> -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 04 November 2025 16:02 > 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 4:14 PM, Shameer Kolothum wrote: > > > >> -----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? > > I need to delve into it again as I forgot the details. Will come back to you > ...
I think the BYPASS case will work anyway as in smmuv3_translate() fn we are checking the ste config (SMMU_TRANS_BYPASS) and it will just return the same address back. So we can do the same here in get_msi_address_space() and return IOMMU as always. And that completely avoids &address_space_memory from SMMUv3-accel if that’s the concern. Thanks, Shameer
