On Tue, Nov 04, 2025 at 11:35:35AM -0400, Jason Gunthorpe wrote: > On Tue, Nov 04, 2025 at 03:20:59PM +0000, Shameer Kolothum wrote: > > > On Tue, Nov 04, 2025 at 02:58:44PM +0000, Shameer Kolothum wrote: > > > > > Sure it is trapped, but nothing should be looking at the MSI address > > > > > from the guest, it is meaningless and wrong information. Just ignore > > > > > it. > > > > > > > > Hmm.. we need to setup the doorbell address correctly. > > > > > > > If we don't do the translation here, it will use the Guest IOVA > > > > address. Remember, we are using the IORT RMR identity mapping to get > > > > MSI working. > > > > > > Either you use the RMR value, which is forced by the kernel into the > > > physical MSI through iommufd and kernel ignores anything qemu > > > does. So fully ignore the guest's vMSI address. > > > > Well, we are sort of trying to do the same through this patch here. > > But to avoid a "translation" completely it will involve some changes to > > Qemu pci subsystem. I think this is the least intrusive path I can think > > of now. And this is a one time setup mostly. > > Should be explained in the commit message that the translation is > pointless. I'm not sure about this, any translation seems risky > because it could fail. The guest can use any IOVA for MSI and none may > fail.
In the current design of KVM in QEMU, it does a generic translation from gIOVA->gPA for the doorbell location to inject IRQ, whether VM has an accelerated IOMMU or an emulated IOMMU. In the accelerated case, this translation is pointless for the SMMU HW underlying. But the IRQ injection routine still stands. We could have invented something like get_msi_physical_address, but the vPCI device is programmed with gIOVA for MSI. So it makes sense for VMM to follow that gIOVA? Even if the gIOVA is a wrong address, I think VMM shouldn't correct that, since a real HW wouldn't. Thanks Nicolin
