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

2019-12-10 Thread Kazuhito Hagio 
> -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

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

2019-12-05 Thread Kazuhito Hagio 
> -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

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

2019-11-23 Thread John Donnelly 

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

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

2019-11-22 Thread Dave Anderson 



- 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

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

2019-11-22 Thread John Donnelly 


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

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

2019-11-22 Thread John Donnelly 


> On Nov 21, 2019, at 3:52 PM, John Donnelly  wrote:
> 
> 
> 
>> On Nov 21, 2019, at 1:20 PM, John Donnelly  
>> wrote:
>> 
>> 
>> 
>>> On Nov 21, 2019, at 10:59 AM, John Donnelly  
>>> wrote:
>>> 
>>> 
>>> 
 On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma  wrote:
 
> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly 
>  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] 9008 91f5 1008 11f5
LOAD[ 1] 9000 9200 80001000 80001200
LOAD[ 2] 928c e3e0 8000128c 800063e0
LOAD[ 3] ffe0 fffa 80007fe0 80007ffa
LOAD[ 4]88000   10 8008 800f8000
LOAD[ 5]   88   bff703 80878000 80bf7703
LOAD[ 6]   bff706   bff72b 80bf7706 80bf772b
LOAD[ 7]   bff72f   bff803 80bf772f 80bf7803
LOAD[ 8]   bff805   bff807 80bf7805 80bf7807
LOAD[ 9]   bff80d   bff827 80bf780d 80bf7827
LOAD[10]   bff828   bff83d 80bf7828 80bf783d
LOAD[11]   bff887   bffc1a 80bf7887 80bf7c1a
LOAD[12]   bffc1c   bffc1d 80bf7c1c 80bf7c1d
LOAD[13]   bffe21   bfffd1 80bf7e21 80bf7fd1
LOAD[14]   bfffd4   bfffd5 80bf7fd4 80bf7fd5
LOAD[15]   bfffe0   c0 80bf7fe0 80bf8000
Linux kdump
VMCOREINFO   :
  OSRELEASE=4.18.0-147.el8.aarch64.  <<  4.18. kernel 
  PAGESIZE=65536
page_size: 65536
  SYMBOL(init_uts_ns)=114657a8
  SYMBOL(node_online_map)=1145d320
  SYMBOL(swapper_pg_dir)=10fa
  SYMBOL(_stext)=10081000
  SYMBOL(vmap_area_list)=114ea220
  SYMBOL(mem_section)=80bf7be7c600
  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)=1149f670
  SYMBOL(log_buf_len)=1149f668
  SYMBOL(log_first_idx)=11cc574c
  SYMBOL(clear_idx)=11cc5758
  SYMBOL(log_next_idx)=11cc5748
  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)=0xfffe8000
  NUMBER(PHYS_OFFSET)=0x8000
  KERNELOFFSET=0
  CRASHTIME=1574425559

phys_base: 8000 (vmcoreinfo)

max_mapnr: c0
There is enough fr

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

2019-11-21 Thread John Donnelly 



> On Nov 21, 2019, at 1:20 PM, John Donnelly  wrote:
> 
> 
> 
>> On Nov 21, 2019, at 10:59 AM, John Donnelly  
>> wrote:
>> 
>> 
>> 
>>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma  wrote:
>>> 
 On Wed, Nov 20, 2019 at 10:03 PM John Donnelly 
  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

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

2019-11-21 Thread John Donnelly 



> On Nov 21, 2019, at 10:59 AM, John Donnelly  
> wrote:
> 
> 
> 
>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma  wrote:
>> 
>>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly  
>>> 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

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

2019-11-21 Thread John Donnelly 



> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma  wrote:
> 
>> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly  
>> 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)
> lzoenabled
> 
>> kdump: saving vmcore
>> makedumpfile 1.6.6, 27 Jun 2019.
>> sadump: unsupported architecture
>>  phys_start phys_end   virt_start virt_end
>> LOAD[ 0] 92a8 94fe 80001008 8000125e
>> LOAD[ 1] 9000 9200 c0001000 c0001200
>> LOAD[ 2] 928c dfe0 c000128c c0005fe0
>> LOAD[ 3] ffe0 fffa c0007fe0 c0007ffa
>> LOAD[ 4]88000   10 c008 c00f8000
>> LOAD[ 5]   88   bff703 c0878000 c0bf7703
>> LOAD[ 6]   bff706   bff72b c0bf7706 c0bf772b
>> LOAD[ 7]   bff72f   bff803 c0bf772f c0bf7803
>> LOAD[ 8]   bff805   bff807 c0bf7805 c0bf7807
>> LOAD[ 9]   bff80d   bff827 c0bf780d c0bf7827
>> LOAD[10]   bff828   bff83d c0bf7828 c0bf783d>
>> LOAD[11]   bff887   bffc1a c0bf7887 c0bf7c1a
>> LOAD[12]   bffc1c   bffc1d c0bf7c1c c0bf7c1d
>> LOAD[13]   bffe21   bfffd1 c0bf7e21 c0bf7fd1
>> LOAD[14]   bfffd4   bfffd5 c0bf7fd4 c0bf7fd5
>> LOAD[15]   bfffe0   c0 c0bf7fe0 c0bf8000
>> Linux kdump
>> VMCOREINFO   :
>  OSRELEASE=5.4.0-rc8
>  PAGESIZE=65536
>> page_size: 65536
>  SYMBOL(init_uts_ns)=800011a65ca8
>  SYMBOL(node_online_map)=800011a5d490
>  SYMBOL(swapper_pg_dir)=8000112f
>  SYMBOL(_stext)=800010081000
>  SYMBOL(vmap_area_list)=800011b29a98
>  SYMBOL(mem_section)=00bf7be7e300
>  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)=800011ada808
>  SYMBOL(log_buf_len)=800011ada810
>  SYMBOL(log_first_idx)=800011e772d4
>  SYMBOL(clear_idx)=800011e74d20
>  SYMBOL(log_next_idx)=800011e772e0
>  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)=0x7fff7d60
>  NUMBER(PHYS_OFFSET)=0x8000
>  NUMBER(tcr_el1_t1sz)=0x10
>  KERNELOFFSET=0
>  CRASHTIME=1574266958
> 
>> phys_base: 8000 (vmcoreinfo)
> 
>> max_mapnr: c0
>> There is enough free memory to be done in one cycle.
> 
>> Buffer size for the cyclic mode: 3145728
>> va_bits  : 47
>> page_offset  : c000
>> 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: 8000 (vmcoreinfo)
> 
> max_mapnr: 97fd00
> Th

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

2019-11-21 Thread Bhupesh Sharma 
> On Wed, Nov 20, 2019 at 10:03 PM John Donnelly  
> 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)
lzoenabled

> kdump: saving vmcore
> makedumpfile 1.6.6, 27 Jun 2019.
> sadump: unsupported architecture
>   phys_start phys_end   virt_start virt_end
> LOAD[ 0] 92a8 94fe 80001008 8000125e
> LOAD[ 1] 9000 9200 c0001000 c0001200
> LOAD[ 2] 928c dfe0 c000128c c0005fe0
> LOAD[ 3] ffe0 fffa c0007fe0 c0007ffa
> LOAD[ 4]88000   10 c008 c00f8000
> LOAD[ 5]   88   bff703 c0878000 c0bf7703
> LOAD[ 6]   bff706   bff72b c0bf7706 c0bf772b
> LOAD[ 7]   bff72f   bff803 c0bf772f c0bf7803
> LOAD[ 8]   bff805   bff807 c0bf7805 c0bf7807
> LOAD[ 9]   bff80d   bff827 c0bf780d c0bf7827
> LOAD[10]   bff828   bff83d c0bf7828 c0bf783d>
> LOAD[11]   bff887   bffc1a c0bf7887 c0bf7c1a
> LOAD[12]   bffc1c   bffc1d c0bf7c1c c0bf7c1d
> LOAD[13]   bffe21   bfffd1 c0bf7e21 c0bf7fd1
> LOAD[14]   bfffd4   bfffd5 c0bf7fd4 c0bf7fd5
> LOAD[15]   bfffe0   c0 c0bf7fe0 c0bf8000
> Linux kdump
> VMCOREINFO   :
  OSRELEASE=5.4.0-rc8
  PAGESIZE=65536
