On Tue, Jul 14, 2026, at 23:45, David Laight wrote:
> On Tue, 14 Jul 2026 17:06:00 +0200
> "Arnd Bergmann" <[email protected]> wrote:
> > For the 2-level page table, this only concerns pgd_t, which is
> > rarely passed around or returned by value. The 3-level page
> > table has a 64-bit pte_t, which means we probably won't
> > want STRICT_MM_TYPECHECKS there.
>
> Is the 64bit pte_t needed to get the extra modified and accessed
> flags there aren't free bits for in the hardware pte?
> Would it have been possible to use bits that are fixed in the hardware
> pte for the extra bits and write the value to pte[0] and pte[256] fixing
> up the value written to pte[0] (that the hardware reads).
The 64-bit pte_t for 3-level tables (armv7ve/lpae) is the hardware
table entry, following the same format as arm64, and similar to
how x86/pae works.
The special cases with double pmd_t entries four 1024 byte tables to
hold hardware and software entries that David Hildenbrand cited
is only for the old 2-level tables (armv3 through armv7-a).
The Linux pte_t is only 32-bit wide here, and gets copied into
the CPU specific hardware pte in the cpu_*_set_pte_ext() function.
Arnd
