[PATCH v16 00/12] migrate on fault for device pages

[mpenttil@redhat.com]

From: Mika Penttilä <mpenttil@redhat.com>

Currently, the way device page faulting and migration works
is not optimal, if you want to do both fault handling and
migration at once.

Being able to migrate not present pages (or pages mapped with incorrect
permissions, eg. COW) to the GPU requires doing either of the
following sequences:

1. hmm_range_fault() - fault in non-present pages with correct permissions, etc.
2. migrate_vma_*() - migrate the pages

Or:

1. migrate_vma_*() - migrate present pages
2. If non-present pages detected by migrate_vma_*():
   a) call hmm_range_fault() to fault pages in
   b) call migrate_vma_*() again to migrate now present pages

The problem with the first sequence is that you always have to do two
page walks even when most of the time the pages are present or zero page
mappings so the common case takes a performance hit.

The second sequence is better for the common case, but far worse if
pages aren't present because now you have to walk the page tables three
times (once to find the page is not present, once so hmm_range_fault()
can find a non-present page to fault in and once again to setup the
migration). It is also tricky to code correctly. One page table walk
could costs over 1000 cpu cycles on X86-64, which is a significant hit.

We should be able to walk the page table once, faulting
pages in as required and replacing them with migration entries if
requested.

Add a new flag to HMM APIs, HMM_PFN_REQ_MIGRATE,
which tells to prepare for migration also during fault handling.
For the migrate_vma_setup() call paths, new flags, MIGRATE_VMA_FAULT,
and MIGRATE_VMA_WRITE are added to tell to add fault handling to migrate.

An extra benefit of migrating with hmm_range_fault() path
is the migrate_vma.vma gets populated, so no need to
retrieve that separataly.

This series avoids the problems in current collecting implementation,
where racing MADV_DONTNEED could make the collecting arrays overflow.
This is achieved mainly by having a rollback mechanism and
populating the collecting array as the last step.

Tested in X86-64 VM with HMM test device, passing the selftests.
The migrate throughput tests from the selftests show similar numbers
(within error margin) as an unmodified kernel, verifying not
regressing with current workloads.

For nouveau migrate-on-fault test harness was : Fedora 44,
Mesa Rusticl, and a fine-grained-system-SVM OpenCL program.
Nouveau SVM is opt-in via Mesa. The OpenCL program passes a plain
malloc pointer (64 pages, array of integers) to the GPU. Increments
each element on GPU, and verifies on the CPU the result. So it drives
both directions of migration. With svm_migrate_on_fault=1, no
migration at bind happens so it's full lazy. The GPU used in testing
was Pascal generation GP102 (selected based on what nouveau
supports for SVM).

Tested also rebased on the
"Remove device private pages from physical address space" series:
https://lore.kernel.org/linux-mm/20260130111050.53670-1-jniethe@nvidia.com/
plus a small patch to adjust with no problems.

Changes in v16:
  - rebased to 7.3.0 (drm-tip)
  - addressed sashiko's concerns
  - added patch 12 - drm/nouveau/svm: add support for migrate on fault

Sashiko's concerns :
https://sashiko.dev/#/patchset/20260924065313.899730-1-mpenttil%40redhat.com

patch 01 mm/Kconfig: changes for migrate on fault for device pages
  Q  "Does selecting HMM_MIRROR under DEVICE_MIGRATION require an explicit
  dependency on MMU?"  
  A   A DEVICE_MIGRATION is def_bool MIGRATION && ZONE_DEVICE,  and MIGRATION depends on MMU,
  which HMM_MIRROR also depends on. DEVICE_MIGRATION is not user selectable, and nothing
  selects it explicitly now. If some config would select it in the future, it should have MMU.

patch 03 mm/hmm: preparations for HMM to participate in migration
  Q  "This is not a bug, but could we add MIGRATE_VMA_SELECT_NONE to this enum
  under CONFIG_MIGRATION?"
  A  Yes, added.

