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 m
r TCG 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
above...
> 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 hyp
y small difference between them.
Will it be good?
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
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.
be touched 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
implementation.
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
the purpose?
> 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
;
if (!host)
synic_exit(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 th
mulate physical 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
xpect 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?
Ok, 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 r
N() (what Peter
suggested).
On x86 there 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
> 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&
ations, 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
0008300 - 0x80008358
--- 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
bility */
> > +if (kvm_direct_msi_enabled()) {
> > +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 "ar
re 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
p:
https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04626.html
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
;s however, still no answer to "why are we aligning up, not down?"
question..
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
for ARM platform, which, as qemu thinks, 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
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
---
hw/arm/virt.c | 47 +--
1 file change
This patch relies on new kernel API which is not released yet.
Signed-off-by: Pavel Fedin
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_its_common.c | 2 +-
hw/intc/arm_gicv3_its_kvm.c| 88 ++
3 files changed, 90 insertions(+), 1
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
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
---
hw/intc
This temporary patch adds kernel API definitions. Use proper header update
procedure after these features are released.
Signed-off-by: Pavel Fedin
---
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a
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
---
target-arm/kvm.c | 6 ++
target-arm/kvm_arm.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/target-arm/kvm.c b
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
Signed-off-by: Pavel Fedin
---
RFC => PATCH:
- Add !kvm_eventfds_enabled() conditions to bypass eventfd injection when not
needed
- Renamed "ioeventfd" to "eventfd", just to mak
t it.
Both (1) and (2) end up 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 absolutel
erformance.
Will 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
Michael. 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
ich is quite easy to trace 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
U. Then this IOMMU alignment problem 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
e, i have 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 En
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 Fedi
: -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
---
hw/vfio/common.c | 7 ---
1 file changed, 4 insertions
/dev/vhost-net
availability and just inserts "vhost=on" automatically in this case.
Signed-off-by: Pavel Fedin
---
v1 => v2:
- Removed "MMIO" from warning message, because it applies not only to MMIO
- Add note about warning to the commit message
---
hw/virtio/vhost.c | 6 ++
27; per property.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
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.
>
patch
vhost.c so that it should also have the same effect on vhost-scsi.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
problems with them. Just
keep the 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,
sizes.
b) Some future kernels 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
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
---
hw/virtio/vhost.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a
hat's 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
---
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/common.c
@@ -704,7 +704,7
his cast needed?
>
> Probably 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
g ObjectProperty to have a back-poointer
to an object instance 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);
> >
d
use them, but 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
e
before 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
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
E
re normally 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
pathname.
Signed-off-by: Pavel Fedin
Tested-by: Igor Skalkin
---
v1 => v2:
- Changed title to more generic one
- Do not introduce new property, check whether the given path is a
directory instead
---
exec.c| 34 +-
qemu-doc.texi | 2 +-
2 files changed,
ar thing 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
dded afterwards, if necessary? Anyway,
my fix does not break anything (i hope).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
oblem. :)
So, Peter C, what is your final decision?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
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
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
Tested-by: Igor Skalkin
---
backends/hostmem-file.c | 26 +-
exec.c | 36
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
---
backends/hostmem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/backends/hostmem.c b/backends
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
---
backends/hostmem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/backends/hostmem.c b/backends
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
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
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 rega
igh, 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
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
---
include
new option to enable the
> state, 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 th
RAM at this point.
Signed-off-by: Pavel Fedin
---
hmp.c | 1 +
include/migration/migration.h | 1 +
migration/migration.c | 19 ---
qapi-schema.json | 4 +++-
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/hmp.c b
v3 with non-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
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
spendsgir[4]
> unless there's a good reason to do something else.
This is about (**). Or 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
ckly, and didn't have much 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
ds any 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_gic
This actually implements pre_save and post_load methods for in-kernel
vGICv3.
Signed-off-by: Pavel Fedin
---
hw/intc/arm_gicv3_kvm.c | 456 +++-
1 file changed, 452 insertions(+), 4 deletions(-)
diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc
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
---
hw/intc/arm_gicv3_common.c | 58 -
include/migration/vmstate.h
This temporary patch adds kernel API definitions. Use proper header update
procedure after these features are released.
Signed-off-by: Pavel Fedin
---
linux-headers/asm-arm64/kvm.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/linux-headers/asm-arm64
software emulation of GICv3
with v2 backwards compatilibity mode.
Signed-off-by: Pavel Fedin
---
hw/intc/arm_gicv3_common.c | 127 +-
hw/intc/gicv3_internal.h | 265 +
include/hw/intc/arm_gicv3_common.h | 93 -
3
patch introduces useful "mp-affinity" property.
Signed-off-by: Pavel Fedin
---
include/hw/cpu/arm.h | 295 +++
target-arm/cpu-qom.h | 40 +--
target-arm/cpu.c | 1 +
target-arm/cpu.h | 226 +-
T 16
> +#define ARM_AFF2_MASK (0xFFULL << ARM_AFF2_SHIFT)
> +#define ARM_AFF3_SHIFT 32
> +#define ARM_AFF3_MASK (0xFFULL << ARM_AFF3_SHIFT)
Actually, these are defined in target-arm/cpu-qom.h. Looks like it was my
fault and they have to be moved to something like
include/hw/cpu/cpu_
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
m Intel,
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
> +REGINFO_SENTINEL
> +};
> +
One more note on this table, which i previously forgot. We tried to run EFI
here, and it crashes with your emulation because when
setting up GICv3 it also pokes BPR1_EL1 register. You should implement it.
> static const ARMCPRegInfo cortex_a57_a53_cp_reginfo[] = {
> #
ion, but abandoned when
vITS patch series was published.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
ml
I 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
hw/intc/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
it and use for your purpose.
With additions, of course, if necessary.
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
an cache 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
ITS. Just 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
ds on the 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 rega
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
v2 RFC structure and judge us? 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 thi
/intc/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
fused
to accept this small standalone patch because 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
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
> +#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
> +#define ARM_AFF3_MASK (0xFFULL << ARM_AFF3_SHIFT)
> +
> +#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
1 - 100 of 511 matches
Mail list logo
