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

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

[Matthew Wilcox]

[why on earth was stable@ cc'd?  adding/removing various other email
addresses]

On Wed, Jun 17, 2026 at 10:21:40AM -0400, Peter Xu wrote:
> On Tue, Jun 16, 2026 at 04:30:54PM -0600, Alex Williamson wrote:
> > On Tue, 16 Jun 2026 14:01:29 -0400
> > Anthony Pighin <anthony.pighin@nokia.com> wrote:
> > 
> > > VFIO PCI devices support PMD-sized page table entries for BAR mappings
> > > via their huge_fault handler (vfio_pci_mmap_huge_fault).  However, the
> > > VFIO device file_operations never provided a get_unmapped_area callback
> > > to request PMD-aligned virtual address placement from the mmap address
> > > allocator.
> > > 
> > > Before commit 34d7cf637c43 ("mm: don't try THP alignment for FS without
> > > get_unmapped_area"), this was masked by a bug introduced in commit
> > > ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") which
> > > inadvertently applied THP alignment to all file-backed mappings,
> > > regardless of whether they provided a get_unmapped_area callback.
> > > 
> > > When commit 34d7cf637c43 ("mm: don't try THP alignment for FS without
> > > get_unmapped_area") correctly restricted THP alignment to anonymous
> > > mappings and files that explicitly opt in via get_unmapped_area, VFIO BAR
> > > mappings lost their PMD-aligned placement.  Since the huge_fault handler
> > > requires both the VMA start address and the physical PFN to be
> > > PMD-aligned, unaligned VMAs force a fallback to 4KB page faults.
> > > 
> > > For example, a 2GiB BAR results in 524,288 individual page faults
> > > instead of 1,024 PMD-sized faults, increasing the VFIO_IOMMU_MAP_DMA
> > > pinning time by orders of magnitude -- a regression directly visible to
> > > KVM guests during PCI device initialization.
> > > 
> > > Fix this by providing a get_unmapped_area callback in vfio_device_fops,
> > > following the same pattern used by ext4, xfs, btrfs, fuse, and other
> > > subsystems that benefit from THP-aligned placement.
> > 
> > The trouble is that PMD alignment isn't right either, your 1024 PMD
> > faults on a 2GiB BAR would be 2 faults on x86_64 with PUD mappings.
> > QEMU has forced the alignment to make it optimal for some time[1], so
> > there are userspace VMM options.  Seems like you were previously
> > getting lucky.
> > 
> > Peter Xu was working on a more comprehensive solution[2] late last
> > year, but it seems there was an objection to the
> > file_operations.get_mapping_order() proposal before Plumbers and the
> > thread hasn't rekindled.
> > 
> > Gentle bump to Peter and Willy that maybe we could resurrect that
> > effort.  Thanks,
> 
> Yes, since QEMU doesn't need it, it was low priority on my list (also due
> to much more downstream works recently, and a lot of things happened).
> 
> I can definitely try again.

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.  And maybe there's a CONTPMD architecture we should also consider?

Anyway, that's my initial thoughts.  Perhaps others have feedback.

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

[Jason Gunthorpe]

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.

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.

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

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?

> And maybe there's a CONTPMD architecture we should also consider?

ARM HW supports "CONTPMD" but I suppose it is not implemented..

Jason

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

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

[Matthew Wilcox]

On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> 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.

What you're saying is that offset 0 of the opened file might correspond
to a PFN that is not aligned in any way?  I had assumed that when trying
to do the mapping of (2MB+4KiB to 64MB), that the offset specified to
mmap was 2MB+4KiB.  But you seem to be saying that the offset in that
case would be 0 and someone needs to know that it corresponds to a PFN
that is misaligned?

> > 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().

mmap_prepare() is called too late.  We've already assigned the virtual
address range before we call __mmap_region(), and there's no attempt to
adjust 'addr' in __mmap_region() after calling mmap_prepare().

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

[Jason Gunthorpe]

On Thu, Jun 18, 2026 at 04:04:06PM +0100, Matthew Wilcox wrote:
> On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> > 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.
> 
> What you're saying is that offset 0 of the opened file might correspond
> to a PFN that is not aligned in any way?  I had assumed that when trying
> to do the mapping of (2MB+4KiB to 64MB), that the offset specified to
> mmap was 2MB+4KiB.  But you seem to be saying that the offset in that
> case would be 0 and someone needs to know that it corresponds to a PFN
> that is misaligned?

I do expect that the pgoff space is usually aligned to the pfn space,
most drivers do that or could be improved to do that. There will be
some off cases, but maybe we don't care, and VFIO should be fine.

That is certainly an easier place to start.

Jason

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

[Lorenzo Stoakes]

On Thu, Jun 18, 2026 at 12:30:49PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 04:04:06PM +0100, Matthew Wilcox wrote:
> > On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> > > 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.
> >
> > What you're saying is that offset 0 of the opened file might correspond
> > to a PFN that is not aligned in any way?  I had assumed that when trying
> > to do the mapping of (2MB+4KiB to 64MB), that the offset specified to
> > mmap was 2MB+4KiB.  But you seem to be saying that the offset in that
> > case would be 0 and someone needs to know that it corresponds to a PFN
> > that is misaligned?
>
> I do expect that the pgoff space is usually aligned to the pfn space,
> most drivers do that or could be improved to do that. There will be
> some off cases, but maybe we don't care, and VFIO should be fine.

Some stuff has weird assumptions about pfn=0 at start of the range (DMA for
instance).

Presumably not applicable to VFIO but that's a thing we need to stop
doing... (I have some patches I deferred from a while back changing the DMA
stuff).

>
> That is certainly an easier place to start.
>
> Jason

Thanks, Lorenzo

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

[Jason Gunthorpe]

On Thu, Jun 18, 2026 at 04:56:06PM +0100, Lorenzo Stoakes wrote:
> > > What you're saying is that offset 0 of the opened file might correspond
> > > to a PFN that is not aligned in any way?  I had assumed that when trying
> > > to do the mapping of (2MB+4KiB to 64MB), that the offset specified to
> > > mmap was 2MB+4KiB.  But you seem to be saying that the offset in that
> > > case would be 0 and someone needs to know that it corresponds to a PFN
> > > that is misaligned?
> >
> > I do expect that the pgoff space is usually aligned to the pfn space,
> > most drivers do that or could be improved to do that. There will be
> > some off cases, but maybe we don't care, and VFIO should be fine.
> 
> Some stuff has weird assumptions about pfn=0 at start of the range (DMA for
> instance).

Do you have a pointer? I'm drawing a blank what "dma" is?

Jason

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

[Jason Gunthorpe]

On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> > 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?

VFIO installs the pages via fault handler so there is not a naturally
existing way to pass in the pfn?

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

Maybe it can pass the pfn anyhow and not have the mmap logic map
anything?

> > 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 :)

