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