Re: [RFC PATCH 1/2] vfio: Improve DMA mapping performance for huge pages

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Jan 05, 2026 at 10:31:14AM -0800, David Matlack wrote:

> Ack on the feedback that this is not a general solution and we should
> switch to iommufd with memfd pinning for our use-case. But I think
> Google will need to carry an optimization locally to type1 until we
> can make that switch to meet our goals.
> 
> For HugeTLB mappings specifically, can it be assumed the VMA contains
> the entire folio? I'm wondering what is the safest way to achieve
> performance close to what Aaron achieved in his patch in type1 for
> HugeTLB and DevDAX. (Not for upstream, just internally.)

If you are certain the address range in question is a single VMA and
that VMA is one of the special memfd-like types then you should be
able to do that.

The issue here is that VFIO doesn't have any idea about VMAs and
pin_user_pages_fast() doesn't check them. So you need to give up
pin_user_pages_fast() and have vfio code bound the work to actual VMAs
under a lock with the table read to make this solution work fully
properly.

Of course for your very special use case the VMM isn't creating sliced
up VMAs and trying to attack the kernel with them so the simple
solution here is workable with VMM co-operation. (though it opens a
sort of security problem of course)

But I wouldn't want to see such hackery in upstream.

Jason