Re: mm: opaque hardware page-table entry handles

[Alexander Gordeev]

On Fri, Jul 24, 2026 at 08:47:30AM +0200, Alexander Gordeev wrote:
> > > What about unlinked/temporary page tables in memory?
> > I've thought about it multiple times and it is best to represent using hw_p*_t
> > type. Even though they aren't installed or live, but it makes more sense to use
> > hardware type as they may get installed soon. 
> 
> My concern is in the long run the dedicated hw_pte_t APIs may want to do something
> special with a hw_pXX_t pointers: accounting, HW resources allocation, tracking,
> link a shadow, whatever. Some of those might be wrong when applied against a
> temporary copy, even though that copy constitutes a formatted page table in memory.
...
> > The difference between representing stack type with pte_t and unlinked/temporary
> > page table with hw_pte_t is that unlinked/temporary page tables are complete tables
> > and not just some copied value.
...
> Sorry for bringing up the classification question from your original
> message again:
> 
> - "a pointer to a live entry in the hardware page table, or
> - "the pointer points into real page-table memory and that table is complete,
>    whether or not it's linked in yet"
> 
> ...but the semantics of the former still looks to me stronger than one of
> the latter. I am afraid this question is going to pop up time and again.

This is yet another example of why we need to stick to the live entry
requirement hw_pXX_t pointers:

https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@xxxxxxx/

> 1. https://lore.kernel.org/linux-s390/71acca838bd3c5bb690ccb4a36313a889a48f383.1784121418.git.agordeev@xxxxxxxxxxxxx/

Thanks!