[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