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

From: Jason Gunthorpe

Date: Fri Dec 12 2025 - 02:00:25 EST


On Fri, Dec 12, 2025 at 02:36:46AM +0000, Tian, Kevin wrote:
> > From: Wei Wang <wei.w.wang@xxxxxxxxxxx>
> > Sent: Thursday, November 13, 2025 11:54 PM
> >
> > @@ -629,6 +630,8 @@ static long vaddr_get_pfns(struct mm_struct *mm,
> > unsigned long vaddr,
> > ret = -EFAULT;
> > }
> > }
> > + if (vma->vm_flags & VM_IO)
> > + *prot |= IOMMU_MMIO;
>
> move into "if (is_invalid_reserved_pfn(*pfn)) {}". it's pointless to set
> it in the error path.
>
> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
>
> btw another alternative is letting userspace set a map flag explicitly
> e.g. introducing a new VFIO_DMA_MAP_FLAG_MMIO flag bit. It's
> not considered because your use case requires existing VMMs to
> work?

I don't think we should do that, userspace shouldn't be able to create
a mapping inconsistent with the rest of the kernel for security
reasons.

I think if we ever need a cachable mmio through to the iommu then it
should be wired through the dmabuf mechanism the same way vfio drivers
wire the cachability when they make the mmap.

The nvgrace is the only driver that creates a cachable mmap already,
and it would be more correct to have a cachable IOPTE, but the only HW
tha driver works with does not care either way so it has been left.

Jason