From: Dave Young <dyoung@redhat.com>
To: Kazuhito Hagio <k-hagio@ab.jp.nec.com>, anderson@redhat.com
Cc: Mark Rutland <mark.rutland@arm.com>,
"lijiang@redhat.com" <lijiang@redhat.com>,
"bhe@redhat.com" <bhe@redhat.com>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Will Deacon <will.deacon@arm.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
James Morse <james.morse@arm.com>, Borislav Petkov <bp@alien8.de>,
"anderson@redhat.com" <anderson@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo
Date: Wed, 13 Feb 2019 19:15:52 +0800 [thread overview]
Message-ID: <20190213111552.GA8265@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <4AE2DC15AC0B8543882A74EA0D43DBEC035683DB@BPXM09GP.gisp.nec.co.jp>
On 02/12/19 at 11:03pm, Kazuhito Hagio wrote:
>
> On 2/12/2019 2:59 PM, Bhupesh Sharma wrote:
> > BTW, in the makedumpfile enablement patch thread for ARMv8.2 LVA
> > (which I sent out for 52-bit User space VA enablement) (see [0]), Kazu
> > mentioned that the changes look necessary.
> >
> > [0]. http://lists.infradead.org/pipermail/kexec/2019-February/022431.html
>
> > > > The increased 'PTRS_PER_PGD' value for such cases needs to be then
> > > > calculated as is done by the underlying kernel (see
> > > > 'arch/arm64/include/asm/pgtable-hwdef.h' for details):
> > > >
> > > > #define PTRS_PER_PGD (1 << (MAX_USER_VA_BITS - PGDIR_SHIFT))
>
> Yes, this is the reason why makedumpfile needs the MAX_USER_VA_BITS.
> It is used for pgd_index() also in makedumpfile to walk page tables.
>
> /* to find an entry in a page-table-directory */
> #define pgd_index(addr) (((addr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
Since Dave mentioned crash tool does not need it, but crash should also
travel the pg tables.
If this is really necessary it would be good to describe what will
happen without the patch, eg. some user visible error from an actual test etc.
>
> Thanks,
> Kazu
>
> > > >
> > > > Also, note that 'arch/arm64/include/asm/memory.h' defines 'MAX_USER_VA_BITS'
> > > > as 'VA_BITS' in case 'CONFIG_ARM64_USER_VA_BITS_52' is set to 'n':
> > > >
> > > > #ifdef CONFIG_ARM64_USER_VA_BITS_52
> > > > #define MAX_USER_VA_BITS 52
> > > > #else
> > > > #define MAX_USER_VA_BITS VA_BITS
> > > > #endif
> > > >
> > > > So, makedumpfile will need this symbol exported in vmcore to make the above
> > > > determination.
> > > >
> > > > [0]. http://lists.infradead.org/pipermail/kexec/2019-February/022425.html
> > > >
> > > > Thanks,
> > > > Bhupesh
> > >
> > > Thanks
> > > Dave
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-13 11:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 12:23 [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo Bhupesh Sharma
2019-01-30 15:21 ` James Morse
2019-01-30 21:39 ` Bhupesh Sharma
2019-02-04 14:35 ` Bhupesh Sharma
2019-02-04 15:31 ` Robin Murphy
2019-02-12 4:55 ` Bhupesh Sharma
2019-02-12 10:49 ` Robin Murphy
2019-02-04 16:56 ` James Morse
2019-01-31 1:48 ` Dave Young
2019-01-31 10:00 ` Bhupesh Sharma
2019-01-31 14:03 ` Dave Anderson
2019-02-04 16:04 ` Kazuhito Hagio
2019-02-12 5:07 ` Bhupesh Sharma
2019-02-12 10:44 ` Dave Young
2019-02-12 19:59 ` Bhupesh Sharma
2019-02-12 23:03 ` Kazuhito Hagio
2019-02-13 11:15 ` Dave Young [this message]
2019-02-13 18:22 ` James Morse
2019-02-13 19:52 ` Kazuhito Hagio
2019-02-15 17:34 ` James Morse
2019-02-15 18:01 ` Bhupesh Sharma
2019-02-18 15:27 ` Steve Capper
2019-02-21 16:08 ` Bhupesh Sharma
2019-02-19 20:47 ` Kazuhito Hagio
2019-02-21 16:20 ` Bhupesh Sharma
2019-02-21 16:42 ` Dave Anderson
2019-02-21 19:02 ` Kazuhito Hagio
2019-03-01 4:01 ` Bhupesh Sharma
2019-02-14 19:30 ` Bhupesh Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190213111552.GA8265@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=anderson@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhe@redhat.com \
--cc=bhsharma@redhat.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=k-hagio@ab.jp.nec.com \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=takahiro.akashi@linaro.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).