> -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 04 November 2025 14:44 > To: Shameer Kolothum <[email protected]>; qemu- > [email protected]; [email protected] > Cc: [email protected]; Jason Gunthorpe <[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 > > External email: Use caution opening links or attachments > > > On 11/4/25 3:37 PM, Shameer Kolothum wrote: > > Hi Eric, > > > >> -----Original Message----- > >> From: Eric Auger <[email protected]> > >> Sent: 04 November 2025 14:12 > >> To: Shameer Kolothum <[email protected]>; qemu- > >> [email protected]; [email protected] > >> Cc: [email protected]; Jason Gunthorpe <[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 > >> > >> External email: Use caution opening links or attachments > >> > >> > >> Hi Shameer, Nicolin, > >> > >> On 10/31/25 11:49 AM, Shameer Kolothum wrote: > >>> On ARM, devices behind an IOMMU have their MSI doorbell addresses > >>> translated by the IOMMU. In nested mode, this translation happens in > >>> two stages (gIOVA → gPA → ITS page). > >>> > >>> In accelerated SMMUv3 mode, both stages are handled by hardware, so > >>> get_address_space() returns the system address space so that VFIO > >>> can setup stage-2 mappings for system address space. > >> Sorry but I still don't catch the above. Can you explain (most probably > >> again) why this is a requirement to return the system as so that VFIO > >> can setup stage-2 mappings for system address space. I am sorry for > >> insisting (at the risk of being stubborn or dumb) but I fail to > >> understand the requirement. As far as I remember the way I integrated it > >> at the old times did not require that change: > >> https://lore.kernel.org/all/20210411120912.15770-1- > >> [email protected]/ > >> I used a vfio_prereg_listener to force the S2 mapping. > > Yes I remember that. > > > >> What has changed that forces us now to have this gym > > This approach achieves the same outcome, but through a > > different mechanism. Returning the system address space > > here ensures that VFIO sets up the Stage-2 mappings for > > devices behind the accelerated SMMUv3. > > > > I think, this makes sense because, in the accelerated case, the > > device is no longer managed by QEMU’s SMMUv3 model. The > On the other hand, as we discussed on v4 by returning system as you > pretend there is no translation in place which is not true. Now we use > an alias for it but it has not really removed its usage. Also it forces > use to hack around the MSI mapping and introduce new PCIIOMMUOps. > Have > you assessed the feasability of using vfio_prereg_listener to force the > S2 mapping. Is it simply not relevant anymore or could it be used also > with the iommufd be integration? Eric
IIUC, the prereg_listener mechanism just enables us to setup the s2 mappings. For MSI, In your version, I see that smmu_find_add_as() always returns IOMMU as. How is that supposed to work if the Guest has s1 bypass mode STE for the device? Thanks, Shameer
