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

[John Donnelly <john.p.donnelly@oracle.com>]

Hi,

  Recent test below 


> On Nov 18, 2019, at 1:01 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> 
> Hi John,
> 
> On Mon, Nov 18, 2019 at 10:41 PM John Donnelly
> <john.p.donnelly@oracle.com> wrote:
>> 
>> Hi,
>> 
>> See below .
>> 
>>> On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
>>> 
>>> Re-sending in plain text mode.
>>> 
>>> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma <bhsharma@redhat.com> 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@oracle.com>
>>>> Cc: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
>>>> Cc: kexec@lists.infradead.org
>>>> 
>>>> 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@marvell.com>
>>> 
>>> —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@oracle.com>
---
 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec