Messages in this thread | | | Date | Tue, 01 Dec 2020 11:50:00 +0000 | From | Marc Zyngier <> | Subject | Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side |
| |
On 2020-12-01 11:40, Shenming Lu wrote: > On 2020/12/1 18:55, Marc Zyngier wrote: >> On 2020-11-30 07:23, Shenming Lu wrote: >> >> Hi Shenming, >> >>> We are pondering over this problem these days, but still don't get a >>> good solution... >>> Could you give us some advice on this? >>> >>> Or could we move the restoring of the pending states (include the >>> sync >>> from guest RAM and the transfer to HW) to the GIC VM state change >>> handler, >>> which is completely corresponding to save_pending_tables (more >>> symmetric?) >>> and don't expose GICv4... >> >> What is "the GIC VM state change handler"? Is that a QEMU thing? > > Yeah, it is a a QEMU thing... > >> We don't really have that concept in KVM, so I'd appreciate if you >> could >> be a bit more explicit on this. > > My thought is to add a new interface (to QEMU) for the restoring of > the pending states, which is completely corresponding to > KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES... > And it is called from the GIC VM state change handler in QEMU, which > is happening after the restoring (call kvm_vgic_v4_set_forwarding()) > but before the starting (running) of the VFIO device.
Right, that makes sense. I still wonder how much the GIC save/restore stuff differs from other architectures that implement similar features, such as x86 with VT-D.
It is obviously too late to change the userspace interface, but I wonder whether we missed something at the time.
Thanks,
M. -- Jazz is not dead. It just smells funny...
| |