[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250613134111.469884-1-peterx@redhat.com>
Date: Fri, 13 Jun 2025 09:41:06 -0400
From: Peter Xu <peterx@...hat.com>
To: linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
kvm@...r.kernel.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Alex Williamson <alex.williamson@...hat.com>,
Zi Yan <ziy@...dia.com>,
Jason Gunthorpe <jgg@...dia.com>,
Alex Mastro <amastro@...com>,
David Hildenbrand <david@...hat.com>,
Nico Pache <npache@...hat.com>,
peterx@...hat.com
Subject: [PATCH 0/5] mm/vfio: huge pfnmaps with !MAP_FIXED mappings
[based on latest akpm/mm-new as of June 12th 2025, commit 19d47edf9]
This series enables !MAP_FIXED huge pfnmaps for vfio-pci.
Before this series, an userapp in most cases need to be modified to benefit
from huge mappings to provide huge size aligned VA using MAP_FIXED. After
this series, the userapp can benefit from huge pfnmap automatically after
the kernel upgrades, with no userspace modifications.
It's still best-effort, because the auto-alignment will require a larger VA
range to be allocated via the per-arch allocator, hence if the huge-mapping
aligned VA cannot be allocated then it'll still fallback to small mappings
like before. However that's really from theory POV: in reality I don't yet
know when it'll fail on any 64bits system due to it.
So far, only vfio-pci is supported. But the logic should be applicable to
all the drivers that support or will support huge pfnmaps.
Kudos goes to Jason on the suggestion:
https://lore.kernel.org/r/20250530131050.GA233377@nvidia.com
Though instead of refactoring shmem, I found we already have a function we
can directly reuse for THP calculations.
The idea is fairly simple too, which is to make sure whatever virtual
address got returned from an mmap() request of the MMIO BAR regions to be
huge-size-aligned with the physical address of the corresponding BARs.
It contains minimum mm changes, in reality only to rename and export the
THP function that can be reused. That is patch 3.
Patch 1 & 2 are trivial small cleanups that I found while I'm looking at
this problem. They can even be posted separately if anyone would like me
to.
Patch 4 is a tunneling needed to wire vfio-pci over to the mmap()
operations of vfio_device. Then, patch 5 is the real meat.
For testing: besides checkpatch and my daily cross-build harness, unit
tests working all fine from either myself [1] (based on another Alex's test
program) or Alex, checking the alignments look all sane with
mmap(!MAP_FIXED), and huge mappings properly installed.
Alex Mastro: please feel free to try this out with your internal tests. The
hope is that after this series applied your app should get huge pfnmaps
without any changes (with any pgoff specified). Logically there should be
minimal dependency on stable branches whenever huge pfnmap is available.
Comments welcomed, thanks.
[1] https://github.com/xzpeter/clibs/blob/master/misc/vfio-pci-nofix.c
[2] https://github.com/awilliam/tests/blob/vfio-pci-device-map-alignment/vfio-pci-device-map-alignment.c
Peter Xu (5):
mm: Deduplicate mm_get_unmapped_area()
mm/hugetlb: Remove prepare_hugepage_range()
mm: Rename __thp_get_unmapped_area to mm_get_unmapped_area_aligned
vfio: Introduce vfio_device_ops.get_unmapped_area hook
vfio-pci: Best-effort huge pfnmaps with !MAP_FIXED mappings
arch/loongarch/include/asm/hugetlb.h | 14 ------
arch/mips/include/asm/hugetlb.h | 14 ------
drivers/vfio/pci/vfio_pci.c | 3 ++
drivers/vfio/pci/vfio_pci_core.c | 65 ++++++++++++++++++++++++++++
drivers/vfio/vfio_main.c | 18 ++++++++
fs/hugetlbfs/inode.c | 8 +---
include/asm-generic/hugetlb.h | 8 ----
include/linux/huge_mm.h | 14 +++++-
include/linux/hugetlb.h | 6 ---
include/linux/vfio.h | 7 +++
include/linux/vfio_pci_core.h | 6 +++
mm/huge_memory.c | 6 ++-
mm/mmap.c | 5 +--
13 files changed, 120 insertions(+), 54 deletions(-)
--
2.49.0
Powered by blists - more mailing lists