Re: [RFC PATCH 02/34] ARM: mm: make 2-level pgd_t a scalar

"Arnd Bergmann" <[email protected]> Wed, 15 Jul 2026 08:11:39 +0200
Newsgroups org.kernel.vger.linux-csky,dev.linux.lists.loongarch,org.infradead.lists.kvm-riscv,org.infradead.lists.linux-riscv,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-mips,org.kernel.vger.linux-openrisc
Message-ID <[email protected]>
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