On 2020/12/1 19:50, Marc Zyngier wrote: > 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. I am not familiar with it... > > It is obviously too late to change the userspace interface, but I wonder > whether we missed something at the time. The interface seems to be really asymmetrical?... Or is there a possibility that we could know which irq is hw before the VFIO device calls kvm_vgic_v4_set_forwarding()? Thanks, Shenming > > Thanks, > > M.
