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

From: "David Hildenbrand (Arm)" <[email-masked]>
Date: Tue, 3 Mar 2026 17:52:07 +0100

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 <[email-masked]>
> ---
> 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