On Tue, Nov 04, 2025 at 02:09:28PM -0400, Jason Gunthorpe wrote: > On Tue, Nov 04, 2025 at 09:57:53AM -0800, Nicolin Chen wrote: > > On Tue, Nov 04, 2025 at 01:41:52PM -0400, Jason Gunthorpe wrote: > > > On Tue, Nov 04, 2025 at 09:11:55AM -0800, Nicolin Chen wrote: > > > > 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. > > > > > > And what happens if the translation fails because there is no mapping? > > > It should be ignored for this case and not ignored for others. > > > > It errors out and does no injection. IOW, yea, "ignored". > > "does no injection" does not sound like ignored to me..
Sorry. I think I've missed your point. The hardware path is programmed with a RMR-ed sw_msi in the host via VFIO's PCI IRQ, ignoring the gIOVA and vITS in the guest VM, even if the vPCI is programmed with a wrong gIOVA that could not be translated. KVM would always get the IRQ from HW, since the HW is programmed correctly. But if gIOVA->vITS is not mapped, i.e. gIOVA is given incorrectly, it can't inject the IRQ. (Perhaps vSMMU in this case should F_TRANSLATION to the device.) What was the meaning of "ignore" in your remarks? Thanks Nicolin
