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
WARNING: multiple messages have this Message-ID (diff)
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); > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-01-30 15:21 UTC|newest] Thread overview: 58+ 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 12:23 ` Bhupesh Sharma 2019-01-30 15:21 ` James Morse [this message] 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=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: linkBe 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.