Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





> On Nov 18, 2019, at 1:12 PM, John Donnelly <john.p.donnelly@xxxxxxxxxx> wrote:
> 
> I will update and test a new kernel 
> 
> 
> 
> 
>> 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
>> 



Hi,


Has anyone verified that crash CLI works  with 5.4.0 ?  Or you are simply relying on getting a vmcore file ? Are there dependencies on crash CLI ?



— snip —   




_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux