Hello!
> I know Pavel Fedin was trying to revive kernel_irqchip=off once,
> but I don't know if that effort was abandoned or not.
It should work with the latest kernel, at least i posted patches and all of
them were applied. If nothing got broken during later
rewrites.
The only missin
is used. Currently we can have v3 only
with KVM, but when software emulation is implemented, it can be used in all
cases, regardless of host KVM restrictions.
> That should work for every QEMU version, right?
Wrong. See (1) above.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
cause it's still host's MSI controller.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
; So we
> should not add a new exit (I suggested elsewhere the existing hyper-v
> exit)
Yes, this would also be more consistent i think, if we think subsystem-centric
("we are implementing Hyper-V") instead of
implementation-centric ("we are implementing hypercalls").
ss some guest
> +Hyper-V hypercalls.
Why introducing this? We already have KVM_EXIT_HYPERCALL, which is exactly the
same. AFAIK it's not used at the moment.
Additionally, in theory we could have hypercalls handled in userspace for
something else except HyperV. And not only for x86.
Kind
ll difference between them.
Will it be good?
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
at all. It would rely only on
drivers' ability to communicate with each other (i guess it should be possible
in Windows, isn't it?)
c) does not need to steal resources (BARs, IRQs, etc) from the actual devices.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
se?
> but could we replace Hyper-V VMBus hypercall and it's parameters
> by KVM_EXIT_REG_IO/MSR_IO too?
It depends. Can i read about these hypercalls somewhere? Is there any
documentation?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ation.
I guess your hypercalls to be introduced using KVM_EXIT_HYPERV are also not
used inside qemu so require implementation :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
xit(synic, msr);
break;
So, every time one of these thee MSRs is written, we get a vmexit with values
of all three registers, and that's all. We could
easily have 'synic_exit(synic, msr, data)' in all three cases, and i think the
userspace could easily deal with proposed
KVM_EXIT_R
CP15
timer. And it would require exactly the same capability - process some trapped
system register accesses in userspace.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
vhost-user to return
VIRTIO_NET_F_GUEST_ANNOUNCE ? Does the device really need to have some
explicit support for it? As far as I can understand, there's no special
handling to be done, the guest just sends GARP and that's
it. So why doesn't qemu turn on this feature by itself?
Kind regards,
Pavel
so, in v2 i remove TARGET_PAGE_ALIGN and simply align to
vfio_container_granularity. Would it be OK for now?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
f defined(CONFIG_USER_ONLY)
#define TARGET_PAGE_BITS 12
#else
/* The ARM MMU allows 1k pages. */
/* ??? Linux doesn't actually use these, and they're deprecated in recent
architecture revisions. Maybe a configure option to disable them. */
#define TARGET_PAGE_BITS 10
#endif
--- cut ---
Kind regards,
Pa
would be no difference, because all these alignments are
identical. On ARM, actually, all of these approaches would also give correct
result, because it's only TARGET_PAGE_ALIGN() wrong in this case. So - what do
you think is the most appropriate? Let's make a choice and i'll send a proper
patch.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
g.
> libvirt) to the guest OS. For instance, "system_powerdown" qmp command
> won't work because guest OS can't receive the notification.
Ah, so it is necessary for e.g. commanding a graceful shutdown using
virt-manager's "shutdown" command? Good then, i've missed that.
Kin
we drop already established things and
reinvent a (triangular) wheel, but what's the purpose? Is it being done only
because vendors want obscure proprietary firmware instead of old good u-boot?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--- cut ---
The problem goes away if i add "secure=off" option. "virt" machine is not
affected.
By the way, is it legitimate to default to "secure=on" in KVM mode at all? We
cannot have trustzone inside KVM.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
s make sure that flags == 0, or they simply return
-EINVAL. Therefore, for backwards compatibility we set the flag only if we know
that we need it.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
) {
> > +return "arm-its-kvm";
> > +}
> > +#endif
>
> Why is this in an #ifdef? In theory we could support
> the GICv3 in a 32-bit system.
Only for code consistency, because "arm-its-kvm" class is compiled only for
TARGET_AARC
p:
https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04626.html
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ll no answer to "why are we aligning up, not down?"
question..
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Introduce global kvm_arm_msi_use_devid flag and pass device IDs in
kvm_arch_fixup_msi_route(). Device IDs are required by the ITS.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
target-arm/kvm.c | 6 ++
target-arm/kvm_arm.h | 3 +++
2 files changed, 9 insertions(+)
diff
This temporary patch adds kernel API definitions. Use proper header update
procedure after these features are released.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 9 +++--
2 files changed, 8 insertions
This patch relies on new kernel API which is not released yet.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_its_common.c | 2 +-
hw/intc/arm_gicv3_its_kvm.c| 88 ++
3 files chang
This is the basic skeleton for both KVM and software-emulated ITS.
Since we already prepare status structure, we also introduce complete
VMState description. But, because we currently have no migratable
implementations, we also set unmigratable flag.
Signed-off-by: Pavel Fedin <p
method
- Added unmigratable flag
- Rebased on top of current master, use kvm_arch_fixup_msi_route() now
Pavel Fedin (5):
hw/intc: Implement ITS base class
kernel: Add vGICv3 ITS definitions
kvm_arm: Pass requester ID to MSI routing functions
kvm_arm: Implement support for ITS emulation by KVM
ar
If supported by the configuration, ITS will be added automatically.
This patch also renames v2m_phandle to msi_phandle because it's now used
by both MSI implementations.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/arm/virt.c | 47 +---
hinks, is always 1K.
> If that's all legit, maybe we should be aligning down
> rather than up, we know the host memory is at least 4k pages, so
> anything in the gap between those alignments should be backed by memory,
> right?
You know, i also have this question. Why are we alig
Hello! No news for a long time, we are at RC stage. Could we get this in?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: qemu-devel-bounces+p.fedin=samsung@nongnu.org [mailto:qemu-devel-
> bounces+p.fedi
settings, while MMIO binding support in KVM will still be
missing.
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
RFC => PATCH:
- Add !kvm_eventfds_enabled() conditions to bypass eventfd injection when not
needed
- Ren
event forwarding (slow)
This problem can be observed with libvirt, which checks for /dev/vhost-net
availability and just inserts "vhost=on" automatically in this case; on an
ARM64 system using stock kernel 3.18.0 with CONFIG_IOEVENTFD enabled in
expert settings.
Signed-off-by: Pavel F
ll it be OK then?
Cc'ed also Cornelia because he's taking part in CCW discussion. And the same
kind of generic event forwarding could be implemented
for CCW then.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ace down and fix?
What i would refactor, perhaps, is to add a return code to
memory_region_add_eventfd(), so that it can signal failure instead of a
critical abort, this would allow to get rid of kvm_eventfds_enabled()
accompanying checks.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
el. ccw support is one more reason for
handling forwarding on virtio device level, not on memory
region level.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
no idea what is
diagnose code, as well as have never seen S390 in real life.
I think if you have motivation, you could implement userspace forwarding for
ccw yourself, since you know the thing and know how to
do it. For MMIO it was indeed very simple.
Kind regards,
Pavel Fedin
Expert Engineer
Sam
m would
disappear automatically. What do you think?
Cc'ed Peter since he is the main ARM guy here.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
p in the same internal routine, and the only difference
is 'bool set_handler', which is set to false for
vhost. This is what i rely on, and this is what you should detect too.
PCI backend is a little bit more complicated to read, but it works absolutely
in the same way.
Kind regards,
Pavel
capability check, so that vhost gets disabled instead. A
> > warning is displayed, explaining the reason.
> >
> > This problem can be observed with libvirt, which checks for /dev/vhost-net
> > availability and just inserts "vhost=on" automatically in this case.
>
operty.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
have the same effect on vhost-scsi.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
list and hashtable in sync.
Or, is there any hashtable implementation out there which would keep iterators
valid during modification?
OTOH, glib has a function "remove the element at iterator's position", and we
could postpone addition. So, perhaps, using both
containers would be
: -22
2015-11-17T07:37:42.892309Z qemu-system-aarch64: vfio_dma_map(0x223da230,
0x80002f0400, 0x10fc00, 0x7f89b40400) = -22 (Invalid
argument)
qemu: hardware error: vfio: DMA mapping failed, unable to continue
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/vfio/common.c | 7 ---
for /dev/vhost-net
availability and just inserts "vhost=on" automatically in this case.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
v1 => v2:
- Removed "MMIO" from warning message, because it applies not only to MMIO
- Add note about warning to the commit messa
could have set some flags, but not reported page sizes
and not set VFIO_IOMMI_PGSIZES
What would you say about this? Yes, this would be a "workaround" instead of
"fix".
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
is displayed, explaining the reason.
This problem can be observed with libvirt, which checks for /dev/vhost-net
availability and just inserts "vhost=on" automatically in this case.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/virtio/vhost.c | 6 ++
1 file chang
why i think that we should adapt qemu to what already exists. But,
well, you are The Boss, so you can just say "i don't care". So, just let me now
if you strongly disagree with this.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
-electrons.com/source/drivers/vfio/vfio_iommu_type1.c#L974
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/vfio/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 6797208..afc10c7 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/co
nstance is not desirable.
--- cut ---
Full message here:
https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg01999.html
>
> > -
> > -g_free(prop->name);
> > -g_free(prop->type);
> > -g_free(prop->description);
> > -g_free(prop);
> > }
> > +
> > +g_hash_table_unref(obj->properties);
> > }
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
bably not, as any pointer should coerce to void * without an
> explicit cast, unless it had a 'const' involved.
But after '&' it becomes "**", not just "*", and this implicit conversion
rule doesn't apply any more. "void **" and "something **" are always co
t i would need a guarantee that my
listener is called before KVMMemoryListener, which picks up changes.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
have only this small leftover:
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg02349.html. Needed
both by live migration and SW emulation of GICv3.
Shlomo: Just add your GICv3 code to obj-$(CONFIG_ARM_GIC), and you'll be able
to include things you need.
Kind regards,
Pavel Fedin
Expert
any other registered handlers get executed. What
is missing is one more notifier_list_notify() call right before
qemu_savevm_state_iterate(), and a corresponding
migration_is_active() checker.
What do you think ?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ing to me, and
i silently agreed.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
g
> their obj-y privileges to access it.
Ok, so decided. I will convert my code, test the build and send a small patch
for this soon, perhaps today.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
pathname.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Tested-by: Igor Skalkin <i.skal...@samsung.com>
---
v1 => v2:
- Changed title to more generic one
- Do not introduce new property, check whether the given path is a
directory instead
---
exe
rmally large (about 640K on my VM), but extremely sparse. So the
actually modified space during this callback would be
several pages, unlikely more.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
, so that old clients will never see the state and new clients have
> expressed their interest in the state
With this kind of approach we would not be able to migrate ITS without this
option. Because it's not external clients being interested in this state at the
moment, but qemu itself.
Ki
This allows to signal migration notifiers that the migration has entered
final phase. The condition is set after vm_stop_force_state().
This will be necessary for ITS live migration on ARM, which will have to
dump its state into guest RAM at this point.
Signed-off-by: Pavel Fedin <p
Sorry, guys, i forgot to add "v2" and simply sent the mail. Log is:
v1 => v2:
- Removed unnecessary parenthesis
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: qemu-devel-bounces+p.fedin=sam
behaves in the same way as if CONFIG_NUMA
was not defined. qemu will still fail if the user specifies some other
policy, so that the user knows it.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
backends/hostmem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ba
behaves in the same way as if CONFIG_NUMA
was not defined. qemu will still fail if the user specifies some other
policy, so that the user knows it.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
backends/hostmem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ba
s quite high, and not
everyone wants to get it.
> (Everything should still be cc'd to qemu-devel as well.)
I would drop this requirement, except for stuff which could touch core
functionality (qom, qobject).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Hello!
> > I can further test cases to do more coverage of object proprty handling
> > wrt to classes, if you want me to.
>
> No, if that is sorted out now, I'll drop v2 and need to review v4.
How is it? Any problems / advancements? Could i help somehow?
Kind regards,
Hello!
> > include/hw/cpu/arm.h | 308
> > +++
>
> I think this would be hw/arm/cpu.h
Sorry for split-reply, forgot to look at this...
include/hw/arm is for board classes, isn't it?
Kind regards,
Pavel Fedin
Exper
rface.
Huh, indeed, it's so simple... I failed to notice this.
Peter, what do you think, if we indeed simply move gicv3 implementation from
common-obj-y to obj-y?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
fterwards, if necessary? Anyway,
my fix does not break anything (i hope).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
. :)
So, Peter C, what is your final decision?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
it
anonymous. This is not very useful with ivshmem because it ends up in a
memory which cannot be accessed by something else.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
Tested-by: Igor Skalkin <i.skal...@samsung.com>
---
backends/hostmem-file.c | 26 ++
ssible, because: a) we want to reduce amount of out-of-tree
patches for our project; b) these things affect qemu
core code, and upstreaming them makes sure that we do it right, and our
out-of-tree code will not diverge from the upstream too
much.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Elect
Hello!
> If it is truly internal, then avoiding exposing the state to external
> clients is indeed the way to go.
Already done:
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06262.html, you
should have received it too.
Kind regards,
Pavel Fedin
Expert Engineer
S
for
GICv3 implementation, which needs to call define_arm_cp_regs_with_opaque()
in order to add system registers to the processor model, as well as play
with affinity IDs.
This patch solves the problem by extracting some self-sufficient
definitions into public area (include/hw/cpu).
Signed-off-by: Pavel
n-SRE
mode, instead, if we want to run a legacy guest, we just configure our host to
provide GICv2 for it.
I actually migrate only those CPU interface registers, which are saved by the
kernel code as part of guest's context.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
do you want to tell that GICv3 with affinity routing
enabled simply doesn't care about source CPUs, and if several CPUs trigger the
same SGI for the same destination, the destination gets only one SGI?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
RAM at this point.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hmp.c | 1 +
include/migration/migration.h | 1 +
migration/migration.c | 19 ---
qapi-schema.json | 4 +++-
4 files changed, 21 insertions(+), 4 deletions(-)
time to dig in
OBJECT_CLASS_CHECK() internals. Does it need a sizeof() maybe? And without it
thing looked a bit ugly and incomplete.
Class structure is pretty self-sufficient and straightforward, so i just moved
it too.
I'll reply to the rest of messages on monday, weekend is coming. :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
const ARMCPRegInfo cortex_a57_a53_cp_reginfo[] = {
> #ifndef CONFIG_USER_ONLY
> { .name = "L2CTLR_EL1", .state = ARM_CP_STATE_AA64,
> @@ -258,6 +367,15 @@ static void aarch64_cpu_set_aarch64(Object *obj, bool
> value, Error **errp)
> }
> }
>
> +void aarch64_registers_with_opaque_set(Object *obj, void *opaque)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +
> +define_arm_cp_regs_with_opaque(cpu,
> + cortex_a57_a53_cp_with_opaque_reginfo,
> + opaque);
> +}
> +
> static void aarch64_cpu_initfn(Object *obj)
> {
> object_property_add_bool(obj, "aarch64", aarch64_cpu_get_aarch64,
> --
> 1.9.1
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
told him that he can also include it in his GIC-500 software emulation
patchset, but finally it's up to you.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
el,
but now adopted by ARM64 architecture too. You can also run it under qemu, if
you want to make kind of "full" machine. And it writes some value to BPR1,
which is indeed ignored by Linux kernel.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
series was published.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
. I'll post some patches to move them, but not sure
that Peter accepts them, just because "there are no
users for this yet".
> +
> +#define MAX_NR_GROUP_PRIO 128
> +
> +typedef struct gicv3_irq_state {
> +/* The enable bits are only banked for per-cpu interrupts. */
> +unsigned long *enabled;
> +unsigned long *pending;
> +unsigned long *active;
> +unsigned long *level;
> +unsigned long *group;
> +unsigned long *target;
> +uint16_t *last_active;
> +bool edge_trigger; /* true: edge-triggered, false: level-triggered */
> +int32_t num_cpu; /* For VMSTATE_BITMAP & VMSTATE_VARRAY */
> +} gicv3_irq_state;
> +
> +typedef struct gicv3_sgi_state {
> +unsigned long *pending;
> +int32_t num_cpu; /* For VMSTATE_BITMAP */
> +} gicv3_sgi_state;
> +
> +typedef struct gicv3_sgi_vec {
> +struct gicv3_sgi_state *state;
> +int32_t num_cpu; /* For VMSTATE_VARRAY */
> +} gicv3_sgi_vec;
> +
> +typedef struct gicv3_priority {
> +uint8_t *p;
> +int32_t num_cpu; /* For VMSTATE_VARRAY */
> +} gicv3_Priority;
> +
> typedef struct GICv3State {
> /*< private >*/
> SysBusDevice parent_obj;
> @@ -33,14 +78,45 @@ typedef struct GICv3State {
>
> qemu_irq *parent_irq;
> qemu_irq *parent_fiq;
> +/* GICD_CTLR; for a GIC with the security extensions the NS banked
> version
> + * of this register is just an alias of bit 1 of the S banked version.
> + */
> +uint32_t ctlr;
> +/* Sim GICC_CTLR; again, the NS banked version is just aliases of bits of
> + * the S banked register, so our state only needs to store the S version.
> + */
> +uint32_t *cpu_ctlr;
> +unsigned long *cpu_enabled;
> +
> +gicv3_irq_state irq_state[GICV3_MAXIRQ];
> +gicv3_Priority priority1[GICV3_INTERNAL];
> +uint8_t priority2[GICV3_MAXIRQ - GICV3_INTERNAL];
> +/* For each SGI on the target CPU, we store bitmap
> + * indicating which source CPUs have made this SGI
> + * pending on the target CPU. These correspond to
> + * the bytes in the GIC_SPENDSGIR* registers as
> + * read by the target CPU.
> + */
> +gicv3_sgi_vec sgi[GICV3_NR_SGIS];
> +
> +uint16_t *priority_mask;
> +uint16_t *running_irq;
> +uint16_t *running_priority;
> +uint16_t *current_pending;
> +uint32_t num_mp_affinity;
> +uint64_t *mp_affinity;
>
> MemoryRegion iomem_dist; /* Distributor */
> +MemoryRegion iomem_spi;
> +MemoryRegion iomem_its_cntrl;
> +MemoryRegion iomem_its;
> MemoryRegion iomem_redist; /* Redistributors */
>
> +uint32_t cpu_mask; /* For redistributer */
> uint32_t num_cpu;
> uint32_t num_irq;
> uint32_t revision;
> -bool security_extn;
> +uint8_t security_levels; /* replace seurity extentions */
>
> int dev_fd; /* kvm device fd if backed by kvm vgic support */
> } GICv3State;
> --
> 1.9.1
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
is indeed ignored by Linux kernel.
> So were is it used in QEMU?
You can configure any ARM machine to use firmware blob instead of kernel +
device tree. This way it looks more like a real machine.
> Which machine in hw/arm needs it?
We ran it on virt, for example.
Kind regards,
Pavel F
software emulation of GICv3
with v2 backwards compatilibity mode.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/intc/arm_gicv3_common.c | 127 +-
hw/intc/gicv3_internal.h | 265 +
include/hw/intc/arm_gicv3_common.h
, the patch introduces useful "mp-affinity" property.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
include/hw/cpu/arm.h | 295 +++
target-arm/cpu-qom.h | 40 +--
target-arm/cpu.c | 1 +
target-arm
This temporary patch adds kernel API definitions. Use proper header update
procedure after these features are released.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
linux-headers/asm-arm64/kvm.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a
This actually implements pre_save and post_load methods for in-kernel
vGICv3.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/intc/arm_gicv3_kvm.c | 456 +++-
1 file changed, 452 insertions(+), 4 deletions(-)
diff --git a/h
Add state structure descriptors and actually enable live migration.
In order to describe fixed-size bitmaps, VMSTATE_BITMAP_STATIC() macro is
introduced.
Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
---
hw/intc/arm_gicv3_common.c | 58 -
i
y more
- Added basic LPI support (PROPBASER and PENDBASER).
Pavel Fedin (4):
hw/intc/arm_gicv3_common: Add state information
kernel: Add definitions for GICv3 attributes
hw/intc/arm_gicv3_kvm: Implement get/put functions
hw/intc/arm_gicv3_common: Add vmstate descriptors
hw/intc/arm_gicv3_co
GIC. The property is declared as implementation-specific only
because it would have different object type, for additional fail-safety.
Software-emulated ITS cannot be attached to KVM vGIC and vice versa, actually
only because kernel guys don't want direct LPI injection.
Kind regards,
Pavel Fedin
Exp
? Should ITS + GICv3 be a monolithic
object, or is my suggestion better?
By the way, gicv3_init_irqs_and_mmio() expects only two regions, so it will
not even pay attention to your stubs. You could patch it, of course, but... I
don't think it's the good thing to do.
Kind regards,
Pavel Fedin
Exp
che them during realize. For example, if you accept my
data layout, then you can just add "uint64_t mp_affinity" to GICv3CPUState.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ntc/arm_gicv3_its.c and its
object should inherit from TYPE_ARM_GICV3_ITS_COMMON.
Or do you have some explicit reasons to have everything as a monolith?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
don't set KVM_VGIC_V3_ADDR_TYPE_ITS and that's it. The only thing
linked in is LPI support. With KVM you cannot have LPIs without vITS. Neither
you can directly inject LPIs.
So, in-kernel ITS is also optional.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
o what you want then, it
will not be a problem to remove these unused stubs.
Peter, we are summoning you. :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
/arm_gicv3_cpu_interface.c, add .cp = 15, and - voila - it magically
works with both ARM32 and ARM64.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ptions".
I would say, system registers are nothing new, these are just renamed CP15
registers, with "CPn" prefix removed.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
urpose.
With additions, of course, if necessary.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
HIFT 0
> +#define ARM_AFF0_MASK (0xFFULL << ARM_AFF0_SHIFT)
> +#define ARM_AFF1_SHIFT 8
> +#define ARM_AFF1_MASK (0xFFULL << ARM_AFF1_SHIFT)
> +#define ARM_AFF2_SHIFT 16
> +#define ARM_AFF2_MASK (0xFFULL << ARM_AFF2_SHIFT)
> +#define ARM_AFF3_SHIFT 32
> +#de
100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -46,6 +46,7 @@ enum {
> VIRT_CPUPERIPHS,
> VIRT_GIC_DIST,
> VIRT_GIC_CPU,
> + VIRT_GIC_DIST_SPI = VIRT_GIC_CPU,
> VIRT_GIC_V2M,
> VIRT_GIC_ITS,
> VIRT_GIC_REDIST,
> diff --git a/target-arm/machine.c b/target-arm/machine.c
> index 36a0d15..33f28be 100644
> --- a/target-arm/machine.c
> +++ b/target-arm/machine.c
> @@ -341,7 +341,12 @@ const char *gicv3_class_name(void)
> #endif
> } else {
> /* TODO: Software emulation is not implemented yet */
> -error_report("KVM is currently required for GICv3 emulation\n");
> +#ifdef TARGET_AARCH64
> +return "arm_gicv3";
Peter told me, there is a policy to use dash ("-") in class names. So
"arm-gicv3".
By the way, why does it depend on TARGET_AARCH64? Actually, TARGET_ARM and
TARGET_AARCH64 are the same. You can make both emulators
running both 64- and 32-bit code. KVM code depends on TARGET_AARCH64 only
because some definitions are missing on 32-bit kernels.
You don't have this restriction, so you don't need this #ifdef.
> +#else
> +error_report("KVM GICv3 acceleration is not supported on this "
> + "platform\n");
Why "KVM" here? Well, rubbish anyway because of the above. :)
> +#endif
> }
>
> exit(1);
> --
> 1.9.1
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
se there are no users for now. My
GICv3 live migration is waiting for kernel API to be ready. And kernel API is
waiting for kernel 4.5 development cycle to begin.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
1 - 100 of 511 matches
Mail list logo
