[PATCH v6 03/13] mm/migrate_device: Make migrate_device_{pfns,range}() take mpfns

David Hildenbrand (Arm) david at kernel.org
Wed Mar 4 03:52:07 AEDT 2026


On 2/2/26 12:36, Jordan Niethe wrote:
> A future change will remove device private pages from the physical
> address space. This will mean that device private pages no longer have a
> pfn.
> 
> This causes an issue for migrate_device_{pfns,range}() which take pfn
> parameters. Depending on if the device is MEMORY_DEVICE_PRIVATE or
> MEMORY_DEVICE_COHERENT will effect how that parameter should be
> interpreted.
> 
> A MIGRATE_PFN flag will be introduced that distinguishes between mpfns
> that contain a pfn vs an offset into device private memory, we will take
> advantage of that here.
> 
> Update migrate_device_{pfns,range}() to take a mpfn instead of pfn.
> 
> Update the users of migrate_device_{pfns,range}() to pass in an mpfn.
> 
> To support this change, update
> dpagemap_devmem_ops::populate_devmem_pfn() to instead return mpfns and
> rename accordingly.
> 
> Signed-off-by: Jordan Niethe <jniethe at nvidia.com>
> ---
> v2: New to series
> v3: No change
> ---

The fact that "migrate pfns" are just dressed as ordinary pfns is
confusing and error prone, especially when we suddenly have to derive
from the variable name whether something is a pfn or an mpfn ...

Something to think about would be treating migrate pfns as opaque
objects and move from misleading "unsigned long" to something like

typedef struct migrate_pfn {
	unsigned long data;
} migrate_pfn_t;

And providing proper accessors.

That would make it much clearer when passing these things around what
they are ... and the compiler can easily catch bugs.

-- 
Cheers,

David


More information about the Linuxppc-dev mailing list