On Thu, Nov 06, 2025 at 08:42:31AM +0100, Eric Auger wrote: > > > On 11/5/25 7:58 PM, Jason Gunthorpe wrote: > > On Wed, Nov 05, 2025 at 10:33:08AM -0800, Nicolin Chen wrote: > >> On Wed, Nov 05, 2025 at 02:10:49PM -0400, Jason Gunthorpe wrote: > >>> On Wed, Nov 05, 2025 at 06:25:05PM +0100, Eric Auger wrote: > >>>> if the guest doorbell address is wrong because not properly translated, > >>>> vgic_msi_to_its() will fail to identify the ITS to inject the MSI in. > >>>> See kernel kvm/vgic/vgic-its.c vgic_msi_to_its and > >>>> vgic_its_inject_msi > >>> Which has been exactly my point to Nicolin. There is no way to > >>> "properly translate" the vMSI address in a HW accelerated SMMU > >>> emulation. > >> Hmm, I still can't connect the dots here. QEMU knows where the > >> guest CD table is to get the stage-1 translation table to walk > >> through. We could choose to not let it walk through. Yet, why? > > You cannot walk any tables in guest memory without fully trapping all > > invalidation on all command queues. Like real HW qemu needs to fence > > its walks with any concurrent invalidate & sync to ensure it doesn't > > walk into a UAF situation. > But at the moment we do trap IOTLB invalidates so logically we can still > do the translate in that config. The problem you describe will show up > with vCMDQ which is not part of this series.
This is why I said: > > Thus, the general principle of the HW accelerated vSMMU is that it > > NEVER walks any of these guest tables for any reason. It would make no sense to add table walking then have to figure out how to rip it out. > But anyway you need to provide KVM a valid info about the guest doorbell > for this latter to setup irqfd gsi routing and also program ITS > translation tables. At the moment we have a single vITS in qemu so maybe > we can cheat. qemu should always know what VITS is linked to a pci device to tell kvm whatever it needs, even if there are more than one. Jason
