Re: [PATCH RFC 00/11] mm: distinguish PTE table storage from PTE values

[Muhammad Usama Anjum <usama.anjum@xxxxxxx>]

On 29/07/2026 12:52 pm, David Hildenbrand (Arm) wrote:
> On 7/29/26 13:33, Muhammad Usama Anjum wrote:
>> On 29/07/2026 12:05 pm, David Hildenbrand (Arm) wrote:
>>> On 7/29/26 12:13, Alexander Gordeev wrote:
>>>> ...
>>>>
>>>> May be we need the generic hw_pte_t implementation as { pte_t pte; }
>>>> right away?
>>>
>>> Indeed, that makes sense. We just need a way for the architecture to opt-in 
>>> that
>>> it did the conversion.
>> Yeah and architecture cannot opt-in until its converted. So we should leave
>> it to architecture to define hw_pte_t.
> 
> In the context of this series, we should have something like an
> CONFIG_ARCH_HAS_XXX and select the definition based on that.
> 
> So we'd have a generic variant.
I'll add CONFIG_ARCH_HAS_XXX config in generic version.

I don't understand why generic code would define hw_pte_t if arch optionally
opts-in.

Are you saying pte_t may have different definition in different arches. But
the hw_pte_t would always be structure of pte_t. Hence definition

typedef struct { pte_t __pte; }; hw_pte_t;

can be moved to the generic code?

Moving definition to generic side is fine at this point in time. But if
a arch wants to hw_pte_t opaque and don't want the generic code to perform
arithmatic (ptep++), it'll not work.

-- 
Thanks,
Usama