RE: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hi Bhupesh,
Thank you for your explanation.
It sounds good.
I will wait for your new patch.
Thanks
Tachibana
> -Original Message-
> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> Sent: Monday, March 05, 2018 12:41 PM
> To: Tachibana Masaki()
> Cc: kexec@lists.infradead.org; Hayashi Masahiko()
> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
>
> Hello Masaki,
>
> Thanks for your reply.
>
> On Fri, Mar 2, 2018 at 11:01 AM, Masaki Tachibana
> wrote:
> > Hi Bhupesh,
> >
> > Sorry for the late reply.
> > And thank you for your patch.
> > I have some questions. Please answer me.
> > - Have you succeeded --mem-usage on ppc64, s390x ?
>
> Yes, --mem-usage works fine on both ppc64 and s390x RHEL systems
> for me. I tested the same on several ppc64 and s390x machines.
>
> > - By your patch, makedumpfile behaves like this;
> > 1.Gets an address of _stext from a vmlinux file.
> > 2.Checks how many upper bits are 1 in the address.
> > 3.Determines va_bits and info->page_offset by the check.
> > Isn't there any other method to get page_offset without a vmlinux ?
>
> Ok, let me give some background here:
>
> On ARM64 platforms the VA_BITS supported by a linux kernel run can be
> selected by setting 'ARM64_VA_BITS_*' (please see [1]) config options.
>
> Now, to determine the 'info->page_offset' in arm64 makedumpfile
> context ('arch/arm64.c')
> we need to determine the VA_BITS which was selected by the underlying
> linux kernel.
>
> Now there are several ways to determine the VA_BITS:
>
> (a). Read the CONFIG flags from the user space using something like:
> - Create a 'running.config' which will contain the configuration of
> the running linux kernel
> and grep the VA_BITS from 'running.config' :
> # cat /proc/config.gz | gunzip > running.config
> - However this is only possible if running linux kernel was configured
> to have '/proc/config.gz'
>
> So, this is probably not a good option.
>
> (b). Read '_stext' symbol and calculate the 'va_bits' and
> 'info->page_offset' using the upper bits are 1 in the address.
> There are a couple of ways to do the same via makedumpfile code:
> - Use the 'vmlinux' file, which this version of the patch does.
> - Use the '/proc/kallsyms' file, which is also possible and I have a
> patch ready for this approach as well.
>
> The '/proc/kallsyms' file approach is better in the following aspects:
> - We don't need to pass the 'vmlinux' file path separately while
> invoking '--mem-usage' option for makedumpfile.
> - It also helps the arm64 KASLR makedumpfile implementation (which I
> am currently working on and will send out a patch to address the same
> soon), as the '_stext' symbol will be randomized and hence cannot be
> properly read from the 'vmlinux' file.
>
> If you agree, I can send a new version which reads the '_stext' symbol
> from '/proc/kallsyms' and works fine on the arm64 platforms I have
> tested it on (both with KASLR turned on and off)
>
> [1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L518
> Regards,
> Bhupesh
>
>
> > Thanks
> > Tachibana
> >
> >> -Original Message-
> >> From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of
> >> Bhupesh SHARMA
> >> Sent: Thursday, February 22, 2018 3:58 AM
> >> To: Tachibana Masaki()
> >> Cc: kexec@lists.infradead.org; Bhupesh Sharma ;
> >> Hayashi Masahiko()
> >>
> >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
> >>
> >> Hi Masaki Tachibana,
> >>
> >> On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana
> >> wrote:
> >> > Hi Bhupesh,
> >> >
> >> > Sorry for the late reply.
> >> > I'll reply by the end the next week.
> >>
> >> Sure. Thanks for your mail.
> >>
> >> Regards,
> >> Bhupesh
> >>
> >>
> >> > Thanks
> >> > tachibana
> >> >
> >> >> -Original Message-
> >> >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> >> >> Sent: Tuesday, February 20, 2018 1:56 PM
> >> >> To: kexec@lists.infradead.org
> >> >> Cc: Bhupesh Sharma ; Tachibana Masaki()
> >> >> ; Nakayama Takuya(
> >> >> ) ; Nishimura Daisuke()
> >> >>
&
Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hello Masaki,
Thanks for your reply.
On Fri, Mar 2, 2018 at 11:01 AM, Masaki Tachibana
wrote:
> Hi Bhupesh,
>
> Sorry for the late reply.
> And thank you for your patch.
> I have some questions. Please answer me.
> - Have you succeeded --mem-usage on ppc64, s390x ?
Yes, --mem-usage works fine on both ppc64 and s390x RHEL systems
for me. I tested the same on several ppc64 and s390x machines.
> - By your patch, makedumpfile behaves like this;
> 1.Gets an address of _stext from a vmlinux file.
> 2.Checks how many upper bits are 1 in the address.
> 3.Determines va_bits and info->page_offset by the check.
> Isn't there any other method to get page_offset without a vmlinux ?
Ok, let me give some background here:
On ARM64 platforms the VA_BITS supported by a linux kernel run can be
selected by setting 'ARM64_VA_BITS_*' (please see [1]) config options.
Now, to determine the 'info->page_offset' in arm64 makedumpfile
context ('arch/arm64.c')
we need to determine the VA_BITS which was selected by the underlying
linux kernel.
Now there are several ways to determine the VA_BITS:
(a). Read the CONFIG flags from the user space using something like:
- Create a 'running.config' which will contain the configuration of
the running linux kernel
and grep the VA_BITS from 'running.config' :
# cat /proc/config.gz | gunzip > running.config
- However this is only possible if running linux kernel was configured
to have '/proc/config.gz'
So, this is probably not a good option.
(b). Read '_stext' symbol and calculate the 'va_bits' and
'info->page_offset' using the upper bits are 1 in the address.
There are a couple of ways to do the same via makedumpfile code:
- Use the 'vmlinux' file, which this version of the patch does.
- Use the '/proc/kallsyms' file, which is also possible and I have a
patch ready for this approach as well.
The '/proc/kallsyms' file approach is better in the following aspects:
- We don't need to pass the 'vmlinux' file path separately while
invoking '--mem-usage' option for makedumpfile.
- It also helps the arm64 KASLR makedumpfile implementation (which I
am currently working on and will send out a patch to address the same
soon), as the '_stext' symbol will be randomized and hence cannot be
properly read from the 'vmlinux' file.
If you agree, I can send a new version which reads the '_stext' symbol
from '/proc/kallsyms' and works fine on the arm64 platforms I have
tested it on (both with KASLR turned on and off)
[1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L518
Regards,
Bhupesh
> Thanks
> Tachibana
>
>> -Original Message-
>> From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Bhupesh
>> SHARMA
>> Sent: Thursday, February 22, 2018 3:58 AM
>> To: Tachibana Masaki()
>> Cc: kexec@lists.infradead.org; Bhupesh Sharma ; Hayashi
>> Masahiko()
>>
>> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
>>
>> Hi Masaki Tachibana,
>>
>> On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana
>> wrote:
>> > Hi Bhupesh,
>> >
>> > Sorry for the late reply.
>> > I'll reply by the end the next week.
>>
>> Sure. Thanks for your mail.
>>
>> Regards,
>> Bhupesh
>>
>>
>> > Thanks
>> > tachibana
>> >
>> >> -Original Message-
>> >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
>> >> Sent: Tuesday, February 20, 2018 1:56 PM
>> >> To: kexec@lists.infradead.org
>> >> Cc: Bhupesh Sharma ; Tachibana Masaki()
>> >> ; Nakayama Takuya(
>> >> ) ; Nishimura Daisuke()
>> >>
>> >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
>> >>
>> >> Hello,
>> >>
>> >> On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma
>> >> wrote:
>> >> > Its good to have the makedumpfile '--mem-usage' support
>> >> > for arm64 architecture as well, as it allows one to see the page numbers
>> >> > of current system (1st kernel) in different use.
>> >> >
>> >> > Using this we can know how many pages are dumpable when different
>> >> > dump_level is specified.
>> >> >
>> >> > Normally for x86_64, makedumpfile analyzes the 'System Ram' and
>> >> > 'kernel text' program segment of /proc/kcore excluding
>> >> > the crashkernel range, then calculates the page number of
RE: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hi Bhupesh, Sorry for the late reply. And thank you for your patch. I have some questions. Please answer me. - Have you succeeded --mem-usage on ppc64, s390x ? - By your patch, makedumpfile behaves like this; 1.Gets an address of _stext from a vmlinux file. 2.Checks how many upper bits are 1 in the address. 3.Determines va_bits and info->page_offset by the check. Isn't there any other method to get page_offset without a vmlinux ? Thanks Tachibana > -Original Message- > From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Bhupesh > SHARMA > Sent: Thursday, February 22, 2018 3:58 AM > To: Tachibana Masaki() > Cc: kexec@lists.infradead.org; Bhupesh Sharma ; Hayashi > Masahiko() > > Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support > > Hi Masaki Tachibana, > > On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana > wrote: > > Hi Bhupesh, > > > > Sorry for the late reply. > > I'll reply by the end the next week. > > Sure. Thanks for your mail. > > Regards, > Bhupesh > > > > Thanks > > tachibana > > > >> -Original Message- > >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com] > >> Sent: Tuesday, February 20, 2018 1:56 PM > >> To: kexec@lists.infradead.org > >> Cc: Bhupesh Sharma ; Tachibana Masaki() > >> ; Nakayama Takuya( > >> ) ; Nishimura Daisuke() > >> > >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support > >> > >> Hello, > >> > >> On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma wrote: > >> > Its good to have the makedumpfile '--mem-usage' support > >> > for arm64 architecture as well, as it allows one to see the page numbers > >> > of current system (1st kernel) in different use. > >> > > >> > Using this we can know how many pages are dumpable when different > >> > dump_level is specified. > >> > > >> > Normally for x86_64, makedumpfile analyzes the 'System Ram' and > >> > 'kernel text' program segment of /proc/kcore excluding > >> > the crashkernel range, then calculates the page number of different > >> > kind per vmcoreinfo. > >> > > >> > We use the similar logic for arm64, but in addition make the > >> > '--mem-usage' > >> > usage dependent on the VMLINUX file being passed. This is done to allow > >> > information like VA_BITS being determined from kernel symbol like > >> > _stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()' > >> > is called. > >> > > >> > Also I have validated the '--mem-usage' makedumpfile option on several > >> > ppc64/ppc64le and s390x machines, so update the makedumpfile.8 > >> > documentation to indicate that '--mem-usage' option is supported > >> > not only on x86_64, but also on ppc64, s390x and arm64. > >> > > >> > After this patch, when using the '--mem-usage' option with makedumpfile, > >> > we get the correct information about the different pages. For e.g. > >> > here is an output from my arm64 board: > >> > > >> > TYPEPAGES EXCLUDABLE DESCRIPTION > >> > -- > >> > ZERO49524 yes Pages filled > >> > with zero > >> > NON_PRI_CACHE 15143 yes Cache pages > >> > without private flag > >> > PRI_CACHE 29147 yes Cache pages with > >> > private flag > >> > USER3684yes User process > >> > pages > >> > FREE1450569 yes Free pages > >> > KERN_DATA 14243 no Dumpable kernel > >> > data > >> > > >> > page size: 65536 > >> > Total pages on system: 1562310 > >> > Total size on system: 102387548160 Byte > >> > > >> > Cc: Masaki Tachibana > >> > Cc: Takuya Nakayama > >> > Cc: Daisuke Nishimura > >> > Signed-off-by: Bhupesh Sharma > >> > >> Ping. Any review comments on this? > >> > >> Regards, > >> Bhupesh > >> > >> > --- > >> > arch/a
Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hi Masaki Tachibana, On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana wrote: > Hi Bhupesh, > > Sorry for the late reply. > I'll reply by the end the next week. Sure. Thanks for your mail. Regards, Bhupesh > Thanks > tachibana > >> -Original Message- >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com] >> Sent: Tuesday, February 20, 2018 1:56 PM >> To: kexec@lists.infradead.org >> Cc: Bhupesh Sharma ; Tachibana Masaki() >> ; Nakayama Takuya( >> ) ; Nishimura Daisuke() >> >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support >> >> Hello, >> >> On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma wrote: >> > Its good to have the makedumpfile '--mem-usage' support >> > for arm64 architecture as well, as it allows one to see the page numbers >> > of current system (1st kernel) in different use. >> > >> > Using this we can know how many pages are dumpable when different >> > dump_level is specified. >> > >> > Normally for x86_64, makedumpfile analyzes the 'System Ram' and >> > 'kernel text' program segment of /proc/kcore excluding >> > the crashkernel range, then calculates the page number of different >> > kind per vmcoreinfo. >> > >> > We use the similar logic for arm64, but in addition make the '--mem-usage' >> > usage dependent on the VMLINUX file being passed. This is done to allow >> > information like VA_BITS being determined from kernel symbol like >> > _stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()' >> > is called. >> > >> > Also I have validated the '--mem-usage' makedumpfile option on several >> > ppc64/ppc64le and s390x machines, so update the makedumpfile.8 >> > documentation to indicate that '--mem-usage' option is supported >> > not only on x86_64, but also on ppc64, s390x and arm64. >> > >> > After this patch, when using the '--mem-usage' option with makedumpfile, >> > we get the correct information about the different pages. For e.g. >> > here is an output from my arm64 board: >> > >> > TYPEPAGES EXCLUDABLE DESCRIPTION >> > -- >> > ZERO49524 yes Pages filled with >> > zero >> > NON_PRI_CACHE 15143 yes Cache pages >> > without private flag >> > PRI_CACHE 29147 yes Cache pages with >> > private flag >> > USER3684yes User process pages >> > FREE1450569 yes Free pages >> > KERN_DATA 14243 no Dumpable kernel >> > data >> > >> > page size: 65536 >> > Total pages on system: 1562310 >> > Total size on system: 102387548160 Byte >> > >> > Cc: Masaki Tachibana >> > Cc: Takuya Nakayama >> > Cc: Daisuke Nishimura >> > Signed-off-by: Bhupesh Sharma >> >> Ping. Any review comments on this? >> >> Regards, >> Bhupesh >> >> > --- >> > arch/arm64.c | 51 --- >> > makedumpfile.8 | 11 +-- >> > makedumpfile.c | 25 +++-- >> > makedumpfile.h | 1 + >> > 4 files changed, 81 insertions(+), 7 deletions(-) >> > >> > diff --git a/arch/arm64.c b/arch/arm64.c >> > index 25d7a1f4db98..91f113f6447c 100644 >> > --- a/arch/arm64.c >> > +++ b/arch/arm64.c >> > @@ -48,6 +48,12 @@ static unsigned long kimage_voffset; >> > #define SZ_64K (64 * 1024) >> > #define SZ_128M(128 * 1024 * 1024) >> > >> > +#define PAGE_OFFSET_36 ((0xUL) << 36) >> > +#define PAGE_OFFSET_39 ((0xUL) << 39) >> > +#define PAGE_OFFSET_42 ((0xUL) << 42) >> > +#define PAGE_OFFSET_47 ((0xUL) << 47) >> > +#define PAGE_OFFSET_48 ((0xUL) << 48) >> > + >> > #define pgd_val(x) ((x).pgd) >> > #define pud_val(x) (pgd_val((x).pgd)) >> > #define pmd_val(x) (pud_val((x).pud)) >> > @@ -140,8 +146,6 @@ pud_offset(pgd_t *pgda, pg
RE: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hi Bhupesh,
Sorry for the late reply.
I'll reply by the end the next week.
Thanks
tachibana
> -Original Message-
> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> Sent: Tuesday, February 20, 2018 1:56 PM
> To: kexec@lists.infradead.org
> Cc: Bhupesh Sharma ; Tachibana Masaki()
> ; Nakayama Takuya(
> ) ; Nishimura Daisuke()
>
> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
>
> Hello,
>
> On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma wrote:
> > Its good to have the makedumpfile '--mem-usage' support
> > for arm64 architecture as well, as it allows one to see the page numbers
> > of current system (1st kernel) in different use.
> >
> > Using this we can know how many pages are dumpable when different
> > dump_level is specified.
> >
> > Normally for x86_64, makedumpfile analyzes the 'System Ram' and
> > 'kernel text' program segment of /proc/kcore excluding
> > the crashkernel range, then calculates the page number of different
> > kind per vmcoreinfo.
> >
> > We use the similar logic for arm64, but in addition make the '--mem-usage'
> > usage dependent on the VMLINUX file being passed. This is done to allow
> > information like VA_BITS being determined from kernel symbol like
> > _stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()'
> > is called.
> >
> > Also I have validated the '--mem-usage' makedumpfile option on several
> > ppc64/ppc64le and s390x machines, so update the makedumpfile.8
> > documentation to indicate that '--mem-usage' option is supported
> > not only on x86_64, but also on ppc64, s390x and arm64.
> >
> > After this patch, when using the '--mem-usage' option with makedumpfile,
> > we get the correct information about the different pages. For e.g.
> > here is an output from my arm64 board:
> >
> > TYPEPAGES EXCLUDABLE DESCRIPTION
> > --
> > ZERO49524 yes Pages filled with
> > zero
> > NON_PRI_CACHE 15143 yes Cache pages without
> > private flag
> > PRI_CACHE 29147 yes Cache pages with
> > private flag
> > USER3684yes User process pages
> > FREE1450569 yes Free pages
> > KERN_DATA 14243 no Dumpable kernel data
> >
> > page size: 65536
> > Total pages on system: 1562310
> > Total size on system: 102387548160 Byte
> >
> > Cc: Masaki Tachibana
> > Cc: Takuya Nakayama
> > Cc: Daisuke Nishimura
> > Signed-off-by: Bhupesh Sharma
>
> Ping. Any review comments on this?
>
> Regards,
> Bhupesh
>
> > ---
> > arch/arm64.c | 51 ---
> > makedumpfile.8 | 11 +--
> > makedumpfile.c | 25 +++--
> > makedumpfile.h | 1 +
> > 4 files changed, 81 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64.c b/arch/arm64.c
> > index 25d7a1f4db98..91f113f6447c 100644
> > --- a/arch/arm64.c
> > +++ b/arch/arm64.c
> > @@ -48,6 +48,12 @@ static unsigned long kimage_voffset;
> > #define SZ_64K (64 * 1024)
> > #define SZ_128M(128 * 1024 * 1024)
> >
> > +#define PAGE_OFFSET_36 ((0xUL) << 36)
> > +#define PAGE_OFFSET_39 ((0xUL) << 39)
> > +#define PAGE_OFFSET_42 ((0xUL) << 42)
> > +#define PAGE_OFFSET_47 ((0xUL) << 47)
> > +#define PAGE_OFFSET_48 ((0xUL) << 48)
> > +
> > #define pgd_val(x) ((x).pgd)
> > #define pud_val(x) (pgd_val((x).pgd))
> > #define pmd_val(x) (pud_val((x).pud))
> > @@ -140,8 +146,6 @@ pud_offset(pgd_t *pgda, pgd_t *pgdv, unsigned long
> > vaddr)
> >
> > static int calculate_plat_config(void)
> > {
> > - va_bits = NUMBER(VA_BITS);
> > -
> > /* derive pgtable_level as per arch/arm64/Kconfig */
> > if ((PAGESIZE() == SZ_16K && va_bits == 36) ||
> > (PAGESIZE() == SZ_64K && va_bits == 42)) {
> > @@ -188,7 +192,6 @@ get_machdep_info_arm64(void)
> > kimage_voffset = NUMBER(kim
Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
Hello,
On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma wrote:
> Its good to have the makedumpfile '--mem-usage' support
> for arm64 architecture as well, as it allows one to see the page numbers
> of current system (1st kernel) in different use.
>
> Using this we can know how many pages are dumpable when different
> dump_level is specified.
>
> Normally for x86_64, makedumpfile analyzes the 'System Ram' and
> 'kernel text' program segment of /proc/kcore excluding
> the crashkernel range, then calculates the page number of different
> kind per vmcoreinfo.
>
> We use the similar logic for arm64, but in addition make the '--mem-usage'
> usage dependent on the VMLINUX file being passed. This is done to allow
> information like VA_BITS being determined from kernel symbol like
> _stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()'
> is called.
>
> Also I have validated the '--mem-usage' makedumpfile option on several
> ppc64/ppc64le and s390x machines, so update the makedumpfile.8
> documentation to indicate that '--mem-usage' option is supported
> not only on x86_64, but also on ppc64, s390x and arm64.
>
> After this patch, when using the '--mem-usage' option with makedumpfile,
> we get the correct information about the different pages. For e.g.
> here is an output from my arm64 board:
>
> TYPEPAGES EXCLUDABLE DESCRIPTION
> --
> ZERO49524 yes Pages filled with zero
> NON_PRI_CACHE 15143 yes Cache pages without
> private flag
> PRI_CACHE 29147 yes Cache pages with
> private flag
> USER3684yes User process pages
> FREE1450569 yes Free pages
> KERN_DATA 14243 no Dumpable kernel data
>
> page size: 65536
> Total pages on system: 1562310
> Total size on system: 102387548160 Byte
>
> Cc: Masaki Tachibana
> Cc: Takuya Nakayama
> Cc: Daisuke Nishimura
> Signed-off-by: Bhupesh Sharma
Ping. Any review comments on this?
Regards,
Bhupesh
> ---
> arch/arm64.c | 51 ---
> makedumpfile.8 | 11 +--
> makedumpfile.c | 25 +++--
> makedumpfile.h | 1 +
> 4 files changed, 81 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64.c b/arch/arm64.c
> index 25d7a1f4db98..91f113f6447c 100644
> --- a/arch/arm64.c
> +++ b/arch/arm64.c
> @@ -48,6 +48,12 @@ static unsigned long kimage_voffset;
> #define SZ_64K (64 * 1024)
> #define SZ_128M(128 * 1024 * 1024)
>
> +#define PAGE_OFFSET_36 ((0xUL) << 36)
> +#define PAGE_OFFSET_39 ((0xUL) << 39)
> +#define PAGE_OFFSET_42 ((0xUL) << 42)
> +#define PAGE_OFFSET_47 ((0xUL) << 47)
> +#define PAGE_OFFSET_48 ((0xUL) << 48)
> +
> #define pgd_val(x) ((x).pgd)
> #define pud_val(x) (pgd_val((x).pgd))
> #define pmd_val(x) (pud_val((x).pud))
> @@ -140,8 +146,6 @@ pud_offset(pgd_t *pgda, pgd_t *pgdv, unsigned long vaddr)
>
> static int calculate_plat_config(void)
> {
> - va_bits = NUMBER(VA_BITS);
> -
> /* derive pgtable_level as per arch/arm64/Kconfig */
> if ((PAGESIZE() == SZ_16K && va_bits == 36) ||
> (PAGESIZE() == SZ_64K && va_bits == 42)) {
> @@ -188,7 +192,6 @@ get_machdep_info_arm64(void)
> kimage_voffset = NUMBER(kimage_voffset);
> info->max_physmem_bits = PHYS_MASK_SHIFT;
> info->section_size_bits = SECTIONS_SIZE_BITS;
> - info->page_offset = 0xUL << (va_bits - 1);
>
> DEBUG_MSG("kimage_voffset : %lx\n", kimage_voffset);
> DEBUG_MSG("max_physmem_bits : %lx\n", info->max_physmem_bits);
> @@ -219,6 +222,48 @@ get_xen_info_arm64(void)
> int
> get_versiondep_info_arm64(void)
> {
> + unsigned long long stext;
> +
> + /* We can read the _stext symbol from vmlinux and determine the
> +* VA_BITS and page_offset.
> +*/
> +
> + /* Open the vmlinux file */
> + open_kernel_file();
> + set_dwarf_debuginfo("vmlinux", NULL,
> + info->name_vmlinux, info->fd_vmlinux);
> +
> + if (!get_symbol_info())
> + return FALSE;
> +
> + /* Get the '_stext' symbol */
> + if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
> + ERRMSG("Can't get the symbol of _stext.\n");
> + return FALSE;
> + } else {
> + stext = SYMBOL(_stext);
> + }
> +
> + /* Derive va_bits as per arch/arm64/Kconfig */
> + if ((stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
> + va_bits = 36;
> + } else if ((stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
> +
[PATCH] makedumpfile/arm64: Add '--mem-usage' support
Its good to have the makedumpfile '--mem-usage' support
for arm64 architecture as well, as it allows one to see the page numbers
of current system (1st kernel) in different use.
Using this we can know how many pages are dumpable when different
dump_level is specified.
Normally for x86_64, makedumpfile analyzes the 'System Ram' and
'kernel text' program segment of /proc/kcore excluding
the crashkernel range, then calculates the page number of different
kind per vmcoreinfo.
We use the similar logic for arm64, but in addition make the '--mem-usage'
usage dependent on the VMLINUX file being passed. This is done to allow
information like VA_BITS being determined from kernel symbol like
_stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()'
is called.
Also I have validated the '--mem-usage' makedumpfile option on several
ppc64/ppc64le and s390x machines, so update the makedumpfile.8
documentation to indicate that '--mem-usage' option is supported
not only on x86_64, but also on ppc64, s390x and arm64.
After this patch, when using the '--mem-usage' option with makedumpfile,
we get the correct information about the different pages. For e.g.
here is an output from my arm64 board:
TYPEPAGES EXCLUDABLE DESCRIPTION
--
ZERO49524 yes Pages filled with zero
NON_PRI_CACHE 15143 yes Cache pages without
private flag
PRI_CACHE 29147 yes Cache pages with
private flag
USER3684yes User process pages
FREE1450569 yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
Cc: Masaki Tachibana
Cc: Takuya Nakayama
Cc: Daisuke Nishimura
Signed-off-by: Bhupesh Sharma
---
arch/arm64.c | 51 ---
makedumpfile.8 | 11 +--
makedumpfile.c | 25 +++--
makedumpfile.h | 1 +
4 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/arch/arm64.c b/arch/arm64.c
index 25d7a1f4db98..91f113f6447c 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -48,6 +48,12 @@ static unsigned long kimage_voffset;
#define SZ_64K (64 * 1024)
#define SZ_128M(128 * 1024 * 1024)
+#define PAGE_OFFSET_36 ((0xUL) << 36)
+#define PAGE_OFFSET_39 ((0xUL) << 39)
+#define PAGE_OFFSET_42 ((0xUL) << 42)
+#define PAGE_OFFSET_47 ((0xUL) << 47)
+#define PAGE_OFFSET_48 ((0xUL) << 48)
+
#define pgd_val(x) ((x).pgd)
#define pud_val(x) (pgd_val((x).pgd))
#define pmd_val(x) (pud_val((x).pud))
@@ -140,8 +146,6 @@ pud_offset(pgd_t *pgda, pgd_t *pgdv, unsigned long vaddr)
static int calculate_plat_config(void)
{
- va_bits = NUMBER(VA_BITS);
-
/* derive pgtable_level as per arch/arm64/Kconfig */
if ((PAGESIZE() == SZ_16K && va_bits == 36) ||
(PAGESIZE() == SZ_64K && va_bits == 42)) {
@@ -188,7 +192,6 @@ get_machdep_info_arm64(void)
kimage_voffset = NUMBER(kimage_voffset);
info->max_physmem_bits = PHYS_MASK_SHIFT;
info->section_size_bits = SECTIONS_SIZE_BITS;
- info->page_offset = 0xUL << (va_bits - 1);
DEBUG_MSG("kimage_voffset : %lx\n", kimage_voffset);
DEBUG_MSG("max_physmem_bits : %lx\n", info->max_physmem_bits);
@@ -219,6 +222,48 @@ get_xen_info_arm64(void)
int
get_versiondep_info_arm64(void)
{
+ unsigned long long stext;
+
+ /* We can read the _stext symbol from vmlinux and determine the
+* VA_BITS and page_offset.
+*/
+
+ /* Open the vmlinux file */
+ open_kernel_file();
+ set_dwarf_debuginfo("vmlinux", NULL,
+ info->name_vmlinux, info->fd_vmlinux);
+
+ if (!get_symbol_info())
+ return FALSE;
+
+ /* Get the '_stext' symbol */
+ if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
+ ERRMSG("Can't get the symbol of _stext.\n");
+ return FALSE;
+ } else {
+ stext = SYMBOL(_stext);
+ }
+
+ /* Derive va_bits as per arch/arm64/Kconfig */
+ if ((stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
+ va_bits = 36;
+ } else if ((stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
+ va_bits = 39;
+ } else if ((stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
+ va_bits = 42;
+ } else if ((stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
+ va_bits = 47;
+ } else if ((stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
+ va_bits = 48;
+ } else {
+
