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

On Fri, Jan 23, 2026 at 04:38:49PM +1100, Alistair Popple wrote:

quoted

quoted

quoted

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