* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
[not found] <mailman.13491.1574446920.2486.kexec@lists.infradead.org>
@ 2019-11-22 18:47 ` Dave Anderson
2019-11-23 14:29 ` John Donnelly
0 siblings, 1 reply; 20+ messages in thread
From: Dave Anderson @ 2019-11-22 18:47 UTC (permalink / raw)
To: kexec
----- Original Message -----
>
> Hi Bhupesh,
>
> I recall seeing a reference to modification are needed for the crash CLI also
> to support 5.4.0-rc with your kernel patches cited here.
>
> Where would I find that at ? I don?t see crash on Giblab.
https://github.com/crash-utility/crash
>
> >>>
> >>>
> >>> Hi
> >>>
> >>>
> >>> I was able to fork and clone your work area .
> >>>
> >>> I can see makedumpfile works now !
> >>>
> >>> Fantastic ;; Thank you for your patience !
> >>>
> >>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-22 18:47 ` [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions Dave Anderson
@ 2019-11-23 14:29 ` John Donnelly
0 siblings, 0 replies; 20+ messages in thread
From: John Donnelly @ 2019-11-23 14:29 UTC (permalink / raw)
To: kexec
On 11/22/19 12:47 PM, Dave Anderson wrote:
>
>
> ----- Original Message -----
>>
>> Hi Bhupesh,
>>
>> I recall seeing a reference to modification are needed for the crash CLI also
>> to support 5.4.0-rc with your kernel patches cited here.
>>
>> Where would I find that at ? I don?t see crash on Giblab.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_crash-2Dutility_crash&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=Idg6a1AITiQdn_Ne3jgviBQAPUgdP7PzV00Z47gRHe8&s=g2_ZOSi3nOdUQgU-MvV3nUWcDbnnanKhzPGPUKnFm-A&e=
>
>>
Hi David ,
Thank you. I verified that works with Bhupesh's makedumpfile and 5.4.0
kernel patches.
--
Thank You,
John
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-12-05 20:59 ` Kazuhito Hagio
@ 2019-12-10 14:50 ` Kazuhito Hagio
0 siblings, 0 replies; 20+ messages in thread
From: Kazuhito Hagio @ 2019-12-10 14:50 UTC (permalink / raw)
To: kexec mailing list; +Cc: John Donnelly, Bhupesh Sharma, Bhupesh SHARMA
> -----Original Message-----
> > -----Original Message-----
> > 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 .
>
> Good suggestion.
>
> I wanted the command line that executed makedumpfile in debug message
> as well, so I'll think about adding them together.
Done.
https://sourceforge.net/p/makedumpfile/code/ci/180a3958c30d95cb1d8e8c341baaf267f7eaef89/
Thanks,
Kazu
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-20 16:33 ` John Donnelly
2019-11-21 16:32 ` Bhupesh Sharma
@ 2019-12-05 20:59 ` Kazuhito Hagio
2019-12-10 14:50 ` Kazuhito Hagio
1 sibling, 1 reply; 20+ messages in thread
From: Kazuhito Hagio @ 2019-12-05 20:59 UTC (permalink / raw)
To: John Donnelly; +Cc: Bhupesh Sharma, Bhupesh SHARMA, kexec mailing list
> -----Original Message-----
> 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 .
Good suggestion.
I wanted the command line that executed makedumpfile in debug message
as well, so I'll think about adding them together.
Thanks,
Kazu
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-22 12:30 ` John Donnelly
@ 2019-11-22 14:22 ` John Donnelly
0 siblings, 0 replies; 20+ messages in thread
From: John Donnelly @ 2019-11-22 14:22 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
Hi Bhupesh,
I recall seeing a reference to modification are needed for the crash CLI also to support 5.4.0-rc with your kernel patches cited here.
Where would I find that at ? I don’t see crash on Giblab.
>>>
>>>
>>> Hi
>>>
>>>
>>> I was able to fork and clone your work area .
>>>
>>> I can see makedumpfile works now !
>>>
>>> Fantastic ;; Thank you for your patience !
>>>
>>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-21 21:52 ` John Donnelly
@ 2019-11-22 12:30 ` John Donnelly
2019-11-22 14:22 ` John Donnelly
0 siblings, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-22 12:30 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Nov 21, 2019, at 3:52 PM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
>> On Nov 21, 2019, at 1:20 PM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>>
>>
>>
>>> On Nov 21, 2019, at 10:59 AM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>>>
>>>
>>>
>>>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>>
>>>>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Recent test below
>>>>> This is your makedumpfile pulled from sourceforge .
>>>>
>>>> Do you mean github? I don't remember pushing anything to sourceforge.
>>>> Please share the exact branch name and the source URL for the
>>>> makedumpfile you are using
>>>
>>> Hi, You are correct - GitHub - I used your url posted below ; I do not see the arch/arm64.c changes in the zip version I downloaded .
>>>
>>> I am not a GUI/gitlab user. Can you please send a tarball copy of your working makedumpfile CLI via email and I will verify it works.
>>>
>>
>>
>> Hi
>>
>>
>> I was able to fork and clone your work area .
>>
>> I can see makedumpfile works now !
>>
>> Fantastic ;; Thank you for your patience !
>>
>
>
>
> I did some basic unit tests.
>
> This patch for makedumpfile ONLY WORKS on 5.4.0-rc8 kernel.
>
> It does not work with a previous 4.18 kernel.
>
> Is this suppose to be backwards compatible ?
>
>
Your makedumpfile ran on 4.18. kernel debug output :
kdump: saving vmcore
sadump: unsupported architecture
phys_start phys_end virt_start virt_end
LOAD[ 0] 90080000 91f50000 ffff000010080000 ffff000011f50000
LOAD[ 1] 90000000 92000000 ffff800010000000 ffff800012000000
LOAD[ 2] 928c0000 e3e00000 ffff8000128c0000 ffff800063e00000
LOAD[ 3] ffe00000 fffa0000 ffff80007fe00000 ffff80007ffa0000
LOAD[ 4] 880000000 1000000000 ffff800800000000 ffff800f80000000
LOAD[ 5] 8800000000 bff7030000 ffff808780000000 ffff80bf77030000
LOAD[ 6] bff7060000 bff72b0000 ffff80bf77060000 ffff80bf772b0000
LOAD[ 7] bff72f0000 bff8030000 ffff80bf772f0000 ffff80bf78030000
LOAD[ 8] bff8050000 bff8070000 ffff80bf78050000 ffff80bf78070000
LOAD[ 9] bff80d0000 bff8270000 ffff80bf780d0000 ffff80bf78270000
LOAD[10] bff8280000 bff83d0000 ffff80bf78280000 ffff80bf783d0000
LOAD[11] bff8870000 bffc1a0000 ffff80bf78870000 ffff80bf7c1a0000
LOAD[12] bffc1c0000 bffc1d0000 ffff80bf7c1c0000 ffff80bf7c1d0000
LOAD[13] bffe210000 bfffd10000 ffff80bf7e210000 ffff80bf7fd10000
LOAD[14] bfffd40000 bfffd50000 ffff80bf7fd40000 ffff80bf7fd50000
LOAD[15] bfffe00000 c000000000 ffff80bf7fe00000 ffff80bf80000000
Linux kdump
VMCOREINFO :
OSRELEASE=4.18.0-147.el8.aarch64. <<———— 4.18. kernel
PAGESIZE=65536
page_size : 65536
SYMBOL(init_uts_ns)=ffff0000114657a8
SYMBOL(node_online_map)=ffff00001145d320
SYMBOL(swapper_pg_dir)=ffff000010fa0000
SYMBOL(_stext)=ffff000010081000
SYMBOL(vmap_area_list)=ffff0000114ea220
SYMBOL(mem_section)=ffff80bf7be7c600
LENGTH(mem_section)=1024
SIZE(mem_section)=16
OFFSET(mem_section.section_mem_map)=0
SIZE(page)=64
SIZE(pglist_data)=6656
SIZE(zone)=1728
SIZE(free_area)=88
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)=5984
OFFSET(pglist_data.node_start_pfn)=5992
OFFSET(pglist_data.node_spanned_pages)=6008
OFFSET(pglist_data.node_id)=6016
OFFSET(zone.free_area)=192
OFFSET(zone.vm_stat)=1552
OFFSET(zone.spanned_pages)=96
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)=48
LENGTH(zone.free_area)=14
SYMBOL(log_buf)=ffff00001149f670
SYMBOL(log_buf_len)=ffff00001149f668
SYMBOL(log_first_idx)=ffff000011cc574c
SYMBOL(clear_idx)=ffff000011cc5758
SYMBOL(log_next_idx)=ffff000011cc5748
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)=5
NUMBER(NR_FREE_PAGES)=0
NUMBER(PG_lru)=5
NUMBER(PG_private)=12
NUMBER(PG_swapcache)=9
NUMBER(PG_swapbacked)=18
NUMBER(PG_slab)=8
NUMBER(PG_hwpoison)=21
NUMBER(PG_head_mask)=32768
NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129
NUMBER(HUGETLB_PAGE_DTOR)=2
NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257
NUMBER(VA_BITS)=48
NUMBER(MAX_PHYSMEM_BITS)=52
NUMBER(MAX_USER_VA_BITS)=52
NUMBER(kimage_voffset)=0xfffeffff80000000
NUMBER(PHYS_OFFSET)=0x80000000
KERNELOFFSET=0
CRASHTIME=1574425559
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 : 48 (vmcoreinfo)
page_offset : ffff000000000000 (approximation)
kimage_voffset : fffeffff80000000
max_physmem_bits : 52
section_size_bits: 30
kdump: saving vmcore failed
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=e8_Mv6xWOkVqXTTpFpN44wI2yJoD5vkUr3uCEgxTYjc&s=_BNBMgMWftR4uXgwxGh8zpq7iWJof0CYkYnFYEPNOSU&e=
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-21 19:20 ` John Donnelly
@ 2019-11-21 21:52 ` John Donnelly
2019-11-22 12:30 ` John Donnelly
0 siblings, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-21 21:52 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Nov 21, 2019, at 1:20 PM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
>> On Nov 21, 2019, at 10:59 AM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>>
>>
>>
>>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>
>>>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Recent test below
>>>> This is your makedumpfile pulled from sourceforge .
>>>
>>> Do you mean github? I don't remember pushing anything to sourceforge.
>>> Please share the exact branch name and the source URL for the
>>> makedumpfile you are using
>>
>> Hi, You are correct - GitHub - I used your url posted below ; I do not see the arch/arm64.c changes in the zip version I downloaded .
>>
>> I am not a GUI/gitlab user. Can you please send a tarball copy of your working makedumpfile CLI via email and I will verify it works.
>>
>
>
> Hi
>
>
> I was able to fork and clone your work area .
>
> I can see makedumpfile works now !
>
> Fantastic ;; Thank you for your patience !
>
I did some basic unit tests.
This patch for makedumpfile ONLY WORKS on 5.4.0-rc8 kernel.
It does not work with a previous 4.18 kernel.
Is this suppose to be backwards compatible ?
>
>
>
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=qzvbWFi4jiB58rXJ3WWlsBhMaCE050Bl3F630z5cxZQ&s=06v1wglHOpFgEZdqr06KBrYVdp3SPc6GuQ88d6Mo_24&e=
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-21 16:59 ` John Donnelly
@ 2019-11-21 19:20 ` John Donnelly
2019-11-21 21:52 ` John Donnelly
0 siblings, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-21 19:20 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Nov 21, 2019, at 10:59 AM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>
>>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Recent test below
>>> This is your makedumpfile pulled from sourceforge .
>>
>> Do you mean github? I don't remember pushing anything to sourceforge.
>> Please share the exact branch name and the source URL for the
>> makedumpfile you are using
>
> Hi, You are correct - GitHub - I used your url posted below ; I do not see the arch/arm64.c changes in the zip version I downloaded .
>
> I am not a GUI/gitlab user. Can you please send a tarball copy of your working makedumpfile CLI via email and I will verify it works.
>
Hi
I was able to fork and clone your work area .
I can see makedumpfile works now !
Fantastic ;; Thank you for your patience !
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-21 16:32 ` Bhupesh Sharma
@ 2019-11-21 16:59 ` John Donnelly
2019-11-21 19:20 ` John Donnelly
0 siblings, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-21 16:59 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>
>> Hi,
>>
>> Recent test below
>> This is your makedumpfile pulled from sourceforge .
>
> Do you mean github? I don't remember pushing anything to sourceforge.
> Please share the exact branch name and the source URL for the
> makedumpfile you are using
Hi, You are correct - GitHub - I used your url posted below ; I do not see the arch/arm64.c changes in the zip version I downloaded .
I am not a GUI/gitlab user. Can you please send a tarball copy of your working makedumpfile CLI via email and I will verify it works.
>
>> It would be helpful if you bumped the VERSION and DATE to be certain we are using the correct pieces .
>
> You can print makedumpfile version in your scriptware. It lets you
> know the latest makedumpfile version. Note that this indicates the
> latest released version and not the development branch. The
> development branch is for things under test (like this change) and
> being stabilized whereas the released version contains a bump to a new
> VERSION number and DATE at which a release is made.
>
> # makedumpfile -v
> makedumpfile: version 1.6.6 (released on 27 Jun 2019)
> lzo enabled
>
>> 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 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
>
> You again seem to be using an old/incorrect version of makedumpfile.
> As you can see here from [0] and [1] the newer makedumpfile patches I
> posted print where the va_bits are derived from - _stext symbol or
> vmcoreinfo.
>
> Since you are running a kdump test, it should print something like
> this for va_bits if you have the correct makedumpfile changes compiled
> in and installed (via make install) - notice the source from where
> va_bits is determined properly is printed in brackets:
> phys_base : 80000000 (vmcoreinfo)
>
> max_mapnr : 97fd00
> There is enough free memory to be done in one cycle.
>
> Buffer size for the cyclic mode: 2490176
> va_bits : 48 (vmcoreinfo)
> page_offset : ffff000000000000 (approximation)
> kimage_voffset : fffeffff8fc00000
> max_physmem_bits : 52
> section_size_bits: 30
>
> Regards,
> Bhupesh
>
> [0]. <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bhupesh-2Dsharma_makedumpfile_blob_52-2Dbit-2Dva-2Dsupport-2Dvia-2Dvmcore-2Dupstream-2Dv4_arch_arm64.c-23L468&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=fTxuFz0gFYqF-yeTV5k-4ve75ozUz7jUQ2H70G6l3Ew&s=5KmTLEoAJrWyjQx6U6QkzZyiqBw8rGIzrSdF5Bc1ui4&e= >
> [1]. <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bhupesh-2Dsharma_makedumpfile_blob_52-2Dbit-2Dva-2Dsupport-2Dvia-2Dvmcore-2Dupstream-2Dv4_arch_arm64.c-23L511&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=fTxuFz0gFYqF-yeTV5k-4ve75ozUz7jUQ2H70G6l3Ew&s=e_1XFoI356GjqUeFk-99QB4wCe-pAUuzZTHirfBMtbQ&e= >
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=fTxuFz0gFYqF-yeTV5k-4ve75ozUz7jUQ2H70G6l3Ew&s=fasW4oWXU7Sb-TR6YC5qCtqErxdidkMgCKZtKMp7Ans&e=
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-20 16:33 ` John Donnelly
@ 2019-11-21 16:32 ` Bhupesh Sharma
2019-11-21 16:59 ` John Donnelly
2019-12-05 20:59 ` Kazuhito Hagio
1 sibling, 1 reply; 20+ messages in thread
From: Bhupesh Sharma @ 2019-11-21 16:32 UTC (permalink / raw)
To: John Donnelly
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>
> Hi,
>
> Recent test below
> This is your makedumpfile pulled from sourceforge .
Do you mean github? I don't remember pushing anything to sourceforge.
Please share the exact branch name and the source URL for the
makedumpfile you are using
> It would be helpful if you bumped the VERSION and DATE to be certain we are using the correct pieces .
You can print makedumpfile version in your scriptware. It lets you
know the latest makedumpfile version. Note that this indicates the
latest released version and not the development branch. The
development branch is for things under test (like this change) and
being stabilized whereas the released version contains a bump to a new
VERSION number and DATE at which a release is made.
# makedumpfile -v
makedumpfile: version 1.6.6 (released on 27 Jun 2019)
lzo enabled
> 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 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
You again seem to be using an old/incorrect version of makedumpfile.
As you can see here from [0] and [1] the newer makedumpfile patches I
posted print where the va_bits are derived from - _stext symbol or
vmcoreinfo.
Since you are running a kdump test, it should print something like
this for va_bits if you have the correct makedumpfile changes compiled
in and installed (via make install) - notice the source from where
va_bits is determined properly is printed in brackets:
phys_base : 80000000 (vmcoreinfo)
max_mapnr : 97fd00
There is enough free memory to be done in one cycle.
Buffer size for the cyclic mode: 2490176
va_bits : 48 (vmcoreinfo)
page_offset : ffff000000000000 (approximation)
kimage_voffset : fffeffff8fc00000
max_physmem_bits : 52
section_size_bits: 30
Regards,
Bhupesh
[0]. <https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-va-support-via-vmcore-upstream-v4/arch/arm64.c#L468>
[1]. <https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-va-support-via-vmcore-upstream-v4/arch/arm64.c#L511>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 19:01 ` Bhupesh Sharma
2019-11-18 19:12 ` John Donnelly
@ 2019-11-20 16:33 ` John Donnelly
2019-11-21 16:32 ` Bhupesh Sharma
2019-12-05 20:59 ` Kazuhito Hagio
1 sibling, 2 replies; 20+ messages in thread
From: John Donnelly @ 2019-11-20 16:33 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
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
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 19:12 ` John Donnelly
@ 2019-11-18 20:00 ` John Donnelly
0 siblings, 0 replies; 20+ messages in thread
From: John Donnelly @ 2019-11-18 20:00 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
> On Nov 18, 2019, at 1:12 PM, John Donnelly <john.p.donnelly@oracle.com> wrote:
>
> I will update and test a new kernel
>
>
>
>
>> 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
>>
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 19:01 ` Bhupesh Sharma
@ 2019-11-18 19:12 ` John Donnelly
2019-11-18 20:00 ` John Donnelly
2019-11-20 16:33 ` John Donnelly
1 sibling, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-18 19:12 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
I will update and test a new kernel
> 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
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yz8krT-bd__omR2VsWUhXea3iPBB4JUhUgw_0MCBasE&s=8r5b0cjNbaH8SDXv6Kvx1NZv7Cy9KHFsmYsNwSG2eMw&e=
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 17:11 ` John Donnelly
@ 2019-11-18 19:01 ` Bhupesh Sharma
2019-11-18 19:12 ` John Donnelly
2019-11-20 16:33 ` John Donnelly
0 siblings, 2 replies; 20+ messages in thread
From: Bhupesh Sharma @ 2019-11-18 19:01 UTC (permalink / raw)
To: John Donnelly
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
kexec mailing list, Kazuhito Hagio, Prabhakar Kushwaha,
Bhupesh SHARMA
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:
<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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 5:12 ` Prabhakar Kushwaha
2019-11-18 17:11 ` John Donnelly
@ 2019-11-18 18:56 ` Bhupesh Sharma
1 sibling, 0 replies; 20+ messages in thread
From: Bhupesh Sharma @ 2019-11-18 18:56 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: John Donnelly, Prabhakar Kushwaha,
Ganapatrao Prabhakerrao Kulkarni, kexec mailing list,
Kazuhito Hagio, Bhupesh SHARMA
Hi Prabhakar,
On Mon, Nov 18, 2019 at 10:42 AM 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:
> > http://lists.infradead.org/pipermail/kexec/2019-March/022534.html
> > - 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:
> > http://lists.infradead.org/pipermail/kexec/2019-February/022456.html
> > - 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:
> > http://lists.infradead.org/pipermail/kexec/2019-February/022424.html
> > (ARMv8.2-LPA)
> > http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
> > (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]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
> > [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
> >
> > 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://git.code.sf.net/p/makedumpfile/code
> (devel branch)
>
> Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
Thanks for testing the patchset.
Regards,
Bhupesh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-18 5:12 ` Prabhakar Kushwaha
@ 2019-11-18 17:11 ` John Donnelly
2019-11-18 19:01 ` Bhupesh Sharma
2019-11-18 18:56 ` Bhupesh Sharma
1 sibling, 1 reply; 20+ messages in thread
From: John Donnelly @ 2019-11-18 17:11 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Prabhakar Kushwaha, Ganapatrao Prabhakerrao Kulkarni,
Bhupesh Sharma, kexec mailing list, Kazuhito Hagio,
bhupesh.linux
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 ?
Thanks !
> k
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=yaIr-WZNVYousyfxDrAInpTgEW0nPszxryxHQtvXrDQ&s=2n_H5NpvTcxlrmKKuAqZtmrMsLwrb8Y5l5kKKyjnJ8g&e=
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-12 11:08 Bhupesh Sharma
2019-11-13 21:59 ` Kazuhito Hagio
@ 2019-11-18 5:12 ` Prabhakar Kushwaha
2019-11-18 17:11 ` John Donnelly
2019-11-18 18:56 ` Bhupesh Sharma
1 sibling, 2 replies; 20+ messages in thread
From: Prabhakar Kushwaha @ 2019-11-18 5:12 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: John Donnelly, Prabhakar Kushwaha,
Ganapatrao Prabhakerrao Kulkarni, kexec mailing list,
Kazuhito Hagio, bhupesh.linux
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:
> http://lists.infradead.org/pipermail/kexec/2019-March/022534.html
> - 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:
> http://lists.infradead.org/pipermail/kexec/2019-February/022456.html
> - 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:
> http://lists.infradead.org/pipermail/kexec/2019-February/022424.html
> (ARMv8.2-LPA)
> http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
> (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]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
> [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
>
> 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://git.code.sf.net/p/makedumpfile/code
(devel branch)
Tested-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
--pk
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-13 21:59 ` Kazuhito Hagio
@ 2019-11-14 19:10 ` Bhupesh Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Bhupesh Sharma @ 2019-11-14 19:10 UTC (permalink / raw)
To: Kazuhito Hagio; +Cc: John Donnelly, bhupesh.linux, kexec
Hi Kazu,
On Thu, Nov 14, 2019 at 3:31 AM Kazuhito Hagio <k-hagio@ab.jp.nec.com> wrote:
>
> Hi Bhupesh,
>
> Thanks for the updated patchset.
>
> I'm taking a look at this, but I will be out of office from tomorrow
> until Nov 29th, so please expect some (long) delays in my response..
Thanks a lot for your message. Sure, let's discuss this more when you
return from your holidays.
Regards,
Bhupesh
>
> Thanks,
> Kazu
>
> > -----Original Message-----
> > Changes since v3:
> > ----------------
> > - v3 can be seen here:
> > http://lists.infradead.org/pipermail/kexec/2019-March/022534.html
> > - 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:
> > http://lists.infradead.org/pipermail/kexec/2019-February/022456.html
> > - 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:
> > http://lists.infradead.org/pipermail/kexec/2019-February/022424.html
> > (ARMv8.2-LPA)
> > http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
> > (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]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
> > [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
> >
> > 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(-)
> >
> > --
> > 2.7.4
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
2019-11-12 11:08 Bhupesh Sharma
@ 2019-11-13 21:59 ` Kazuhito Hagio
2019-11-14 19:10 ` Bhupesh Sharma
2019-11-18 5:12 ` Prabhakar Kushwaha
1 sibling, 1 reply; 20+ messages in thread
From: Kazuhito Hagio @ 2019-11-13 21:59 UTC (permalink / raw)
To: Bhupesh Sharma; +Cc: John Donnelly, bhupesh.linux, kexec
Hi Bhupesh,
Thanks for the updated patchset.
I'm taking a look at this, but I will be out of office from tomorrow
until Nov 29th, so please expect some (long) delays in my response..
Thanks,
Kazu
> -----Original Message-----
> Changes since v3:
> ----------------
> - v3 can be seen here:
> http://lists.infradead.org/pipermail/kexec/2019-March/022534.html
> - 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:
> http://lists.infradead.org/pipermail/kexec/2019-February/022456.html
> - 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:
> http://lists.infradead.org/pipermail/kexec/2019-February/022424.html
> (ARMv8.2-LPA)
> http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
> (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]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
> [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
>
> 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(-)
>
> --
> 2.7.4
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
@ 2019-11-12 11:08 Bhupesh Sharma
2019-11-13 21:59 ` Kazuhito Hagio
2019-11-18 5:12 ` Prabhakar Kushwaha
0 siblings, 2 replies; 20+ messages in thread
From: Bhupesh Sharma @ 2019-11-12 11:08 UTC (permalink / raw)
To: kexec; +Cc: John Donnelly, bhsharma, bhupesh.linux, Kazuhito Hagio
Changes since v3:
----------------
- v3 can be seen here:
http://lists.infradead.org/pipermail/kexec/2019-March/022534.html
- 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:
http://lists.infradead.org/pipermail/kexec/2019-February/022456.html
- 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:
http://lists.infradead.org/pipermail/kexec/2019-February/022424.html
(ARMv8.2-LPA)
http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
(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]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
[1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
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(-)
--
2.7.4
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-12-10 14:51 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.13491.1574446920.2486.kexec@lists.infradead.org>
2019-11-22 18:47 ` [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions Dave Anderson
2019-11-23 14:29 ` John Donnelly
2019-11-12 11:08 Bhupesh Sharma
2019-11-13 21:59 ` Kazuhito Hagio
2019-11-14 19:10 ` Bhupesh Sharma
2019-11-18 5:12 ` Prabhakar Kushwaha
2019-11-18 17:11 ` John Donnelly
2019-11-18 19:01 ` Bhupesh Sharma
2019-11-18 19:12 ` John Donnelly
2019-11-18 20:00 ` John Donnelly
2019-11-20 16:33 ` John Donnelly
2019-11-21 16:32 ` Bhupesh Sharma
2019-11-21 16:59 ` John Donnelly
2019-11-21 19:20 ` John Donnelly
2019-11-21 21:52 ` John Donnelly
2019-11-22 12:30 ` John Donnelly
2019-11-22 14:22 ` John Donnelly
2019-12-05 20:59 ` Kazuhito Hagio
2019-12-10 14:50 ` Kazuhito Hagio
2019-11-18 18:56 ` Bhupesh Sharma
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.