I think you need something, otherwise we will be aligning VMAs that
never have anything larger than a 2M THP to 1GB boundaries, doesn't
seem good.

Jason

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

[Matthew Wilcox]

On Thu, Jun 18, 2026 at 12:28:05PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> > Can't we figure this out from what the driver tells us when it invokes an
> > mmap_prepare action?
> 
> VFIO installs the pages via fault handler so there is not a naturally
> existing way to pass in the pfn?

Is there an advantage to doing it this way?  I understand why we (eg)
demand-page pagecache, that's obvious.  But I've never really understood
the advantage to taking page faults for PFNMAP areas where we don't
really do anything, just figure out which PFN needs to be installed.
It defers page table allocation, I suppose.

> > 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 :)
> 
> I think you need something, otherwise we will be aligning VMAs that
> never have anything larger than a 2M THP to 1GB boundaries, doesn't
> seem good.

If Lorenzo's willing to move the mmap_prepare call earlier, to before we
allocate the vma then we can do it that way ...

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

[Jason Gunthorpe]

On Fri, Jun 19, 2026 at 05:11:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jun 18, 2026 at 12:28:05PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote:
> > > Can't we figure this out from what the driver tells us when it invokes an
> > > mmap_prepare action?
> > 
> > VFIO installs the pages via fault handler so there is not a naturally
> > existing way to pass in the pfn?
> 
> Is there an advantage to doing it this way?  I understand why we (eg)
> demand-page pagecache, that's obvious.  But I've never really understood
> the advantage to taking page faults for PFNMAP areas where we don't
> really do anything, just figure out which PFN needs to be installed.
> It defers page table allocation, I suppose.

VFIO has a model where the mapping can come and go, so it makes the
entire VMA SIGBUS from time to time. The only way to do this currently
is with faulting.

The mm also had races around populating the mmap in the mmap callback
and using zap on the inode, faulting avoids those too. Lorenzo may
have fixed that with the new interface though

Jason

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

[Ryan Roberts]

On 18/06/2026 15:55, Lorenzo Stoakes wrote:
> +cc Ryan for contPMD
> 
>>
>>> 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?

Sorry not quite sure what you're asking so will give a generic answer:

Arm arch does indeed support CONTPMD at level 2 in the same way that it supports
CONTPTE at level 3, as follows:

+-----------+-----------+-----------+-----------+-----------+
| Page Size |  CONTPTE  |    PMD    |  CONTPMD  |    PUD    |
+-----------+-----------+-----------+-----------+-----------+
|    4KB    |   64KB    |    2MB    |    32MB   |    1GB    |
|   16KB    |    2MB    |   32MB    |     1GB   |           |
|   64KB    |    2MB    |  512MB    |    16GB   |           |
+-----------+-----------+-----------+-----------+-----------+

For HugeTLB, Linux/arm64 support all of the listed sizes today. For !HugeTLB
(i.e. THP, large file filos) Linux/arm64 supports CONTPTE and PMD only. We could
(and probably would) extend to support CONTPMD once THP PUDs are supported.

Not sure if that answers the question?

Thanks,
Ryan

> 
>>
>> Jason
> 
> Thanks, Lorenzo