Hi, Recent test below > On Nov 18, 2019, at 1:01 PM, Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote: > > Hi John, > > On Mon, Nov 18, 2019 at 10:41 PM John Donnelly > <john.p.donnelly@xxxxxxxxxx> wrote: >> >> Hi, >> >> See below . >> >>> On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha <prabhakar.pkin@xxxxxxxxx> wrote: >>> >>> Re-sending in plain text mode. >>> >>> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote: >>>> >>>> Changes since v3: >>>> ---------------- >>>> - v3 can be seen here: >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DMarch_022534.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=tXNSuQSbZP03h4vwmeTiXu_9gUn9e_rY470TmwrNQSU&e= >>>> - Added a new patch (via [PATCH 4/4]) which marks '--mem-usage' option as >>>> unsupported for arm64 architecture. With the newer arm64 kernels >>>> supporting 48-bit/52-bit VA address spaces and keeping a single >>>> binary for supporting the same, the address of >>>> kernel symbols like _stext, which could be earlier used to determine >>>> VA_BITS value, can no longer to determine whether VA_BITS is set to 48 >>>> or 52 in the kernel space. Hence for now, it makes sense to mark >>>> '--mem-usage' option as unsupported for arm64 architecture until >>>> we have more clarity from arm64 kernel maintainers on how to manage >>>> the same in future kernel/makedumpfile versions. >>>> >>>> Changes since v2: >>>> ---------------- >>>> - v2 can be seen here: >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DFebruary_022456.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=Hd_PJi1aXdKh1jmODxHa_VFNy8HwvSYxCBH-wDitxkI&e= >>>> - I missed some comments from Kazu sent on the LVA v1 patch when I sent >>>> out the v2. So, addressing them now in v3. >>>> - Also added a patch that adds a tree-wide feature to read >>>> 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available). >>>> >>>> Changes since v1: >>>> ---------------- >>>> - v1 was sent as two separate patches: >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DFebruary_022424.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=ZB2bTeP-9z7PVIUhtVjv0ao8wqWFJSOWTnH-kqj_LV8&e= >>>> (ARMv8.2-LPA) >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DFebruary_022425.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=OzCS7jUUiiB4YZPbD5xo1GRQtOtsgpHtnwQDV7AgiMs&e= >>>> (ARMv8.2-LVA) >>>> - v2 combined the two in a single patchset and also addresses Kazu's >>>> review comments. >>>> >>>> This patchset adds support for ARMv8.2 extensions in makedumpfile code. >>>> I cover the following two cases with this patchset: >>>> - 48-bit kernel VA + 52-bit PA (LPA) >>>> - 52-bit kernel VA (LVA) + 52-bit PA (LPA) >>>> - 48-bit kernel VA + 52-bit user-space VA (LVA) >>>> - 52-bit kernel VA + 52-bit user-space VA (Full LVA) >>>> >>>> This has been tested for the following user-cases: >>>> 1. Creating a dumpfile using /proc/vmcore, >>>> 2. Creating a dumpfile using /proc/kcore, and >>>> 3. Post-processing a vmcore. >>>> >>>> I have tested this patchset on the following platforms, with kernels >>>> which support/do-not-support ARMv8.2 features: >>>> 1. CPUs which don't support ARMv8.2 features, e.g. qualcomm-amberwing, >>>> ampere-osprey. >>>> 2. Prototype models which support ARMv8.2 extensions (e.g. ARMv8 FVP >>>> simulation model). >>>> >>>> Also a preparation patch has been added in this patchset which adds a >>>> common feature for archs (except arm64, for which similar support is >>>> added via subsequent patch) to retrieve 'MAX_PHYSMEM_BITS' from >>>> vmcoreinfo (if available). >>>> >>>> I recently posted two kernel patches (see [0] and [1]) which append >>>> 'TCR_EL1.T1SZ' and 'MAX_PHYSMEM_BITS' to vmcoreinfo in the kernel >>>> code, so that user-space code can benefit from the same. >>>> >>>> This patchset ensures backward compatibility for kernel versions in >>>> which 'TCR_EL1.T1SZ' and 'MAX_PHYSMEM_BITS' are not available in >>>> vmcoreinfo. >>>> >>>> [0]. https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DNovember_023960.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=Aiwq36rzITwEmdA6KIDK54J-AWZKSMBcrGOG2sspXAg&e= >>>> [1]. https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DNovember_023962.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=q9nNMgIGrTZoTuSZ2xymuuXN2gqhXnfNlnRPRifV6CI&e= >>>> >>>> Cc: John Donnelly <john.p.donnelly@xxxxxxxxxx> >>>> Cc: Kazuhito Hagio <k-hagio@xxxxxxxxxxxxx> >>>> Cc: kexec@xxxxxxxxxxxxxxxxxxx >>>> >>>> Bhupesh Sharma (4): >>>> tree-wide: Retrieve 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available) >>>> makedumpfile/arm64: Add support for ARMv8.2-LPA (52-bit PA support) >>>> makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA >>>> support) >>>> makedumpfile: Mark --mem-usage option unsupported for arm64 >>>> >>>> arch/arm.c | 8 +- >>>> arch/arm64.c | 438 ++++++++++++++++++++++++++++++++++++++++++--------------- >>>> arch/ia64.c | 7 +- >>>> arch/ppc.c | 8 +- >>>> arch/ppc64.c | 49 ++++--- >>>> arch/s390x.c | 29 ++-- >>>> arch/sparc64.c | 9 +- >>>> arch/x86.c | 34 +++-- >>>> arch/x86_64.c | 27 ++-- >>>> makedumpfile.c | 7 + >>>> makedumpfile.h | 3 +- >>>> 11 files changed, 439 insertions(+), 180 deletions(-) >>>> >>>> -- >>> >>> Tested this patch-set on Marvell's TX2 platform on top >>> commit(82e6cce2219a) of https://urldefense.proofpoint.com/v2/url?u=https-3A__git.code.sf.net_p_makedumpfile_code&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=Eg6LcBiLs9MlQf3jlvdRnuaQ-DODCNA9UKWnQgg9wX8&e= >>> (devel branch) >>> >>> Tested-by: Prabhakar Kushwaha <pkushwaha@xxxxxxxxxxx> >>> >>> —p >> >> >> Hi , >> >> I tested this on a Arm 8.1v platform with a 5.4.rc4 kernel and it fails : >> >> >> >> kdump: saving vmcore-dmesg.txt >> kdump: saving vmcore-dmesg.txt complete >> kdump: saving vmcore >> sadump: unsuppor phys_start phys_end virt_start virt_end >> LOAD[ 0] 92a80000 95040000 ffff800010080000 ffff800012640000 >> LOAD[ 1] 90000000 92000000 ffffc00010000000 ffffc00012000000 >> LOAD[ 2] 928c0000 dfe00000 ffffc000128c0000 ffffc0005fe00000 >> LOAD[ 3] ffe00000 fffa0000 ffffc0007fe00000 ffffc0007ffa0000 >> LOAD[ 4] 880000000 1000000000 ffffc00800000000 ffffc00f80000000 >> LOAD[ 5] 8800000000 bff7010000 ffffc08780000000 ffffc0bf77010000 >> LOAD[ 6] bff7040000 bff7740000 ffffc0bf77040000 ffffc0bf77740000 >> LOAD[ 7] bff7770000 bff8020000 ffffc0bf77770000 ffffc0bf78020000 >> LOAD[ 8] bff8050000 bff8070000 ffffc0bf78050000 ffffc0bf78070000 >> LOAD[ 9] bff80d0000 bff8270000 ffffc0bf780d0000 ffffc0bf78270000 >> LOAD[10] bff8280000 bff83d0000 ffffc0bf78280000 ffffc0bf783d0000 >> LOAD[11] bff8870000 bffc1a0000 ffffc0bf78870000 ffffc0bf7c1a0000 >> LOAD[12] bffc1c0000 bffc1d0000 ffffc0bf7c1c0000 ffffc0bf7c1d0000 >> LOAD[13] bffe210000 bfffd10000 ffffc0bf7e210000 ffffc0bf7fd10000 >> LOAD[14] bfffd40000 bfffd50000 ffffc0bf7fd40000 ffffc0bf7fd50000 >> LOAD[15] bfffe00000 c000000000 ffffc0bf7fe00000 ffffc0bf80000000 >> Linux kdump >> VMCOREINFO : >> OSRELEASE=5.4.0-0 >> PAGESIZE=65536 >> page_size : 65536 >> SYMBOL(init_uts_ns)=ffff800011ac5ca8 >> SYMBOL(node_online_map)=ffff800011abd490 >> SYMBOL(swapper_pg_dir)=ffff800011340000 >> SYMBOL(_stext)=ffff800010081000 >> SYMBOL(vmap_area_list)=ffff800011b89898 >> SYMBOL(mem_section)=ffff00bf7be7e300 >> LENGTH(mem_section)=64 >> SIZE(mem_section)=16 >> OFFSET(mem_section.section_mem_map)=0 >> SIZE(page)=64 >> SIZE(pglist_data)=6912 >> SIZE(zone)=1920 >> SIZE(free_area)=104 >> SIZE(list_head)=16 >> SIZE(nodemask_t)=8 >> OFFSET(page.flags)=0 >> OFFSET(page._refcount)=52 >> OFFSET(page.mapping)=24 >> OFFSET(page.lru)=8 >> OFFSET(page._mapcount)=48 >> OFFSET(page.private)=40 >> OFFSET(page.compound_dtor)=16 >> OFFSET(page.compound_order)=17 >> OFFSET(page.compound_head)=8 >> OFFSET(pglist_data.node_zones)=0 >> OFFSET(pglist_data.nr_zones)=6176 >> OFFSET(pglist_data.node_start_pfn)=6184 >> OFFSET(pglist_data.node_spanned_pages)=6200 >> OFFSET(pglist_data.node_id)=6208 >> OFFSET(zone.free_area)=192 >> OFFSET(zone.vm_stat)=1728 >> OFFSET(zone.spanned_pages)=104 >> OFFSET(free_area.free_list)=0 >> OFFSET(list_head.next)=0 >> OFFSET(list_head.prev)=8 >> OFFSET(vmap_are14 >> SYMBOL(logt_idx)=ffff800011ed7294 >> SYMBOL(clear_idx)=ffff800011ed4ce0 >> og)=16 >> OFFSET(printk_log.ts_nsec)=0 >> OFFSET(printk_log.len)=8 >> OFFSET(printk_log.text_len)=10 >> OFFSET(printk_log.dict_len)=12 >> LENGTH(free_area.free_list)=6 >> NUMBER(NR_FREE_PAGES)=0 >> NUMBER(PG_lru)=4 >> NUMBER(PG_private)=13 >> NUMBER(PG_swapcache)=10 >> NUMBER(PG_swapbacked)=19 >> NUMBER(PG_slab)=9 >> NUMBER(PG_hwpoison)=22 >> NUMBER(PG_head_mask)=65536 >> NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129 >> NUMBER(HUGETLB_PAGE_DTOR)=2 >> NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257 >> NUMBER(VA_BITS)=52 >> NUMBER(kimage_voffset)=0xffff7fff7d600000 >> NUMBER(PHYS_OFFSET)=0x80000000 >> KERNELOFFSET=0 >> CRASHTIME=1574096441 >> >> phys_base : 80000000 (vmcoreinfo) >> >> max_mapnr : c00000 >> There is enough free memory to be done in one cycle. >> >> Buffer size for the cyclic mode: 3145728 >> va_bits : 47 >> page_offset : ffffc00000000000 >> calculate_plat_config: Parm64: Can't detd >> [FAILED] Failed to start Kdump Vmcore Save Service. >> >> >> < reboot > >> >> >> CAN YOU ADD A VERSION BANNER TO THE MAKEDUMPFILE SO WE CAN BE SURE OF WHAT IS BEING USED WHEN IT STARTS ? > > It will not work with default vanila (upstream) kernel as you need to > apply the patches which export TCR_EL1.T1SZ and 'MAX_PHYSMEM_BITS' in > vmcoreinfo (see [0] and [1] for details). > > I mentioned the same in the cover letter (see: > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DNovember_023963.html&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yz8krT-bd__omR2VsWUhXea3iPBB4JUhUgw_0MCBasE&s=Itbzun1ta89dvRLgYqXtplaQcQKMncXV4ewUs0Lpf7o&e= >) > > [0]. https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DNovember_023960.html&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yz8krT-bd__omR2VsWUhXea3iPBB4JUhUgw_0MCBasE&s=fqNL97Va3Cc3_pym_lQXB_dnJZxU98KTioa_CHMzzoc&e= > [1]. https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DNovember_023962.html&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yz8krT-bd__omR2VsWUhXea3iPBB4JUhUgw_0MCBasE&s=En-sz176a1irpuRC9XXUqRn3SL5eqLPR8VN05ajhB5A&e= > > Regards, > Bhupesh > This is your makedumpfile pulled from sourceforge . It would be helpful if you bumped the VERSION and DATE to be certain we are using the correct pieces . kdump: saving vmcore makedumpfile 1.6.6, 27 Jun 2019. sadump: unsupported architecture phys_start phys_end virt_start virt_end LOAD[ 0] 92a80000 94fe0000 ffff800010080000 ffff8000125e0000 LOAD[ 1] 90000000 92000000 ffffc00010000000 ffffc00012000000 LOAD[ 2] 928c0000 dfe00000 ffffc000128c0000 ffffc0005fe00000 LOAD[ 3] ffe00000 fffa0000 ffffc0007fe00000 ffffc0007ffa0000 LOAD[ 4] 880000000 1000000000 ffffc00800000000 ffffc00f80000000 LOAD[ 5] 8800000000 bff7030000 ffffc08780000000 ffffc0bf77030000 LOAD[ 6] bff7060000 bff72b0000 ffffc0bf77060000 ffffc0bf772b0000 LOAD[ 7] bff72f0000 bff8030000 ffffc0bf772f0000 ffffc0bf78030000 LOAD[ 8] bff8050000 bff8070000 ffffc0bf78050000 ffffc0bf78070000 LOAD[ 9] bff80d0000 bff8270000 ffffc0bf780d0000 ffffc0bf78270000 LOAD[10] bff8280000 bff83d0000 ffffc0bf78280000 ffffc0bf783d0000 LOAD[11] bff8870000 bffc1a0000 ffffc0bf78870000 ffffc0bf7c1a0000 LOAD[12] bffc1c0000 bffc1d0000 ffffc0bf7c1c0000 ffffc0bf7c1d0000 LOAD[13] bffe210000 bfffd10000 ffffc0bf7e210000 ffffc0bf7fd10000 LOAD[14] bfffd40000 bfffd50000 ffffc0bf7fd40000 ffffc0bf7fd50000 LOAD[15] bfffe00000 c000000000 ffffc0bf7fe00000 ffffc0bf80000000 Linux kdump VMCOREINFO : OSRELEASE=5.4.0-rc8 PAGESIZE=65536 page_size : 65536 SYMBOL(init_uts_ns)=ffff800011a65ca8 SYMBOL(node_online_map)=ffff800011a5d490 SYMBOL(swapper_pg_dir)=ffff8000112f0000 SYMBOL(_stext)=ffff800010081000 SYMBOL(vmap_area_list)=ffff800011b29a98 SYMBOL(mem_section)=ffff00bf7be7e300 LENGTH(mem_section)=64 SIZE(mem_section)=16 OFFSET(mem_section.section_mem_map)=0 NUMBER(MAX_PHYSMEM_BITS)=48 SIZE(page)=64 SIZE(pglist_data)=6912 SIZE(zone)=1920 SIZE(free_area)=104 SIZE(list_head)=16 SIZE(nodemask_t)=8 OFFSET(page.flags)=0 OFFSET(page._refcount)=52 OFFSET(page.mapping)=24 OFFSET(page.lru)=8 OFFSET(page._mapcount)=48 OFFSET(page.private)=40 OFFSET(page.compound_dtor)=16 OFFSET(page.compound_order)=17 OFFSET(page.compound_head)=8 OFFSET(pglist_data.node_zones)=0 OFFSET(pglist_data.nr_zones)=6176 OFFSET(pglist_data.node_start_pfn)=6184 OFFSET(pglist_data.node_spanned_pages)=6200 OFFSET(pglist_data.node_id)=6208 OFFSET(zone.free_area)=192 OFFSET(zone.vm_stat)=1728 OFFSET(zone.spanned_pages)=104 OFFSET(free_area.free_list)=0 OFFSET(list_head.next)=0 OFFSET(list_head.prev)=8 OFFSET(vmap_area.va_start)=0 OFFSET(vmap_area.list)=40 LENGTH(zone.free_area)=14 SYMBOL(log_buf)=ffff800011ada808 SYMBOL(log_buf_len)=ffff800011ada810 SYMBOL(log_first_idx)=ffff800011e772d4 SYMBOL(clear_idx)=ffff800011e74d20 SYMBOL(log_next_idx)=ffff800011e772e0 SIZE(printk_log)=16 OFFSET(printk_log.ts_nsec)=0 OFFSET(printk_log.len)=8 OFFSET(printk_log.text_len)=10 OFFSET(printk_log.dict_len)=12 LENGTH(free_area.free_list)=6 NUMBER(NR_FREE_PAGES)=0 NUMBER(PG_lru)=4 NUMBER(PG_private)=13 NUMBER(PG_swapcache)=10 NUMBER(PG_swapbacked)=19 NUMBER(PG_slab)=9 NUMBER(PG_hwpoison)=22 NUMBER(PG_head_mask)=65536 NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129 NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257 NUMBER(VA_BITS)=48 NUMBER(kimage_voffset)=0xffff7fff7d600000 NUMBER(PHYS_OFFSET)=0x80000000 NUMBER(tcr_el1_t1sz)=0x10 KERNELOFFSET=0 CRASHTIME=1574266958 phys_base : 80000000 (vmcoreinfo) max_mapnr : c00000 There is enough free memory to be done in one cycle. Buffer size for the cyclic mode: 3145728 va_bits : 47 page_offset : ffffc00000000000 kdump: saving vmcore failed ================ — kernel patch applied to 5.4.0-rc8 vabits_actual variable on arm64 indicates the actual VA space size, and allows a single binary to support both 48-bit and 52-bit VA spaces. If the ARMv8.2-LVA optional feature is present, and we are running with a 64KB page size; then it is possible to use 52-bits of address space for both userspace and kernel addresses. However, any kernel binary that supports 52-bit must also be able to fall back to 48-bit at early boot time if the hardware feature is not present. Since TCR_EL1.T1SZ indicates the size offset of the memory region addressed by TTBR1_EL1 (and hence can be used for determining the vabits_actual value) it makes more sense to export the same in vmcoreinfo rather than vabits_actual variable, as the name of the variable can change in future kernel versions, but the architectural constructs like TCR_EL1.T1SZ can be used better to indicate intended specific fields to user-space. User-space utilities like makedumpfile and crash-utility, need to read/write this value from/to vmcoreinfo for determining if a virtual address lies in the linear map range. The user-space computation for determining whether an address lies in the linear map range is the same as we have in kernel-space: #define __is_lm_address(addr) (!(((u64)addr) & BIT(vabits_actual - 1))) Copied from kexec working group Signed-off-by: John Donnelly <john.p.donnelly@xxxxxxxxxx> --- arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/kernel/crash_core.c | 10 ++++++++++ kernel/crash_core.c | 1 + 3 files changed, 12 insertions(+) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h index 3df60f97da1f..a0f789fa25f3 100644 --- a/arch/arm64/include/asm/pgtable-hwdef.h +++ b/arch/arm64/include/asm/pgtable-hwdef.h @@ -215,6 +215,7 @@ #define TCR_TxSZ(x) (TCR_T0SZ(x) | TCR_T1SZ(x)) #define TCR_TxSZ_WIDTH 6 #define TCR_T0SZ_MASK (((UL(1) << TCR_TxSZ_WIDTH) - 1) << TCR_T0SZ_OFFSET) +#define TCR_T1SZ_MASK (((UL(1) << TCR_TxSZ_WIDTH) - 1) << TCR_T1SZ_OFFSET) #define TCR_EPD0_SHIFT 7 #define TCR_EPD0_MASK (UL(1) << TCR_EPD0_SHIFT) diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c index ca4c3e12d8c5..f7027142030f 100644 --- a/arch/arm64/kernel/crash_core.c +++ b/arch/arm64/kernel/crash_core.c @@ -7,6 +7,14 @@ #include <linux/crash_core.h> #include <asm/memory.h> +static inline u64 get_tcr_el1_t1sz(void); + +static inline u64 get_tcr_el1_t1sz(void) +{ + return (read_sysreg(tcr_el1) & TCR_T1SZ_MASK) >> TCR_T1SZ_OFFSET; +} + + void arch_crash_save_vmcoreinfo(void) { VMCOREINFO_NUMBER(VA_BITS); @@ -15,5 +23,7 @@ void arch_crash_save_vmcoreinfo(void) kimage_voffset); vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n", PHYS_OFFSET); + vmcoreinfo_append_str("NUMBER(tcr_el1_t1sz)=0x%llx\n", + get_tcr_el1_t1sz()); vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset()); } diff --git a/kernel/crash_core.c b/kernel/crash_core.c index f0061fec74df..157d0c2ec277 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -469,6 +469,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); + VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS); #endif VMCOREINFO_STRUCT_SIZE(page); VMCOREINFO_STRUCT_SIZE(pglist_data); -- 2.20.1 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
