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

["David Hildenbrand (Arm)" <david@xxxxxxxxxx>]

On 7/29/26 13:44, Alexander Gordeev wrote:
> On Wed, Jul 29, 2026 at 01:05:35PM +0200, 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.
>>
>>>
>>> Also, can you envision a case when sizeof(pte_t) != sizeof(hw_pte_t)?
>>> If not, the compile-time check is worth adding.
>>
>> That wouldn't work as is. We'd have to intercept ptep++ and instead have a
>> helper to advance the ptep pointer.
> 
> I think I am missing the point. That is my takeaway from your previous mail:
> https://lore.kernel.org/lkml/31d36023-d728-4eee-90f8-158c7066f565@xxxxxxxxxx/
> 
> <quote>
>>    {
>>       page_table_check_ptes_set(mm, addr, ptep, pte, nr);
>>       for (;;) {
>>               set_pte(ptep, pte);
>>               if (--nr == 0)
>>                       break;
>>   -           ptep++;
>>   +           ptep = hw_pte_next(ptep);
> 
> We should really just let ptep++ work as before.
> 
>>               pte = pte_next_pfn(pte);
>>       }
>>    }
> </quote>
> 
> So are we going after hw_pte_next(ptep) or ptep++?

As I said "That wouldn't work as is. We'd have ".

So in this series here we are clearly going for ptep++ and sizeof(pte_t) ==
sizeof(hw_pte_t).

Because otherwise it wouldn't work.

> 
>> One idea for that would be to let the compiler catch that by marking 
>> hw_pte_t an
>> undefined struct (unknown size), such that the compiler would indicate any 
>> usage
>> of ptep++ properly.
> 
> What is the purpose of that? I mean when pte_t vs hw_pte_t uses are sorted
> out what is the benefit of preventing hw_ptep++?

One thing I could pull out of my magic hat is that you might be able to decide
at runtime the size of your underlying page table entries.

E.g., have 128bit pteval, but allow running on HW with either 64bit ptes or
128bit ptes.

I'm sure there are more challenges to that, but that's an easy thing to imagine.

But again, the focus of this patch set here is ptep++ to just keep working.

-- 
Cheers,

David