On 2/12/2019 2:59 PM, Bhupesh Sharma wrote: > BTW, in the makedumpfile enablement patch thread for ARMv8.2 LVA > (which I sent out for 52-bit User space VA enablement) (see [0]), Kazu > mentioned that the changes look necessary. > > [0]. http://lists.infradead.org/pipermail/kexec/2019-February/022431.html > > > The increased 'PTRS_PER_PGD' value for such cases needs to be then > > > calculated as is done by the underlying kernel (see > > > 'arch/arm64/include/asm/pgtable-hwdef.h' for details): > > > > > > #define PTRS_PER_PGD (1 << (MAX_USER_VA_BITS - PGDIR_SHIFT)) Yes, this is the reason why makedumpfile needs the MAX_USER_VA_BITS. It is used for pgd_index() also in makedumpfile to walk page tables. /* to find an entry in a page-table-directory */ #define pgd_index(addr) (((addr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)) Thanks, Kazu > > > > > > Also, note that 'arch/arm64/include/asm/memory.h' defines 'MAX_USER_VA_BITS' > > > as 'VA_BITS' in case 'CONFIG_ARM64_USER_VA_BITS_52' is set to 'n': > > > > > > #ifdef CONFIG_ARM64_USER_VA_BITS_52 > > > #define MAX_USER_VA_BITS 52 > > > #else > > > #define MAX_USER_VA_BITS VA_BITS > > > #endif > > > > > > So, makedumpfile will need this symbol exported in vmcore to make the above > > > determination. > > > > > > [0]. http://lists.infradead.org/pipermail/kexec/2019-February/022425.html > > > > > > Thanks, > > > Bhupesh > > > > Thanks > > Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
