Re: [RFC PATCH 0/6] Remove device private pages from physical address space

[Jordan Niethe <jniethe@nvidia.com>]

Hi,

On 1/12/25 12:51, Matthew Brost wrote:
> On Mon, Dec 01, 2025 at 10:23:32AM +1100, Alistair Popple wrote:
>> On 2025-11-29 at 06:22 +1100, Matthew Brost <matthew.brost@intel.com> wrote...
>>> On Fri, Nov 28, 2025 at 03:41:40PM +1100, Jordan Niethe wrote:
>>>> Today, when creating these device private struct pages, the first step
>>>> is to use request_free_mem_region() to get a range of physical address
>>>> space large enough to represent the devices memory. This allocated
>>>> physical address range is then remapped as device private memory using
>>>> memremap_pages.
>>>>
>>>> Needing allocation of physical address space has some problems:
>>>>
>>>>    1) There may be insufficient physical address space to represent the
>>>>       device memory. KASLR reducing the physical address space and VM
>>>>       configurations with limited physical address space increase the
>>>>       likelihood of hitting this especially as device memory increases. This
>>>>       has been observed to prevent device private from being initialized.
>>>>
>>>>    2) Attempting to add the device private pages to the linear map at
>>>>       addresses beyond the actual physical memory causes issues on
>>>>       architectures like aarch64  - meaning the feature does not work there [0].
>>>>
>>>> This RFC changes device private memory so that it does not require
>>>> allocation of physical address space and these problems are avoided.
>>>> Instead of using the physical address space, we introduce a "device
>>>> private address space" and allocate from there.
>>>>
>>>> A consequence of placing the device private pages outside of the
>>>> physical address space is that they no longer have a PFN. However, it is
>>>> still necessary to be able to look up a corresponding device private
>>>> page from a device private PTE entry, which means that we still require
>>>> some way to index into this device private address space. This leads to
>>>> the idea of a device private PFN. This is like a PFN but instead of
>>>> associating memory in the physical address space with a struct page, it
>>>> associates device memory in the device private address space with a
>>>> device private struct page.
>>>>
>>>> The problem that then needs to be addressed is how to avoid confusing
>>>> these device private PFNs with the regular PFNs. It is the inherent
>>>> limited usage of the device private pages themselves which make this
>>>> possible. A device private page is only used for userspace mappings, we
>>>> do not need to be concerned with them being used within the mm more
>>>> broadly. This means that the only way that the core kernel looks up
>>>> these pages is via the page table, where their PTE already indicates if
>>>> they refer to a device private page via their swap type, e.g.
>>>> SWP_DEVICE_WRITE. We can use this information to determine if the PTE
>>>> contains a normal PFN which should be looked up in the page map, or a
>>>> device private PFN which should be looked up elsewhere.
>>>>
>>>> This applies when we are creating PTE entries for device private pages -
>>>> because they have their own type there are already must be handled
>>>> separately, so it is a small step to convert them to a device private
>>>> PFN now too.
>>>>
>>>> The first part of the series updates callers where device private PFNs
>>>> might now be encountered to track this extra state.
>>>>
>>>> The last patch contains the bulk of the work where we change how we
>>>> convert between device private pages to device private PFNs and then use
>>>> a new interface for allocating device private pages without the need for
>>>> reserving physical address space.
>>>>
>>>> For the purposes of the RFC changes have been limited to test_hmm.c
>>>> updates to the other drivers will be included in the next revision.
>>>>
>>>> This would include updating existing users of memremap_pages() to use
>>>> memremap_device_private_pagemap() instead to allocate device private
>>>> pages. This also means they would no longer need to call
>>>> request_free_mem_region().  An equivalent of devm_memremap_pages() will
>>>> also be necessary.
>>>>
>>>> Users of the migrate_vma() interface will also need to be updated to be
>>>> aware these device private PFNs.
>>>>
>>>> By removing the device private pages from the physical address space,
>>>> this RFC also opens up the possibility to moving away from tracking
>>>> device private memory using struct pages in the future. This is
>>>> desirable as on systems with large amounts of memory these device
>>>> private struct pages use a signifiant amount of memory and take a
>>>> significant amount of time to initialize.
>>>
>>> A couple things.
>>>
>>> - I’m fairly certain that, briefly looking at this, it will break all
>>>    upstream DRM drivers (AMDKFD, Nouveau, Xe / GPUSVM) that use device
>>>    private pages. I looked into what I think conflicts with Xe / GPUSVM,
>>>    and I believe the impact is fairly minor. I’m happy to help by pulling
>>>    this code and fixing up our side.
>>
>> It most certainly will :-) I think Jordan called that out above but we wanted
> 
> I don't always read.
> 
>> to get the design right before spending too much time updating drivers. That
>> said I don't think the driver changes should be extensive, but let us know if
>> you disagree.
> 
> I did a quick look, and I believe it pretty minor (e.g., pfn_to_page is used a
> few places for device pages which would need a refactor, etc...). Maybe
> a bit more, we will find out but not too concerned.

