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 guest owns the Stage-1 context, and the host (VFIO) is responsible for establishing the Stage-2 mappings accordingly. Do you see any issues with this approach? Thanks, Shameer
