Re: mm: opaque hardware page-table entry handles

[Muhammad Usama Anjum]

Hi,

[Moved some already involved people to To. So they can help with the plan
details mentioned below.]

On 07/07/2026 2:17 pm, David Hildenbrand (Arm) wrote:
> [...]
> 
>>>
>>> typedef struct {
>>> 	pte_t __pte;
>>> } hw_pte_t;
>>>
>>> And then simply use
>>>
>>> hw_pte_t *hptep;
>> Make sense. So you have suggested to just hide put pte_t inside a structure
>> instead of complex structure of pointer. I've tried to implement and it reduces
>> churn enormously.
> 
> Right. And for most architectures we can probable leave both types be the same
> under the hood.
> 
> So we'd only have to convert common code first, and can then e.g., look into
> making architectures that care about the difference (e.g., arm64) actually have
> it be two separate types.
It makes a lot of sense.

Let's even divide the series into more parts as there are several places where
conversion is controversial. (Xi Yan had mentioned one example earlier in this
thread.) Most of those controversial conversions are pmd related. I propose
that we convert pte_t first, then pmd_t and others. It'll keep the number of
patches manageable and easier to review. 

I think wider agreement for this approach will be very helpful before I post the
actual code.

> 
> Just an idea to further reduce the churn and limit it only to core code (because
> I saw some very ugly stuff in some arch code that would make such a conversion
> harder).
> 
> [...]
> 
>>> Why do we need this and what would we use it for?
>> The idea was that there should be two different functions to read value. Let's
>> leave this out of the first initial series. It is complicating the original
>> proposal.
> 
> Right, let's leave that out for now. I'm currently working with Levi on an
> approach that tries to avoid the overhead due to READ_ONCE with folded page
> tables. [1]
So you are referring to page folding improvements. I also stumbled upon those
while doing a dirty implementation.

> 
> We're still struggling with some bits, but looks like we can make it fly and
> have it be fairly robust.
> 
> With that, maybe there is no reason left to have separate pXXp_get() vs.
> pXXp_get_once(). TBD :)
Yeah, I was reviewing that series earlier today. I've not looked deeply, but it
seems there are still a lot of cases where (mostly) pmd is getting dereferenced
directly. To complete the conversion, direct dereferences need to be converted
into an API. I've been thinking if there should be a dereference macro or we
must always use pmdp_get() even though it ensures ordering. It may add excessive 
ordering in some functions if pmdp_get() is getting called multiple times. But
storing its output in a tmp variable would solve this. 

Do you agree with converting all direct dereferences into pXXp_get()?

> 
> [1] https://lore.kernel.org/all/08ecabe9-0664-4aea-82fb-f9cb1739f762@xxxxxxxxxx/
> 
> [...]
> 
>>>
>>> I'm still not sure about the _once() really, and if we need that right now. We
>>> survived without is so far, why do we need it now?
>> The idea is to convert all current pXXp_get() to pXXp_get_once() and convert raw
>> dereference to pXXp_get(). Let's keep this idea separate for the other work. Let's
>> discuss it later sometime again later.
> 
> Sounds good.

I've tried to do conversions already. Converting by call hierarchy wise is very
difficult and error prune.

Converting component by component (such as page walk, huge page) is also difficult
as code is tangled. Some helper which is getting used in one component is also used
in another component.

I see the following way forward:
* Add the new type
* Identify which functions need explicitly pointer to a stack variable. These
  must not be converted. These variables must be renamed to a common name. For
  pte_t pointers on stack some functions already use ptentp, which is unique name
  if we look at generic code. So ptentp would be used for all such variables.
* One commit per controversial change would be done at this point. We need new
  separate function for stack types. Also we can do more renaming to a name which
  will not be converted.
* Run Coccinelle script directory-by-directory which would ignore converting any
  ptentp (and similarly for other types). Coccinelle doesn't converts in some case
  (pte_t *a. *b) which can be done by hand at this point.
* Update any remaining functions

-- 
Thanks,
Usama