Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8 October 2015 at 13:45, Pavel Fedin <p.fedin@xxxxxxxxxxx> wrote:

>> Speaking of which, does the QEMU side of this patch set require first
>> adding the GICv3 emulation for the data structures or is there a
>> stand-alone migration patch set somewhere?
>
>  I rolled it out a week ago: https://www.mail-archive.com/qemu-devel@xxxxxxxxxx/msg325331.html. I
> tried to get reviewed/accepted/whatever at least data structure part, but Peter replied that he
> isn't interested before we have the kernel.

More specifically, I wanted us to agree on the kernel API for
migration, because that significantly affects how the QEMU
code looks.

A quick look at your patch suggests you still have data
structures like

+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;
+    bool edge_trigger; /* true: edge-triggered, false: level-triggered  */
+    uint32_t mask_size; /* Size of bitfields in long's, for migration */
+};

I think it's probably going to be better to have an array
of redistributor structures (one per CPU), and then keep
the state that in hardware is in each redistributor inside
those sub-structures. Similarly for state that in hardware
is inside the distributor, and inside each cpu interface.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux