On 9/25/26 12:07, Christoph Hellwig wrote: > Who is going to use this? The series seems to lack an actual user for it.
Two users: For one, existing migrate_vma_setup() callers, unchanged. The series reworks migrate_vma_setup() to collect via hmm_range_fault() internally (it sets HMM_PFN_REQ_MIGRATE and calls migrate_hmm_range_setup(), mm/migrate_device.c). So every in-tree migrate_vma consumer — nouveau, amdgpu/amdkfd, drm/xe via drm_pagemap, lib/test_hmm — runs on the new path. Second, the point is to fault-in and migrate in a single page-table walk instead of the 2–3 walks drivers do today . It can be driven by hmm_range_fault() directly instead of ping-ponging between hmm fault and migrate_vma interfaces, and lib/test_hmm exercises it. migrate.vma is also populated now for free on fault path. These are aimed at SVM like migrate-on-fault, and is motivated by Alistair Popple's experiments with current interfaces, where the redundant-walk overhead showed up clearly in perf traces. The unified page table walker also avoids some limitations in current collecting interfaces that can crash when raced with unmap. So this is a building block for migrate-on-fault but delivers immediate in-tree effects by unifying, refactoring and more robust collecting. --Mika
