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
