> > Essentially, on 32-bit 2-level ARM, the PGD is merely indexed by the > virtual address. As far as the kernel is concerned, each entry is > 64-bit, and the generic kernel code has no business accessing that > through the pgd pointer. > > The pgd pointer is passed through the PUD and PMD levels, where it is > typecast down through the kernel layers to a pmd_t pointer, where it > becomes a 32-bit quantity. This results in only the _first_ level 1 > pointer being dereferenced by kernel code to a 32-bit pmd_t quantity. > pmd_page_vaddr() converts this pmd_t quantity to a pte pointer (which > points at the software level 2 page tables, not the hardware page > tables.) As an aside, my understanding of Linux's pgtable model differs from what you describe. As I understand it, Linux's logical page table model has 5 levels (pgd, p4d, pud, pmd, pte). If an arch doesn't support all 5 levels, then the middle levels can be folded away (p4d first, then pud, then pmd). But the core-mm still logically walks all 5 levels. So if the HW supports 2 levels, those levels are (pgd, pte). But you are suggesting that arm exposes pmd and pte, which is not what Linux expects? (Perhaps you call it the pmd in the arch, but that is being folded and accessed through the pgd helpers in core code, I believe? > > So, as I'm now being told that the kernel wants to dereference the > pgd level despite the model I describe above, alarm bells are ringing. > I want full information please. > This is not new; the kernel already dereferences the pgd pointers. Thanks, Ryan
