mm: opaque hardware page-table entry handles

[David Hildenbrand (Arm)]

[...]

>>
>> 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.

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]

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 :)

[1] https://lore.kernel.org/all/08ecabe9-0664-4aea-82fb-f9cb1739f762@kernel.org/

[...]

>>
>> 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.

-- 
Cheers,

David