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

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

[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

[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

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

[Bhupesh Sharma]

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

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

[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 <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

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

[Bhupesh Sharma]

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

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

[Prabhakar Kushwaha]

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

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

[John Donnelly]

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

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

[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

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

[John Donnelly]

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

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

[John Donnelly]

> 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

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

[John Donnelly]

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

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

[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

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

[John Donnelly]

> 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

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

[John Donnelly]

> 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

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

[John Donnelly]

> 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

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

[John Donnelly]

> 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

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

[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

[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

[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

[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