From: Mika Penttilä <[email protected]> Describe the two new MIGRATE_VMA_FAULT / MIGRATE_VMA_WRITE flags of migrate_vma_setup(), and add a section on driving the migration collection phase directly from hmm_range_fault() via HMM_PFN_REQ_MIGRATE and migrate_hmm_range_setup().
Signed-off-by: Mika Penttilä <[email protected]> --- Documentation/mm/hmm.rst | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst index fc1b8dc19825..58424e5f5873 100644 --- a/Documentation/mm/hmm.rst +++ b/Documentation/mm/hmm.rst @@ -348,6 +348,13 @@ between device driver specific code and shared common code: Currently only anonymous private VMA ranges can be migrated to or from system memory and device private memory. + By default only pages already present are collected. Two additional flags + ask migrate_vma_setup() to fault in missing pages first: + + * ``MIGRATE_VMA_FAULT`` faults in missing pages with read access. + * ``MIGRATE_VMA_WRITE`` faults in missing pages with write access + (implies faulting). + One of the first steps migrate_vma_setup() does is to invalidate other device's MMUs with the ``mmu_notifier_invalidate_range_start()`` and ``mmu_notifier_invalidate_range_end()`` calls around the page table @@ -427,6 +434,38 @@ between device driver specific code and shared common code: The lock can now be released. +Migration collection through hmm_range_fault() +============================================== + +The collection phase of migration (steps 1 and 2 above) can also be driven by +hmm_range_fault() directly, sharing its page table walk. This lets a driver +fault in and collect a range for migration in one walk, which is useful for +migrate on fault. + +To do so, the driver sets ``HMM_PFN_REQ_MIGRATE`` in ``range->default_flags`` +and points ``range->migrate`` at a ``struct migrate_vma`` it has filled in +(``flags``, ``src``, ``dst``, ``pgmap_owner``). Usually ``HMM_PFN_REQ_FAULT`` +(and ``HMM_PFN_REQ_WRITE``) is set as well, so missing pages are faulted in +before being collected. The mmap_read_lock() has to be held for the whole +migration, since the vma must stay stable. + +hmm_range_fault() collects the entries the same way migrate_vma_setup() does, +taking a folio reference, locking it and installing a migration PTE. Collected +entries are marked with ``HMM_PFN_VALID | HMM_PFN_MIGRATE`` in +``range->hmm_pfns``. If the page tables change while locks are dropped the +partially collected entries are rolled back automatically. + +After hmm_range_fault() returns, the driver calls:: + + void migrate_hmm_range_setup(struct hmm_range *range); + +to translate ``range->hmm_pfns`` into ``migrate->src[]`` (``migrate->dst[]`` is +zeroed) and initialize ``migrate->cpages`` and ``migrate->npages``. From here on +the ``range->migrate`` struct is ready for the rest of the flow (steps 3 +onwards), i.e. migrate_vma_pages() and migrate_vma_finalize(). This should be +called even on error, since hmm_range_fault() may have collected part of the +range before failing. + Exclusive access memory ======================= -- 2.55.0
