On 03/04/2019 13:37, Robin Murphy wrote: > [ +Steve ] > > Hi Anshuman, > > On 03/04/2019 05:30, Anshuman Khandual wrote: <snip> >> diff --git a/arch/arm64/include/asm/pgtable.h >> b/arch/arm64/include/asm/pgtable.h >> index de70c1e..858098e 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -355,6 +355,18 @@ static inline int pmd_protnone(pmd_t pmd) >> } >> #endif >> +#if (CONFIG_PGTABLE_LEVELS > 2) >> +#define pmd_large(pmd) (pmd_val(pmd) && !(pmd_val(pmd) & >> PMD_TABLE_BIT)) >> +#else >> +#define pmd_large(pmd) 0 >> +#endif >> + >> +#if (CONFIG_PGTABLE_LEVELS > 3) >> +#define pud_large(pud) (pud_val(pud) && !(pud_val(pud) & >> PUD_TABLE_BIT)) >> +#else >> +#define pud_large(pmd) 0 >> +#endif > > These seem rather different from the versions that Steve is proposing in > the generic pagewalk series - can you reach an agreement on which > implementation is preferred? Indeed this doesn't match the version in my series although is quite similar. My desire is that p?d_large represents the hardware architectural definition of large page/huge page/section (pick your naming). Although now I look more closely this is actually broken in my series (I'll fix that up and send a new version shortly) - p?d_sect() is similarly conditional. Is there a good reason not to use the existing p?d_sect() macros available on arm64? I'm also surprised by the CONFIG_PGTABLE_LEVEL conditions as they don't match the existing conditions for p?d_sect(). Might be worth double checking it actually does what you expect. Steve
