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

On 7/29/26 13:44, Alexander Gordeev wrote:

On Wed, Jul 29, 2026 at 01:05:35PM +0200, David Hildenbrand (Arm) wrote:

quoted

On 7/29/26 12:13, Alexander Gordeev wrote:

quoted

...

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.

quoted

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@kernel.org/ (local)

<quote>

quoted

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

quoted

              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.

quoted

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