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: <http://lists.infradead.org/pipermail/kexec/2019-November/023963.html>) [0]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html Regards, Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
