On Thu, Nov 20, 2025 at 01:21:56PM +0000, Shameer Kolothum wrote: > For certain vIOMMU implementations, such as SMMUv3 in accelerated mode, > the translation tables are programmed directly into the physical SMMUv3 > in a nested configuration. While QEMU knows where the guest tables live, > safely walking them in software would require trapping and ordering all > guest invalidations on every command queue. Without this, QEMU could race > with guest updates and walk stale or freed page tables. > > This constraint is fundamental to the design of HW-accelerated vSMMU when > used with downstream vfio-pci endpoint devices, where QEMU must never walk > guest translation tables and must rely on the physical SMMU for > translation. Future accelerated vSMMU features, such as virtual CMDQ, will > also prevent trapping invalidations, reinforcing this restriction. > > For vfio-pci endpoints behind such a vSMMU, the only translation QEMU > needs is for the MSI doorbell used when setting up KVM MSI route tables. > Instead of attempting a software walk, introduce an optional vIOMMU > callback that returns the MSI doorbell GPA directly. > > kvm_arch_fixup_msi_route() uses this callback when available and ignores > the guest provided IOVA in that case. > > If the vIOMMU does not implement the callback, we fall back to the > existing IOMMU based address space translation path. > > This ensures correct MSI routing for accelerated SMMUv3 + VFIO passthrough > while avoiding unsafe software walks of guest translation tables. > > Cc: Michael S. Tsirkin <[email protected]> > Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Nicolin Chen <[email protected]>