Yes, the existing drivers will need to be updated to use the new
interface. It should be a mechanical enough change that I can include
the driver updates myself in the next revision, but will need some help
testing. Just wanted to get some feedback on the general approach first.

> 
>>
>>> - I’m fully on board with eventually moving to something that uses less
>>>    memory than struct page, and I’m happy to coordinate on future changes.
>>
>> Thanks!
>>
>>> - Before we start coordinating on this patch set, should we hold off until
>>>    the 6.19 cycle, which includes 2M device pages from Balbir [1] (i.e.,
>>>    rebase this series on top of 6.19 once it includes 2M pages)? I suspect
>>>    that, given the scope of this series and Balbir’s, there will be some
>>>    conflicts.
>>
>> Our aim here is to get some review of the design and the patches/implementation
>> for the 6.19 cycle but I agree that this will need to get rebased on top of
>> Balbir's series.
> 
> +1. Will be on the lookout for the next post and pull into 6.19 DRM tree
> and at least test out the Intel stuffi + send fixes if needed.

The next revision I will rebase on Balbir's series.

> 
> I can enable both of you for Intel CI too, just include intel-xe list on
> next post and it will get kicked off and you can find the results on
> patchworks.

This will be very helpful, will do.

Thanks,
Jordan.

> 
> Matt
> 
>>
>>   - Alistair
>>
>>> Matt
>>>
>>> [1] https://patchwork.freedesktop.org/series/152798/
>>>
>>>>
>>>> Testing:
>>>> - selftests/mm/hmm-tests on an amd64 VM
>>>>
>>>> [0] https://lore.kernel.org/lkml/CAMj1kXFZ=4hLL1w6iCV5O5uVoVLHAJbc0rr40j24ObenAjXe9w@mail.gmail.com/
>>>>
>>>> Jordan Niethe (6):
>>>>    mm/hmm: Add flag to track device private PFNs
>>>>    mm/migrate_device: Add migrate PFN flag to track device private PFNs
>>>>    mm/page_vma_mapped: Add flags to page_vma_mapped_walk::pfn to track
>>>>      device private PFNs
>>>>    mm: Add a new swap type for migration entries with device private PFNs
>>>>    mm/util: Add flag to track device private PFNs in page snapshots
>>>>    mm: Remove device private pages from the physical address space
>>>>
>>>>   Documentation/mm/hmm.rst |   9 +-
>>>>   fs/proc/page.c           |   6 +-
>>>>   include/linux/hmm.h      |   5 ++
>>>>   include/linux/memremap.h |  25 +++++-
>>>>   include/linux/migrate.h  |   5 ++
>>>>   include/linux/mm.h       |   9 +-
>>>>   include/linux/rmap.h     |  33 +++++++-
>>>>   include/linux/swap.h     |   8 +-
>>>>   include/linux/swapops.h  | 102 +++++++++++++++++++++--
>>>>   lib/test_hmm.c           |  66 ++++++++-------
>>>>   mm/debug.c               |   9 +-
>>>>   mm/hmm.c                 |   2 +-
>>>>   mm/memory.c              |   9 +-
>>>>   mm/memremap.c            | 174 +++++++++++++++++++++++++++++----------
>>>>   mm/migrate.c             |   6 +-
>>>>   mm/migrate_device.c      |  44 ++++++----
>>>>   mm/mm_init.c             |   8 +-
>>>>   mm/mprotect.c            |  21 +++--
>>>>   mm/page_vma_mapped.c     |  18 +++-
>>>>   mm/pagewalk.c            |   2 +-
>>>>   mm/rmap.c                |  68 ++++++++++-----
>>>>   mm/util.c                |   8 +-
>>>>   mm/vmscan.c              |   2 +-
>>>>   23 files changed, 485 insertions(+), 154 deletions(-)
>>>>
>>>>
>>>> base-commit: e1afacb68573c3cd0a3785c6b0508876cd3423bc
>>>> -- 
>>>> 2.34.1
>>>>