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@xxxxxxx/
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
