Re: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for MMIO-backed addresses

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Nov 07, 2025 at 02:38:50AM +0000, Wei Wang wrote:
> On Friday, November 7, 2025 9:04 AM, Jason Gunthorpe wrote:
> > On Mon, Nov 03, 2025 at 10:00:34PM +0800, Wei Wang wrote:
> > > Before requesting the IOMMU driver to map an IOVA to a physical
> > > address, set the IOMMU_MMIO flag in dma->prot when the physical
> > > address corresponds to MMIO. This allows the IOMMU driver to handle
> > MMIO mappings specially.
> > > For example, on AMD CPUs with SME enabled, the AMD IOMMU driver
> > avoids
> > > setting the C-bit if iommu_map() is called with IOMMU_MMIO set in prot.
> > > This prevents issues with PCIe P2P communication, since current PCIe
> > > switches and devices do not interpret the C-bit correctly.
> > >
> > > Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
> > > ---
> > >  drivers/vfio/vfio_iommu_type1.c | 14 +++++++++-----
> > >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > This may be the best you can do with vfio type1, but just because the VMA is
> > special doesn't necessarily mean it is MMIO, nor does it mean it is decrypted
> > memory.
> 
> I think here vfio type1 only needs to provide the info about "MMIO or not"
> (the decision to encrypt MMIO or not rests with the vendor IOMMU driver).
> 
> Why might a region not be MMIO when vma->flags includes VM_IO | VM_PFNMAP?
> (are you aware of any real examples in use?)

VM_IO should indicate MMIO, yes, but we don't actually check that in
this type 1 path..

> > I think to really make this work fully properly going forward people are going
> > to have to use iommufd's dmabuf.
> 
> Yeah, I'll also patch for iommufd. We still need to account for the
> case that many users are still relying on legacy VFIO type1 (will
> also have some backport work of this patch).

I think my dmabuf patch for iommufd already does this properly.

Jason