From: James Morse <james.morse@arm.com>
To: Bhupesh Sharma <bhsharma@redhat.com>,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
Cc: bhupesh.linux@gmail.com, Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>,
Steve Capper <steve.capper@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Dave Anderson <anderson@redhat.com>,
Kazuhito Hagio <k-hagio@ab.jp.nec.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
Date: Wed, 1 Jul 2020 12:59:39 +0100 [thread overview]
Message-ID: <7abd195f-2091-0ef9-2e0b-4a8bf2cf820e@arm.com> (raw)
In-Reply-To: <1589395957-24628-3-git-send-email-bhsharma@redhat.com>
Hi Bhupesh,
On 13/05/2020 19:52, Bhupesh Sharma wrote:
> 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.
I'd prefer the commit message not to refer to this 'vabits_actual' thing at all. By the
time a git-archaeologist comes to read this, it may be long gone.
Ideally this would refer to: TCR_EL1.TxSZ, which controls the VA space size,
and can be configured by a single kernel image to support either 48-bit or 52-bit VA space.
> 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 this value from vmcoreinfo for determining if a virtual
> address lies in the linear map range.
>
> While at it also add documentation for TCR_EL1.T1SZ variable being
> added to vmcoreinfo.
>
> It indicates the size offset of the memory region addressed by TTBR1_EL1
> diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
> index 1f646b07e3e9..314391a156ee 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/cpufeature.h>
> #include <asm/memory.h>
> +#include <asm/pgtable-hwdef.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)
> {
> @@ -16,6 +24,8 @@ 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());
> vmcoreinfo_append_str("NUMBER(KERNELPACMASK)=0x%llx\n",
> system_supports_address_auth() ?
(I think second guessing the kernel memory map is a sisyphean effort), but this register
isn't going to disappear, or change its meaning!:
Reviewed-by: James Morse <james.morse@arm.com>
You may need to re-post this to get the maintainer's attention as its normally safe to
assume patches posted before rc1 no longer apply. (in this case, this one does)
Thanks,
James
next prev parent reply other threads:[~2020-07-01 12:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 18:52 [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs) Bhupesh Sharma
2020-05-13 18:52 ` [PATCH v6 1/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo Bhupesh Sharma
2020-07-02 11:00 ` Catalin Marinas
2020-07-02 12:08 ` Dave Young
2020-07-02 16:55 ` Catalin Marinas
2020-05-13 18:52 ` [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo Bhupesh Sharma
2020-06-03 11:20 ` Kamlakant Patel
2020-06-03 20:34 ` Bhupesh Sharma
2020-06-04 4:49 ` [EXT] " Kamlakant Patel
2020-06-04 7:19 ` Will Deacon
2020-07-01 8:04 ` Amit Kachhap
2020-07-01 11:59 ` James Morse [this message]
2020-06-02 5:24 ` [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs) Bhupesh Sharma
2020-06-15 19:11 ` Bhupesh Sharma
2020-07-02 17:14 ` Catalin Marinas
2020-07-02 18:43 ` 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=7abd195f-2091-0ef9-2e0b-4a8bf2cf820e@arm.com \
--to=james.morse@arm.com \
--cc=anderson@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=bhupesh.linux@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=k-hagio@ab.jp.nec.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=steve.capper@arm.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®