> -----Original Message-----
> From: Jason Gunthorpe <[email protected]>
> Sent: 04 November 2025 14:52
> To: Shameer Kolothum <[email protected]>
> Cc: Eric Auger <[email protected]>; [email protected]; qemu-
> [email protected]; [email protected]; Nicolin Chen
> <[email protected]>; [email protected]; [email protected]; Nathan
> Chen <[email protected]>; Matt Ochs <[email protected]>;
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> Krishnakant Jaju <[email protected]>
> Subject: Re: [PATCH v5 15/32] hw/pci/pci: Introduce optional
> get_msi_address_space() callback
>
> On Tue, Nov 04, 2025 at 02:42:57PM +0000, Shameer Kolothum wrote:
> > > On Tue, Nov 04, 2025 at 03:11:55PM +0100, Eric Auger wrote:
> > > > > However, QEMU/KVM also calls this callback when resolving
> > > > > MSI doorbells:
> > > > >
> > > > > kvm_irqchip_add_msi_route()
> > > > > kvm_arch_fixup_msi_route()
> > > > > pci_device_iommu_address_space()
> > > > > get_address_space()
> > > > >
> > > > > VFIO device in the guest with a SMMUv3 is programmed with a gIOVA
> for
> > > > > MSI doorbell. This gIOVA can't be used to setup the MSI doorbell
> > > > > directly. This needs to be translated to vITS gPA. In order to do the
> > > > > doorbell transalation it needs IOMMU address space.
> > >
> > > Why does qemu do anything with the msi address? It is opaque and qemu
> > > cannot determine anything meaningful from it. I expect it to ignore it?
> >
> > I am afraid not. Guest MSI table write gets trapped and it then configures
> > the
> > doorbell( this is where this patch comes handy) and sets up the KVM
> > routing etc.
>
> 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.
See this discussion here,
https://lore.kernel.org/qemu-devel/ch3pr12mb754810ae8d308630041f9afeab...@ch3pr12mb7548.namprd12.prod.outlook.com/
Thanks,
Shameer