patch 05 mm/hmm: migrate collection in HMM pagewalk - pte level
  Q  "Can this cause a livelock when splitting the folio?"
  A  the ref is taken under ptl before dropping it (no UAF), and the split either succeeds
  (progress) or fails -> HMM_PFN_ERROR + return 0 (termination). No unbounded retry,
  no livelock. The -EAGAIN -> goto again path only re-walks when state actually changed.
  Q  "Does this code operate on uninitialized folio metadata if a driver maps an
  uninitialized compound page to userspace?"
  A  The folio is either from vm_normal_page(), or a device private/coherent page
  and properly initialized so no.
  Q "Can a transient split failure result in valid pages being falsely marked as
  inaccessible?"
  A  a split failure reports HMM_PFN_ERROR for that walk only; the consumer can re-fault
  and a later split can succeed. The page isn't lost or permanently marked.

patch 06 mm/hmm: migrate collection in HMM pagewalk - pmd level
  Q "Can this lead to a use-after-free on an unlocked tail page?"
  A  For that branch, it has to be fault folio. fault_page (of fault folio)
  is always device-private -> the tail new_fault_folio is a ZONE_DEVICE
  page, which reclaim never scans. So not possible.

patch 08 mm/hmm: implement rollback for device page migration in HMM pagewalk
  Q "Will hmm_pfn_rollback_collected() destroy the user's per-PFN request flags?"
  A migration is entirely driven by default_flags, and (HMM_PFN_VALID|HMM_PFN_MIGRATE)
  is used as a sentinel for already pinned and migrate collected pfns. The sentinel
  is safe to be erased from per pfn flags.
  Q "Can this regression lead to memory corruption via an uninitialized PFN
  unlock/put?"
  A  "rollback only unlocks/puts entries carrying the (HMM_PFN_VALID|HMM_PFN_MIGRATE) sentinel
  ,i.e. ones actually collected (locked+ref'd), so no uninitialized pfn is ever unlocked or put
  Q "Is there an infinite loop in hmm_range_fault_locked() when a THP split fails?"
  A yes, fixed in v16. A split failure now fills HMM_PFN_ERROR and returns 0 instead of -EBUSY
  
patch 10 lib/test_hmm: add a new testcase for the migrate on fault
  Q "Will skipping the device page table update here create an inconsistent state
  that migrate_vma_finalize() permanently commits? (in case parallel unmap)"
  A Concurrent unmap is fine. In that case migrate_vma_finalize() frees dst pages,
  and retry migrates on next round. So no ping-pong, it is self-healing.

Link to v15: https://lore.kernel.org/linux-mm/20260924065313.899730-1-mpenttil@redhat.com/

Cc: David Hildenbrand <david@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Leon Romanovsky <leonro@nvidia.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Balbir Singh <balbirs@nvidia.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>

Mika Penttilä (12):
  mm/Kconfig: changes for migrate on fault for device pages
  mm: add helper to convert HMM pfn to migrate pfn
  mm/hmm: preparations for HMM to participate in migration
  mm/hmm: do the plumbing for HMM to participate in migration
  mm/hmm: migrate collection in HMM pagewalk - pte level
  mm/hmm: migrate collection in HMM pagewalk - pmd level
  mm/hmm: add lazy MMU mode support for migration in HMM pagewalk
  mm/hmm: implement rollback for device page migration in HMM pagewalk
  mm: enable device page migration from HMM pagewalk
  lib/test_hmm: add a new testcase for the migrate on fault
  Documentation/mm/hmm: document migration through hmm_range_fault()
  drm/nouveau/svm: add support for migrate on fault

 Documentation/mm/hmm.rst               |  39 +
 drivers/gpu/drm/nouveau/nouveau_dmem.c | 281 +++++++-
 drivers/gpu/drm/nouveau/nouveau_dmem.h |  12 +
 drivers/gpu/drm/nouveau/nouveau_svm.c  | 141 ++--
 drivers/gpu/drm/nouveau/nouveau_svm.h  |   5 +
 include/linux/hmm.h                    |  51 +-
 include/linux/migrate.h                |  59 +-
 lib/test_hmm.c                         | 174 ++++-
 lib/test_hmm_uapi.h                    |  21 +-
 mm/Kconfig                             |   1 +
 mm/hmm.c                               | 959 +++++++++++++++++++++++--
 mm/migrate_device.c                    | 617 +++-------------
 tools/testing/selftests/mm/hmm-tests.c |  54 ++
 13 files changed, 1740 insertions(+), 674 deletions(-)

drm-tip
base-commit: b0311e0de50840c3f35aafa2e95c14bf38f4a767
-- 
2.55.0