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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251107141632.GL1732817@nvidia.com>
Date: Fri, 7 Nov 2025 10:16:32 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Wei Wang <wei.w.wang@...mail.com>
Cc: "alex@...zbot.org" <alex@...zbot.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>,
	"joro@...tes.org" <joro@...tes.org>,
	"kevin.tian@...el.com" <kevin.tian@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for
 MMIO-backed addresses

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@...mail.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