All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bhupesh Sharma <bhsharma@redhat.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	James Morse <james.morse@arm.com>,
	bhupesh.linux@gmail.com
Subject: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo
Date: Wed, 30 Jan 2019 17:53:11 +0530	[thread overview]
Message-ID: <1548850991-11879-1-git-send-email-bhsharma@redhat.com> (raw)

With ARMv8.2-LVA and LPA architecture extensions, arm64 hardware which
supports these extensions can support upto 52-bit virtual and 52-bit
physical addresses respectively.

Since at the moment we enable the support of these extensions via CONFIG
flags, e.g.
 - LPA via CONFIG_ARM64_PA_BITS_52

there are no clear mechanisms in user-space right now to
deteremine these CONFIG flag values and also determine the PARange and
VARange address values.

User-space tools like 'makedumpfile' and 'crash-utility' can instead
use the 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' values to determine
the maximum virtual address and physical address (respectively)
supported by underlying kernel.

A reference 'makedumpfile' implementation which uses this approach to
determining the maximum physical address is available in [0].

[0]. https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-pa-support-via-vmcore-v1/arch/arm64.c#L490

Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
 arch/arm64/kernel/crash_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
index ca4c3e12d8c5..ad231be5c0d8 100644
--- a/arch/arm64/kernel/crash_core.c
+++ b/arch/arm64/kernel/crash_core.c
@@ -10,6 +10,8 @@
 void arch_crash_save_vmcoreinfo(void)
 {
 	VMCOREINFO_NUMBER(VA_BITS);
+	VMCOREINFO_NUMBER(MAX_USER_VA_BITS);
+	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
 	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
 	vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
 						kimage_voffset);
-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Bhupesh Sharma <bhsharma@redhat.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	James Morse <james.morse@arm.com>,
	bhupesh.linux@gmail.com
Subject: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo
Date: Wed, 30 Jan 2019 17:53:11 +0530	[thread overview]
Message-ID: <1548850991-11879-1-git-send-email-bhsharma@redhat.com> (raw)

With ARMv8.2-LVA and LPA architecture extensions, arm64 hardware which
supports these extensions can support upto 52-bit virtual and 52-bit
physical addresses respectively.

Since at the moment we enable the support of these extensions via CONFIG
flags, e.g.
 - LPA via CONFIG_ARM64_PA_BITS_52

there are no clear mechanisms in user-space right now to
deteremine these CONFIG flag values and also determine the PARange and
VARange address values.

User-space tools like 'makedumpfile' and 'crash-utility' can instead
use the 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' values to determine
the maximum virtual address and physical address (respectively)
supported by underlying kernel.

A reference 'makedumpfile' implementation which uses this approach to
determining the maximum physical address is available in [0].

[0]. https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-pa-support-via-vmcore-v1/arch/arm64.c#L490

Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
 arch/arm64/kernel/crash_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
index ca4c3e12d8c5..ad231be5c0d8 100644
--- a/arch/arm64/kernel/crash_core.c
+++ b/arch/arm64/kernel/crash_core.c
@@ -10,6 +10,8 @@
 void arch_crash_save_vmcoreinfo(void)
 {
 	VMCOREINFO_NUMBER(VA_BITS);
+	VMCOREINFO_NUMBER(MAX_USER_VA_BITS);
+	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
 	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
 	vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
 						kimage_voffset);
-- 
2.7.4


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

             reply	other threads:[~2019-01-30 12:23 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 12:23 Bhupesh Sharma [this message]
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 15:21   ` James Morse
2019-01-30 21:39   ` Bhupesh Sharma
2019-01-30 21:39     ` Bhupesh Sharma
2019-02-04 14:35     ` Bhupesh Sharma
2019-02-04 14:35       ` Bhupesh Sharma
2019-02-04 15:31       ` Robin Murphy
2019-02-04 15:31         ` Robin Murphy
2019-02-12  4:55         ` Bhupesh Sharma
2019-02-12  4:55           ` Bhupesh Sharma
2019-02-12 10:49           ` Robin Murphy
2019-02-12 10:49             ` Robin Murphy
2019-02-04 16:56       ` James Morse
2019-02-04 16:56         ` James Morse
2019-01-31  1:48 ` Dave Young
2019-01-31  1:48   ` Dave Young
2019-01-31 10:00   ` Bhupesh Sharma
2019-01-31 10:00     ` Bhupesh Sharma
2019-01-31 14:03   ` Dave Anderson
2019-01-31 14:03     ` Dave Anderson
2019-02-04 16:04   ` Kazuhito Hagio
2019-02-04 16:04     ` Kazuhito Hagio
2019-02-12  5:07     ` Bhupesh Sharma
2019-02-12  5:07       ` Bhupesh Sharma
2019-02-12 10:44       ` Dave Young
2019-02-12 10:44         ` Dave Young
2019-02-12 19:59         ` Bhupesh Sharma
2019-02-12 19:59           ` Bhupesh Sharma
2019-02-12 23:03           ` Kazuhito Hagio
2019-02-12 23:03             ` Kazuhito Hagio
2019-02-13 11:15             ` Dave Young
2019-02-13 11:15               ` Dave Young
2019-02-13 18:22               ` James Morse
2019-02-13 18:22                 ` James Morse
2019-02-13 19:52                 ` Kazuhito Hagio
2019-02-13 19:52                   ` Kazuhito Hagio
2019-02-15 17:34                   ` James Morse
2019-02-15 17:34                     ` James Morse
2019-02-15 18:01                     ` Bhupesh Sharma
2019-02-15 18:01                       ` Bhupesh Sharma
2019-02-18 15:27                       ` Steve Capper
2019-02-18 15:27                         ` Steve Capper
2019-02-21 16:08                         ` Bhupesh Sharma
2019-02-21 16:08                           ` Bhupesh Sharma
2019-02-19 20:47                       ` Kazuhito Hagio
2019-02-19 20:47                         ` Kazuhito Hagio
2019-02-21 16:20                         ` Bhupesh Sharma
2019-02-21 16:20                           ` Bhupesh Sharma
2019-02-21 16:42                           ` Dave Anderson
2019-02-21 16:42                             ` Dave Anderson
2019-02-21 19:02                             ` Kazuhito Hagio
2019-02-21 19:02                               ` Kazuhito Hagio
2019-03-01  4:01                               ` Bhupesh Sharma
2019-03-01  4:01                                 ` Bhupesh Sharma
2019-02-14 19:30                 ` 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=1548850991-11879-1-git-send-email-bhsharma@redhat.com \
    --to=bhsharma@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhupesh.linux@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.