Re: [PATCH] vfio: Request THP-aligned mmap for device fds

[Lorenzo Stoakes]

+cc Ryan for contPMD

On Wed, Jun 17, 2026 at 04:29:28PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 17, 2026 at 07:34:06PM +0100, Matthew Wilcox wrote:
>
> > I don't see this as being something that drivers should be involved with
> > at all.  The MM should be able to get this right without any hints from
> > the file-provider.  Yes, that means I also want to get rid of the setting
> > of get_unmapped_area in ext4/xfs/other filesystems.
> >
> > Looking at generic_get_unmapped_area_topdown(), I think we can do this by
> > making an additional call to vm_unmapped_area() before the existing two,
> > setting info.align_mask and info.align_offset appropriately.
> >
> > Now, what's "appropriately"?  I think it's based on length (>= PMD_SIZE,
> > then >= PUD_SIZE), but we should also take CONTPTE architectures into
> > account.
>
> The info.align_mask and info.align_offset do need information from the
> driver based on what it intends to map into the VMA that is being
> created.
>
> Filesystems probably have quite different requirements than drivers
> using remap_pfn() or vmf_insert_pfn() that have locked down pfn's.

I think part of the problem here is that we don't differentiate between
drivers and filesystems, and what might be sensible for one is perhaps not
sensible for another.

We're too generic really.

With mmap_prepare we have a lot of flexibility as to what we do. That
callback is idempotent and as limited as possible, and actions like remap
are achieved through calling a kernel function like mmap-action_remap().

With that interface, drivers are declarative more than imperative, and
_they can tell us stuff_ :)

That seems pertinent here.

And I'm more than happy to have features that _require_ mmap_prepare.

>
> A pfn driver often has a single already known physical range that it
> will use for the VMA and that range should drive the alignment
> decision of the VMA.
>
> vfio in particular has common use cases where you want to mmap from
> weird offsets, but we still want to achieve a VMA starting point that
> has pa % PUD_SIZE == va % PUD_SIZE. It is impossible to do this if the
> thing building info does not know pa.
>
> I do think it makes sense that no file provider should be computing
> the VA area itself, I think I made that case when Peter was last
> working on this. Now that we have Lorenzo's mmap changes maybe we
> should be talking about supporting VFIO by having a callback to obtain
> the starting pfn for the VMA. Usable only by drivers like VFIO that
> are working with the pfn functions.

Can't we figure this out from what the driver tells us when it invokes an
mmap_prepare action?

In general I have zero trust in drivers, the right basis for dealing with
them is that they will do the most insane thing possible (and you're
pleasantly surprised if they don't :)

Callbacks are problematic, they're not neutral (context/lock state/etc.)
and you can't necessarily make assumptions in calling code after a callback
is called that you could before.

Can't we figure it out from the PFN the driver tells mmap_prepare about?

>
> The starting pfn and VMA size is enough for the mm to setup info
> suitably.

seems so? :)

>
> Maybe other users would prefer a 'max order' callback and then the mm
> would assume the VMA will be popoulated with pgoff aligned folios up
> to that highest order?

Not in favour of that, fear it'll be seen as a new go-faster stripe.  Ask
somebody how many free pints they want and they may veer rather towards the
upper bound :)

>
> > And maybe there's a CONTPMD architecture we should also consider?
>
> ARM HW supports "CONTPMD" but I suppose it is not implemented..

Maybe Ryan has thoughts?

>
> Jason

Thanks, Lorenzo