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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Jan 23, 2026 at 04:38:49PM +1100, Alistair Popple wrote:
> > >> We need to be a bit careful by what we mean when we say "HMM" in the kernel.
> > >>
> > >> Specifically MIGRATE_PFN_SHIFT is used with migrate_vma/migrate_device, which
> > >> is the migration half of "HMM" which does depend on CONFIG_DEVICE_MIGRATION or
> > >> really just CONFIG_ZONE_DEVICE making it somewhat arch specific.
> > >>
> > >> However hmm_range_fault() does something similar - see the definition of
> > >> hmm_pfn_flags - it actually steals the top 11 bits of a pfn for flags, and it is
> > >> not architecture specific. It only depends on CONFIG_MMU.
> > >
> > > Oh, that is hacky. But are HMM PFNs with any flag exposed to code outside HMM?
> > > Currently, device private needs to reserve PFNs for struct page, so I assume
> > > only the reserved PFNs are seen by outsiders. Otherwise, when outsiders see
> > > a HMM PFN with a flag, pfn_to_page() on such a PFN will read non exist
> > > struct page, right?
> 
> Any user of hmm_range_fault() would be exposed to an issue - most users of
> hmm_range_fault() use it to grab a PFN (ie. physical address) to map into some
> remote page table. So potentially if some important bit in the PFN is dropped
> that could potentially result in users mapping the wrong physical address or
> page.

Trim the quotes guys..

hmm is arguably returning phys_addr_t >> PAGE_SHIFT. This is a lossless
translation because everything is aligned, it isn't hacky.

The value it returns is not a "pfn", it is a hmm structure that has to
be decoded to something else using a hmm helper function.

I think we take a number of liberties going between pte, phys_addr_t,
pfn. If there are arches that use a special encoding for the mm PFN
then range_fault would need to call converter functions to get to/from
phys_addr_t.

Jason