linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
	kexec@lists.infradead.org, Will Deacon <will.deacon@arm.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	bhupesh.linux@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo
Date: Wed, 30 Jan 2019 15:21:09 +0000	[thread overview]
Message-ID: <239cdca4-1c7d-f236-f4a9-a0a3fe98f966@arm.com> (raw)
In-Reply-To: <1548850991-11879-1-git-send-email-bhsharma@redhat.com>

Hi Bhupesh,

On 01/30/2019 12:23 PM, Bhupesh Sharma wrote:
> 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].

Why does it need to know?

(Suzuki asked the same question on your earlier version)
https://lore.kernel.org/linux-arm-kernel/cff44754-7fe4-efea-bc8e-4dde2277c821@arm.com/


 From your github link it looks like you use this to re-assemble the two 
bits of the PFN from the pte. Can't you always do this for 64K pages? 
CPUs with the feature always do this too, its not something the kernel 
turns on.


Thanks,

James


> 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);
> 


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

  reply	other threads:[~2019-01-30 15:21 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 [this message]
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
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=239cdca4-1c7d-f236-f4a9-a0a3fe98f966@arm.com \
    --to=james.morse@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhsharma@redhat.com \
    --cc=bhupesh.linux@gmail.com \
    --cc=catalin.marinas@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 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).