> page_size: 65536
  SYMBOL(init_uts_ns)=800011a65ca8
  SYMBOL(node_online_map)=800011a5d490
  SYMBOL(swapper_pg_dir)=8000112f
  SYMBOL(_stext)=800010081000
  SYMBOL(vmap_area_list)=800011b29a98
  SYMBOL(mem_section)=00bf7be7e300
  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)=800011ada808
  SYMBOL(log_buf_len)=800011ada810
  SYMBOL(log_first_idx)=800011e772d4
  SYMBOL(clear_idx)=800011e74d20
  SYMBOL(log_next_idx)=800011e772e0
  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)=0x7fff7d60
  NUMBER(PHYS_OFFSET)=0x8000
  NUMBER(tcr_el1_t1sz)=0x10
  KERNELOFFSET=0
  CRASHTIME=1574266958

> phys_base: 8000 (vmcoreinfo)

> max_mapnr: c0
> There is enough free memory to be done in one cycle.

> Buffer size for the cyclic mode: 3145728
> va_bits  : 47
> page_offset  : c000
> 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: 8000 (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:  (approximation)
kimage_voffset   : fffe8fc0
max_physmem_bits : 52
section_size_bits: 30

Regards,
Bhupesh

[0]. 

[1].

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

2019-11-20 Thread John Donnelly 
Hi,

  Recent test below 


> On Nov 18, 2019, at 1:01 PM, Bhupesh Sharma  wrote:
> 
> Hi John,
> 
> On Mon, Nov 18, 2019 at 10:41 PM John Donnelly
>  wrote:
>> 
>> Hi,
>> 
>> See below .
>> 
>>> On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha  
>>> wrote:
>>> 
>>> Re-sending in plain text mode.
>>> 
>>> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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

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

2019-11-18 Thread John Donnelly 



> On Nov 18, 2019, at 1:12 PM, John Donnelly  wrote:
> 
> I will update and test a new kernel 
> 
> 
> 
> 
>> On Nov 18, 2019, at 1:01 PM, Bhupesh Sharma  wrote:
>> 
>> Hi John,
>> 
>> On Mon, Nov 18, 2019 at 10:41 PM John Donnelly
>>  wrote:
>>> 
>>> Hi,
>>> 
>>> See below .
>>> 
 On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha 
  wrote:
 
 Re-sending in plain text mode.
 
 On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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/

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

2019-11-18 Thread John Donnelly 
I will update and test a new kernel 




> On Nov 18, 2019, at 1:01 PM, Bhupesh Sharma  wrote:
> 
> Hi John,
> 
> On Mon, Nov 18, 2019 at 10:41 PM John Donnelly
>  wrote:
>> 
>> Hi,
>> 
>> See below .
>> 
>>> On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha  
>>> wrote:
>>> 
>>> Re-sending in plain text mode.
>>> 
>>> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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_3C

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

2019-11-18 Thread Bhupesh Sharma 
Hi John,

On Mon, Nov 18, 2019 at 10:41 PM John Donnelly
 wrote:
>
> Hi,
>
> See below .
>
> > On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha  
> > wrote:
> >
> > Re-sending in plain text mode.
> >
> > On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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=q9nNMgIGr

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

2019-11-18 Thread Bhupesh Sharma 
Hi Prabhakar,

On Mon, Nov 18, 2019 at 10:42 AM Prabhakar Kushwaha
 wrote:
>
> Re-sending in plain text mode.
>
> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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 
> > Cc: Kazuhito Hagio 
> > 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 

Thanks for testing the patchset.

Regards,
Bhupesh


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

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

2019-11-18 Thread John Donnelly 
Hi,

See below .

> On Nov 17, 2019, at 11:12 PM, Prabhakar Kushwaha  
> wrote:
> 
> Re-sending in plain text mode.
> 
> On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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 
>> Cc: Kazuhito Hagio 
>> Cc: kexec@lists.infradead.org
>> 
>> Bhupesh Sharma (4):
>>  tree-wide: Retrieve 'MAX_PHYSMEM_BITS' fro

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

2019-11-17 Thread Prabhakar Kushwaha 
Re-sending in plain text mode.

On Tue, Nov 12, 2019 at 4:39 PM Bhupesh Sharma  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 
> Cc: Kazuhito Hagio 
> 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 

--pk

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

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

2019-11-14 Thread Bhupesh Sharma 
Hi Kazu,

On Thu, Nov 14, 2019 at 3:31 AM Kazuhito Hagio  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 
> > Cc: Kazuhito Hagio 
> > 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.infrade

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

2019-11-13 Thread Kazuhito Hagio 
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 
> Cc: Kazuhito Hagio 
> 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