Le 10/04/2024 à 21:58, Peter Xu a écrit : >> >> e500 has two modes: 32 bits and 64 bits. >> >> For 32 bits: >> >> 8xx is the only one handling it through HW-assisted pagetable walk hence >> requiring a 2-level whatever the pagesize is. > > Hmm I think maybe finally I get it.. > > I think the confusion came from when I saw there's always such level-2 > table described in Figure 8-5 of the manual: > > https://www.nxp.com/docs/en/reference-manual/MPC860UM.pdf Yes indeed that figure is confusing. Table 8-1 gives a pretty good idea of what is required. We only use MD_CTR[TWAM] = 1 > > So I suppose you meant for 8M, the PowerPC 8xx system hardware will be > aware of such 8M pgtable (from level-1's entry, where it has bit 28-29 set > 011b), then it won't ever read anything starting from "Level-2 Descriptor > 1" (but only read the only entry "Level-2 Descriptor 0"), so fundamentally > hugepd format must look like such for 8xx? > > But then perhaps it's still compatible with cont-pte because the rest > entries (pte index 1+) will simply be ignored by the hardware? Yes, still compatible with CONT-PTE allthough things become tricky because you need two page tables to get the full 8M so that's a kind of cont-PMD down to PTE level, as you can see in my RFC series. > >> >> On e500 it is all software so pages 2M and larger should be cont-PGD (by >> the way I'm a bit puzzled that on arches that have only 2 levels, ie PGD >> and PTE, the PGD entries are populated by a function called PMD_populate()). > > Yeah.. I am also wondering whether pgd_populate() could also work there > (perhaps with some trivial changes, or maybe not even needed..), as when > p4d/pud/pmd levels are missing, linux should just do something like an > enforced cast from pgd_t* -> pmd_t* in this case. > > I think currently they're already not pgd, as __find_linux_pte() already > skipped pgd unconditionally: > > pgdp = pgdir + pgd_index(ea); > p4dp = p4d_offset(pgdp, ea); > Yes that's what is confusing, some parts of code considers we have only a PGD and a PT while other parts consider we have only a PMD and a PT >> >> Current situation for 8xx is illustrated here: >> https://github.com/linuxppc/wiki/wiki/Huge-pages#8xx >> >> I also tried to better illustrate e500/32 here: >> https://github.com/linuxppc/wiki/wiki/Huge-pages#e500 >> >> For 64 bits: >> We have PTE/PMD/PUD/PGD, no P4D >> >> See arch/powerpc/include/asm/nohash/64/pgtable-4k.h > > We don't have anything that is above pud in this category, right? That's > what I read from your wiki (and thanks for providing that in the first > place; helps a lot for me to understand how it works on PowerPC). Yes thanks to Michael and Aneesh who initiated that Wiki page. > > I want to make sure if I can move on without caring on p4d/pgd leafs like > what we do right now, even after if we can remove hugepd for good, in this > case since p4d always missing, then it's about whether "pud|pmd|pte_leaf()" > can also cover the pgd ones when that day comes, iiuc. I guess so but I'd like Aneesh and/or Michael to confirm as I'm not an expert on PPC64. Christophe
