• Aditya Gupta's avatar
    powerpc/vmcore: Add MMU information to vmcoreinfo · 36e826b5
    Aditya Gupta authored
    Since below commit, address mapping for vmemmap has changed for Radix
    MMU, where address mapping is stored in kernel page table itself,
    instead of earlier used 'vmemmap_list'.
    
        commit 368a0590 ("powerpc/book3s64/vmemmap: switch radix to use
        a different vmemmap handling function")
    
    Hence with upstream kernel, in case of Radix MMU, makedumpfile fails
    to do address translation for vmemmap addresses, as it depended on
    vmemmap_list, which can now be empty.
    
    While fixing the address translation in makedumpfile, it was identified
    that currently makedumpfile cannot distinguish between Hash MMU and
    Radix MMU, unless VMLINUX is passed with -x flag to makedumpfile. And
    hence fails to assign offsets and shifts correctly (such as in L4 to
    PGDIR offset calculation in makedumpfile).
    
    For getting the MMU, makedumpfile uses `cur_cpu_spec.mmu_features`.
    
    Add `cur_cpu_spec` symbol and offset of `mmu_features` in the `cpu_spec`
    struct, to VMCOREINFO, so that makedumpfile can assign the offsets
    correctly, without needing a VMLINUX.
    
    Also, even along with `cur_cpu_spec->mmu_features` makedumpfile has to
    depend on the 'MMU_FTR_TYPE_RADIX' flag in mmu_features, implying kernel
    developers need to be cautious of changes to 'MMU_FTR_*' defines.
    
    A more stable approach was suggested in the below thread by contributors:
     https://lore.kernel.org/linuxppc-dev/20230920105706.853626-1-adityag@linux.ibm.com/
    
    The suggestion was to add whether 'RADIX_MMU' is enabled in vmcoreinfo
    
    This patch also implements the suggestion, by adding 'RADIX_MMU' in
    vmcoreinfo, which makedumpfile can use to get whether the crashed system
    had RADIX MMU (in which case 'NUMBER(RADIX_MMU)=1') or not (in which
    case 'NUMBER(RADIX_MMU)=0')
    
    Fixes: 368a0590
    
     ("powerpc/book3s64/vmemmap: switch radix to use a different vmemmap handling function")
    Reported-by: default avatarSachin Sant <sachinp@linux.ibm.com>
    Signed-off-by: default avatarAditya Gupta <adityag@linux.ibm.com>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231023072612.50874-1-adityag@linux.ibm.com
    36e826b5
core.c 7.55 KB