Re: [PATCH v2 00/11] Remove device private pages from physical address space

[Jordan Niethe <jniethe@nvidia.com>]

Hi,

On 8/1/26 12:49, Alistair Popple wrote:
> On 2026-01-08 at 07:06 +1100, Andrew Morton <akpm@linux-foundation.org> wrote...
>> On Wed,  7 Jan 2026 20:18:12 +1100 Jordan Niethe <jniethe@nvidia.com> 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.
>>
>> Welcome to Linux MM.  That's a heck of an opening salvo ;)
>>
>>> 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].
>>
>> Can you better help us understand the seriousness of these problems?
>> How much are our users really hurting from this?
> 
> Hopefully the rest of the thread helps address this.
> 
>>> Seeking opinions on using the mpfns like this or if a new type would be
>>> preferred.
>>
>> Whose opinions?  IOW, can you suggest who you'd like to see review this
>> work?
> 
> I was going to see if I could find Lorenzo on IRC as I think it would be good to
> get his opinion on the softleaf changes. And probably Felix's (and my) opinion
> for the mpfn changes (I don't think Intel currently uses DEVICE_COHERENT which
> this bit has the biggest impact on).

It also effects intel's driver because the mpfn changes also touch
migrate_device_pfns() which gets used there.

So also looking for Matthew's thoughts here as well as Felix's.

> 
>>>
>>> * NOTE: I will need help in testing the driver changes *
>>>
>>
>> Again, please name names ;)  I'm not afraid to prod.
> 
> As noted in the other thread Intel Xe and AMD GPU are the biggest. Matthew has
> already offered to help test Intel (thanks!) and Felix saw the v1 posting so
> hoping he can help with testing there.

Yes, I should also be able to get run this through the intel-xe CI.
The other area that needs testing is the powerpc ultravisor.
(+cc) Madhavan Srinivasan - are you able to help here?

> 
>> I'm reluctant to add this to mm.git's development/testing branches at
>> this time.  Your advice on when you think we're ready for that step
>> would be valuable, thanks.
> 
> Will leave the readiness call to Jordan, but we were hoping to get
> this in for the v6.20 merge window if at all possible. I realise
> we're probably running late given we generally like to let stuff
> settle in development/testing branches for a while prior to the
> merge window, but it did have an early round of review last year
> (https://lore.kernel.org/linux-mm/20251128044146.80050-1-jniethe@nvidia.com/)
> and I reviewed it internally and it looked very reasonable.

Matt has kindly said that he is reviewing the patches so will wait for 
his feedback.
I'd also like to get the results from the intel-xe CI first.

Andrew, I'll advise on including in mm.git after these steps - but I don't
expect any major issues at this stage.  The changes have been solid with the
hmm selftests and with updating our out of tree driver to use the new
interface.


Thanks,
Jordan.

> 
> I will take a look at this latest version later today.
> 
>   - Alistair