Re: [PATCH v4 0/3] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)
Hi Bhupesh, Do you have a corresponding patch for userspace tools, including crash util and/or makedumpfile? Otherwise, we can't verify that a generated core file is correctly handled. Thanks, -Takahiro Akashi On Mon, Nov 11, 2019 at 01:31:19PM +0530, Bhupesh Sharma wrote: > Changes since v3: > > - v3 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html > - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo > instead of PTRS_PER_PGD. > - Added a new patch (via [PATCH 3/3]), which fixes a simple typo in > 'Documentation/arm64/memory.rst' > > Changes since v2: > > - v2 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022531.html > - Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM > ifdef sections, as suggested by Kazu. > - Updated vmcoreinfo documentation to add description about > 'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]). > > Changes since v1: > > - v1 was sent out as a single patch which can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-February/022411.html > > - v2 breaks the single patch into two independent patches: > [PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, whereas > [PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kernel code > (all archs) > > This patchset primarily fixes the regression reported in user-space > utilities like 'makedumpfile' and 'crash-utility' on arm64 architecture > with the availability of 52-bit address space feature in underlying > kernel. These regressions have been reported both on CPUs which don't > support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer kernels > and also on prototype platforms (like ARMv8 FVP simulator model) which > support ARMv8.2 extensions and are running newer kernels. > > The reason for these regressions is that right now user-space tools > have no direct access to these values (since these are not exported > from the kernel) and hence need to rely on a best-guess method of > determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' supported > by underlying kernel. > > Exporting these values via vmcoreinfo will help user-land in such cases. > In addition, as per suggestion from makedumpfile maintainer (Kazu), > it makes more sense to append 'MAX_PHYSMEM_BITS' to > vmcoreinfo in the core code itself rather than in arm64 arch-specific > code, so that the user-space code for other archs can also benefit from > this addition to the vmcoreinfo and use it as a standard way of > determining 'SECTIONS_SHIFT' value in user-land. > > Cc: Boris Petkov > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Jonathan Corbet > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Cc: Dave Anderson > Cc: Kazuhito Hagio > Cc: x...@kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: kexec@lists.infradead.org > > Bhupesh Sharma (3): > crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo > arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo > Documentation/arm64: Fix a simple typo in memory.rst > > Documentation/arm64/memory.rst | 2 +- > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > arch/arm64/kernel/crash_core.c | 9 + > kernel/crash_core.c| 1 + > 4 files changed, 12 insertions(+), 1 deletion(-) > > -- > 2.7.4 > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.4 41/48] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1cad055..414f9b52e58e6 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -66,7 +66,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.9 58/68] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 282630e4c6ea4..1624a7ffa95d8 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -66,7 +66,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.14 095/115] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index f327236f0fa71..5125fca472bb0 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,7 +67,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.14 072/115] kexec: Allocate decrypted control pages for kdump if SME is enabled
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is enabled.
[ bp: clean up text. ]
Signed-off-by: Lianbo Jiang
Signed-off-by: Borislav Petkov
Reviewed-by: Tom Lendacky
Cc: kexec@lists.infradead.org
Cc: t...@linutronix.de
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: a...@linux-foundation.org
Cc: dan.j.willi...@intel.com
Cc: bhelg...@google.com
Cc: baiyao...@cmss.chinamobile.com
Cc: ti...@suse.de
Cc: brijesh.si...@amd.com
Cc: dyo...@redhat.com
Cc: b...@redhat.com
Cc: jroe...@suse.de
Link: https://lkml.kernel.org/r/20180930031033.22110-3-liji...@redhat.com
Signed-off-by: Sasha Levin
---
kernel/kexec_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8f15665ab6167..27cf24e285e0c 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -473,6 +473,10 @@ static struct page
*kimage_alloc_crash_control_pages(struct kimage *image,
}
}
+ /* Ensure that these pages are decrypted if SME is enabled. */
+ if (pages)
+ arch_kexec_post_alloc_pages(page_address(pages), 1 << order, 0);
+
return pages;
}
@@ -867,6 +871,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
+ arch_kexec_post_alloc_pages(page_address(page), 1, 0);
ptr = kmap(page);
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
@@ -884,6 +889,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
kunmap(page);
+ arch_kexec_pre_free_pages(page_address(page), 1);
if (result) {
result = -EFAULT;
goto out;
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.19 176/209] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index f327236f0fa71..5125fca472bb0 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,7 +67,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH AUTOSEL 4.19 127/209] kexec: Allocate decrypted control pages for kdump if SME is enabled
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is enabled.
[ bp: clean up text. ]
Signed-off-by: Lianbo Jiang
Signed-off-by: Borislav Petkov
Reviewed-by: Tom Lendacky
Cc: kexec@lists.infradead.org
Cc: t...@linutronix.de
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: a...@linux-foundation.org
Cc: dan.j.willi...@intel.com
Cc: bhelg...@google.com
Cc: baiyao...@cmss.chinamobile.com
Cc: ti...@suse.de
Cc: brijesh.si...@amd.com
Cc: dyo...@redhat.com
Cc: b...@redhat.com
Cc: jroe...@suse.de
Link: https://lkml.kernel.org/r/20180930031033.22110-3-liji...@redhat.com
Signed-off-by: Sasha Levin
---
kernel/kexec_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f50b90d0d1c28..faeec8255e7e0 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -473,6 +473,10 @@ static struct page
*kimage_alloc_crash_control_pages(struct kimage *image,
}
}
+ /* Ensure that these pages are decrypted if SME is enabled. */
+ if (pages)
+ arch_kexec_post_alloc_pages(page_address(pages), 1 << order, 0);
+
return pages;
}
@@ -869,6 +873,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
+ arch_kexec_post_alloc_pages(page_address(page), 1, 0);
ptr = kmap(page);
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
@@ -886,6 +891,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
kunmap(page);
+ arch_kexec_pre_free_pages(page_address(page), 1);
if (result) {
result = -EFAULT;
goto out;
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
RE: [PATCH] makedumpfile: Fix wrong statistics in ELF format mode
> -Original Message-
> The -E option, which creates a dumpfile in ELF format, reports wrong
> statistics like the ones below, because:
> (1) counts excluded pages repeatedly due to overlapped cycles
> (2) does not calculate the number of memory hole pages in cyclic mode
> (3) does not take account of the number of pages excluded actually
> in ELF format, which excludes only contiguous 256 or more pages
> that can be excluded.
>
> Original pages : 0x
> Excluded pages : 0x007daf05
> Pages filled with zero : 0x2dcc
> Non-private cache pages : 0x000471d6
> Private cache pages : 0x0001
> User process data pages : 0x000147f1
> Free pages : 0x0077c771
> Hwpoison pages : 0x
> Offline pages : 0x
> Remaining pages : 0xff8250fb
> Memory Hole : 0x0044
> --
> Total pages : 0x0044
>
> In order to fix this issue:
> (1) start the first cycle from the start pfn of a segment to avoid
> overlaps between cycles
finally I found a fault with this change.
Will merge the following patch into the original one.
diff --git a/makedumpfile.c b/makedumpfile.c
index 9569251ce0c7..ac19ed858416 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -56,8 +56,13 @@ static void first_cycle(mdf_pfn_t start, mdf_pfn_t max,
struct cycle *cycle)
if (cycle->end_pfn > max)
cycle->end_pfn = max;
+ /*
+* Mitigate statistics problem in ELF dump mode.
+* A cycle must start with a pfn that is divisible by BITPERBYTE.
+* See create_bitmap_from_memhole().
+*/
if (info->flag_elf_dumpfile && cycle->start_pfn < start)
- cycle->start_pfn = start;
+ cycle->start_pfn = round(start, BITPERBYTE);
cycle->exclude_pfn_start = 0;
cycle->exclude_pfn_end = 0;
@@ -7503,7 +7508,7 @@ get_loads_dumpfile_cyclic(void)
if (!create_2nd_bitmap(&cycle))
return FALSE;
}
- for (pfn = cycle.start_pfn; pfn < cycle.end_pfn; pfn++)
{
+ for (pfn = MAX(pfn_start, cycle.start_pfn); pfn <
cycle.end_pfn; pfn++) {
if (!is_dumpable(info->bitmap2, pfn, &cycle)) {
num_excluded++;
continue;
@@ -7598,7 +7603,7 @@ write_elf_pages_cyclic(struct cache_data *cd_header,
struct cache_data *cd_page)
return FALSE;
}
- for (pfn = cycle.start_pfn; pfn < cycle.end_pfn; pfn++)
{
+ for (pfn = MAX(pfn_start, cycle.start_pfn); pfn <
cycle.end_pfn; pfn++) {
if (info->flag_cyclic)
pfn_memhole--;
Thanks,
Kazu
> (2) calculate the number of memory hole pages in cyclic mode
> (3) introduce pfn_elf_excluded variable to store the actual number
> of the excluded pages in ELF format
>
> With the patch, a report message in ELF format mode becomes like this:
>
> Original pages : 0x003f1538
> Excluded pages : 0x003c8c9d
>in ELF format : 0x003c4319
> Pages filled with zero : 0x26d8
> Non-private cache pages : 0x00047032
> Private cache pages : 0x0001
> User process data pages : 0x00014794
> Free pages : 0x0036adfe
> Hwpoison pages : 0x
> Offline pages : 0x
> Remaining pages : 0x0002889b
>in ELF format : 0x0002d21f
> (The number of pages is reduced to 4%.)
> Memory Hole : 0x0004eac8
> --
> Total pages : 0x0044
>
> where the "Excluded pages" and "Remaining pages" do not mean the
> actual numbers of excluded and remaining pages. But remain the
> same for some reference.
>
> Signed-off-by: Kazuhito Hagio
> ---
> makedumpfile.c | 27 +--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index 4a000112ba59..9569251ce0c7 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -56,6 +56,9 @@ static void first_cycle(mdf_pfn_t start, mdf_pfn_t max,
> struct cycle *cycle)
> if (cycle->end_pfn > max)
> cycle->end_pfn = max;
>
> + if (info->flag_elf_dumpfile && cycle->start_pfn < start)
> + cycle->start_pfn = start;
> +
> cycle->exclude_pfn_start = 0;
> cycle->exclude_pfn_end = 0;
> }
> @@ -89,6 +92,7 @@ mdf_pfn_t pfn_use
[RFC PATCH] efi: arm64: Introduce /sys/firmware/efi/memreserve to tell the persistent pages
From: Masayoshi Mizuma
kexec reboot stucks because efi_config_parse_tables() refers garbage
(with memblock=debug):
efi: ACPI 2.0=0x9821790014 PROP=0x8757f5c0 SMBIOS 3.0=0x982074
MEMRESERVE=0x9820bfdc58
memblock_reserve: [0x009820bfdc58-0x009820bfdc67]
efi_config_parse_tables+0x228/0x278
memblock_reserve: [0x8276-0x324d07ff]
efi_config_parse_tables+0x228/0x278
memblock_reserve: [0xcc4f84ecc0511670-0x5f6e5214a7fd91f9]
efi_config_parse_tables+0x244/0x278
memblock_reserve: [0xd2fd4144b9af693d-0xad0c1db1086f40a2]
efi_config_parse_tables+0x244/0x278
memblock_reserve: [0x0c719bb159b1fadc-0x5aa6e62a1417ce12]
efi_config_parse_tables+0x244/0x278
...
That happens because 0x8276, struct linux_efi_memreserve, is destroyed.
0x8276 is pointed from efi.mem_reseve, and efi.mem_reserve points the
head page of pending table and prop table which are allocated by
gic_reserve_range().
The destroyer is kexec. kexec locates the inird to the area:
# kexec -d -l /boot/vmlinuz-5.4.0-rc7 /boot/initramfs-5.4.0-rc7.img
--reuse-cmdline
...
initrd: base 8229, size 388dd8ah (59301258)
...
>From dynamic debug log:
machine_kexec_prepare:70:
kexec kimage info:
type:0
start: 85b30680
head:0
nr_segments: 4
segment[0]: 8048 - 8229, 0x1e1 bytes, 481
pages
segment[1]: 8229 - 85b2, 0x389 bytes, 905
pages
segment[2]: 85b2 - 85b3, 0x1 bytes, 1 pages
segment[3]: 85b3 - 85b4, 0x1 bytes, 1 pages
kexec searches the appropriate memory region to locate initrd through "System
RAM"
in /proc/iomem. The pending tables are included in "System RAM" because they are
allocated by alloc_pages(), so kexec destroys the pending tables.
Introduce /sys/firmware/efi/memreserve to tell the pages pointed by
efi.mem_reserve
so that kexec can avoid the area to locate initrd.
Signed-off-by: Masayoshi Mizuma
---
drivers/firmware/efi/efi.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index e98bbf8e5..67b21ae7a 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -141,6 +141,36 @@ static ssize_t systab_show(struct kobject *kobj,
static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
+static struct linux_efi_memreserve *efi_memreserve_root __ro_after_init;
+static ssize_t memreserve_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct linux_efi_memreserve *rsv;
+ unsigned long prsv;
+ char *str = buf;
+ int index, i;
+
+ if (!kobj || !buf)
+ return -EINVAL;
+
+ if (!efi_memreserve_root)
+ return -ENODEV;
+
+ for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) {
+ rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB);
+ index = atomic_read(&rsv->count);
+ for (i = 0; i < index; i++)
+ str += sprintf(str, "%llx-%llx\n",
+ rsv->entry[i].base,
+ rsv->entry[i].base + rsv->entry[i].size - 1);
+ memunmap(rsv);
+ }
+
+ return str - buf;
+}
+
+static struct kobj_attribute efi_attr_memreserve = __ATTR_RO_MODE(memreserve,
0444);
+
#define EFI_FIELD(var) efi.var
#define EFI_ATTR_SHOW(name) \
@@ -172,6 +202,7 @@ static struct attribute *efi_subsys_attrs[] = {
&efi_attr_runtime.attr,
&efi_attr_config_table.attr,
&efi_attr_fw_platform_size.attr,
+ &efi_attr_memreserve.attr,
NULL,
};
@@ -955,7 +986,6 @@ int efi_status_to_err(efi_status_t status)
}
static DEFINE_SPINLOCK(efi_mem_reserve_persistent_lock);
-static struct linux_efi_memreserve *efi_memreserve_root __ro_after_init;
static int __init efi_memreserve_map_root(void)
{
--
2.18.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 4/4] makedumpfile: Mark --mem-usage option unsupported for arm64
This patch marks '--mem-usage' option as unsupported for arm64
architecture.
With the newer arm64 kernels supporting 48-bit/52-bit VA address spaces
and keeping a single binary for supporting the same, the address of
kernel symbols like _stext which could be earlier used to determine
VA_BITS value, can no longer to determine whether VA_BITS is set to 48
or 52 in the kernel space.
Hence for now, it makes sense to mark '--mem-usage' option as
unsupported for arm64 architecture until we have more clarity from arm64
kernel maintainers on how to manage the same in future
kernel/makedumpfile versions.
Cc: John Donnelly
Cc: Kazuhito Hagio
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma
---
makedumpfile.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/makedumpfile.c b/makedumpfile.c
index baf559e4d74e..ae60466a1e9c 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -11564,6 +11564,11 @@ main(int argc, char *argv[])
MSG("\n");
MSG("The dmesg log is saved to %s.\n", info->name_dumpfile);
} else if (info->flag_mem_usage) {
+#ifdef __aarch64__
+ MSG("mem-usage not supported for arm64 architecure.\n");
+ goto out;
+#endif
+
if (!check_param_for_creating_dumpfile(argc, argv)) {
MSG("Commandline parameter is invalid.\n");
MSG("Try `makedumpfile --help' for more
information.\n");
--
2.7.4
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 1/4] tree-wide: Retrieve 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available)
This patch adds a common feature for archs (except arm64, for which
similar support is added via subsequent patch) to retrieve
'MAX_PHYSMEM_BITS' from vmcoreinfo (if available).
I recently posted a kernel patch (see [0]) which appends
'MAX_PHYSMEM_BITS' to vmcoreinfo in the core code itself rather than
in arch-specific code, so that user-space code can also benefit from
this addition to the vmcoreinfo and use it as a standard way of
determining 'SECTIONS_SHIFT' value in 'makedumpfile' utility.
This patch ensures backward compatibility for kernel versions in which
'MAX_PHYSMEM_BITS' is not available in vmcoreinfo.
[0]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
Cc: Kazuhito Hagio
Cc: John Donnelly
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma
---
arch/arm.c | 8 +++-
arch/ia64.c| 7 ++-
arch/ppc.c | 8 +++-
arch/ppc64.c | 49 -
arch/s390x.c | 29 ++---
arch/sparc64.c | 9 +++--
arch/x86.c | 34 --
arch/x86_64.c | 27 ---
8 files changed, 109 insertions(+), 62 deletions(-)
diff --git a/arch/arm.c b/arch/arm.c
index af7442ac70bf..33536fc4dfc9 100644
--- a/arch/arm.c
+++ b/arch/arm.c
@@ -81,7 +81,13 @@ int
get_machdep_info_arm(void)
{
info->page_offset = SYMBOL(_stext) & 0xUL;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
+ /* Check if we can get MAX_PHYSMEM_BITS from vmcoreinfo */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER)
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
+ else
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
info->kernel_start = SYMBOL(_stext);
info->section_size_bits = _SECTION_SIZE_BITS;
diff --git a/arch/ia64.c b/arch/ia64.c
index 6c33cc7c8288..fb44dda47172 100644
--- a/arch/ia64.c
+++ b/arch/ia64.c
@@ -85,7 +85,12 @@ get_machdep_info_ia64(void)
}
info->section_size_bits = _SECTION_SIZE_BITS;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
+ /* Check if we can get MAX_PHYSMEM_BITS from vmcoreinfo */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER)
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
+ else
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS;
return TRUE;
}
diff --git a/arch/ppc.c b/arch/ppc.c
index 37c6a3b60cd3..ed9447427a30 100644
--- a/arch/ppc.c
+++ b/arch/ppc.c
@@ -31,7 +31,13 @@ get_machdep_info_ppc(void)
unsigned long vmlist, vmap_area_list, vmalloc_start;
info->section_size_bits = _SECTION_SIZE_BITS;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
+ /* Check if we can get MAX_PHYSMEM_BITS from vmcoreinfo */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER)
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
+ else
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
info->page_offset = __PAGE_OFFSET;
if (SYMBOL(_stext) != NOT_FOUND_SYMBOL)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 9d8f2525f608..a3984eebdced 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -466,30 +466,37 @@ int
set_ppc64_max_physmem_bits(void)
{
long array_len = ARRAY_LENGTH(mem_section);
- /*
-* The older ppc64 kernels uses _MAX_PHYSMEM_BITS as 42 and the
-* newer kernels 3.7 onwards uses 46 bits.
-*/
-
- info->max_physmem_bits = _MAX_PHYSMEM_BITS_ORIG ;
- if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
- || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT(
- return TRUE;
-
- info->max_physmem_bits = _MAX_PHYSMEM_BITS_3_7;
- if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
- || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT(
- return TRUE;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS_4_19;
- if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
- || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT(
+ /* Check if we can get MAX_PHYSMEM_BITS from vmcoreinfo */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER) {
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
return TRUE;
+ } else {
+ /*
+* The older ppc64 kernels uses _MAX_PHYSMEM_BITS as 42 and the
+* newer kernels 3.7 onwards uses 46 bits.
+*/
- info->max_physmem_bits = _MAX_PHYSMEM_BITS_4_20;
- if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
- || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT(
- return TRUE;
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS_ORIG ;
+ if ((array_len == (NR_MEM_SECTIONS() /
_SECTIONS_PE
[PATCH v4 2/4] makedumpfile/arm64: Add support for ARMv8.2-LPA (52-bit PA support)
ARMv8.2-LPA architecture extension (if available on underlying hardware)
can support 52-bit physical addresses, while the kernel virtual
addresses remain 48-bit.
Make sure that we read the 52-bit PA address capability from
'MAX_PHYSMEM_BITS' variable (if available in vmcoreinfo) and
accordingly change the pte_to_phy() mask values and also traverse
the page-table walk accordingly.
Also make sure that it works well for the existing 48-bit PA address
platforms and also on environments which use newer kernels with 52-bit
PA support but hardware which is not ARM8.2-LPA compliant.
I have sent a kernel patch upstream to add 'MAX_PHYSMEM_BITS' to
vmcoreinfo for arm64 (see [0]).
This patch is in accordance with ARMv8 Architecture Reference Manual
version D.a
[0]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html
Cc: Kazuhito Hagio
Cc: John Donnelly
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma
---
arch/arm64.c | 292 +--
1 file changed, 204 insertions(+), 88 deletions(-)
diff --git a/arch/arm64.c b/arch/arm64.c
index 3516b340adfd..ecb19139e178 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -39,72 +39,184 @@ typedef struct {
unsigned long pte;
} pte_t;
+#define __pte(x) ((pte_t) { (x) } )
+#define __pmd(x) ((pmd_t) { (x) } )
+#define __pud(x) ((pud_t) { (x) } )
+#define __pgd(x) ((pgd_t) { (x) } )
+
+static int lpa_52_bit_support_available;
static int pgtable_level;
static int va_bits;
static unsigned long kimage_voffset;
-#define SZ_4K (4 * 1024)
-#define SZ_16K (16 * 1024)
-#define SZ_64K (64 * 1024)
-#define SZ_128M(128 * 1024 * 1024)
+#define SZ_4K 4096
+#define SZ_16K 16384
+#define SZ_64K 65536
-#define PAGE_OFFSET_36 ((0xUL) << 36)
-#define PAGE_OFFSET_39 ((0xUL) << 39)
-#define PAGE_OFFSET_42 ((0xUL) << 42)
-#define PAGE_OFFSET_47 ((0xUL) << 47)
-#define PAGE_OFFSET_48 ((0xUL) << 48)
+#define PAGE_OFFSET_36 ((0xUL) << 36)
+#define PAGE_OFFSET_39 ((0xUL) << 39)
+#define PAGE_OFFSET_42 ((0xUL) << 42)
+#define PAGE_OFFSET_47 ((0xUL) << 47)
+#define PAGE_OFFSET_48 ((0xUL) << 48)
+#define PAGE_OFFSET_52 ((0xUL) << 52)
#define pgd_val(x) ((x).pgd)
#define pud_val(x) (pgd_val((x).pgd))
#define pmd_val(x) (pud_val((x).pud))
#define pte_val(x) ((x).pte)
-#define PAGE_MASK (~(PAGESIZE() - 1))
-#define PGDIR_SHIFT((PAGESHIFT() - 3) * pgtable_level + 3)
-#define PTRS_PER_PGD (1 << (va_bits - PGDIR_SHIFT))
-#define PUD_SHIFT get_pud_shift_arm64()
-#define PUD_SIZE (1UL << PUD_SHIFT)
-#define PUD_MASK (~(PUD_SIZE - 1))
-#define PTRS_PER_PTE (1 << (PAGESHIFT() - 3))
-#define PTRS_PER_PUD PTRS_PER_PTE
-#define PMD_SHIFT ((PAGESHIFT() - 3) * 2 + 3)
-#define PMD_SIZE (1UL << PMD_SHIFT)
-#define PMD_MASK (~(PMD_SIZE - 1))
+/* See 'include/uapi/linux/const.h' for definitions below */
+#define __AC(X,Y) (X##Y)
+#define _AC(X,Y) __AC(X,Y)
+#define _AT(T,X) ((T)(X))
+
+/* See 'include/asm/pgtable-types.h' for definitions below */
+typedef unsigned long pteval_t;
+typedef unsigned long pmdval_t;
+typedef unsigned long pudval_t;
+typedef unsigned long pgdval_t;
+
+#define PAGE_SHIFT PAGESHIFT()
+
+/* See 'arch/arm64/include/asm/pgtable-hwdef.h' for definitions below */
+
+#define ARM64_HW_PGTABLE_LEVEL_SHIFT(n)((PAGE_SHIFT - 3) * (4 - (n)) +
3)
+
+#define PTRS_PER_PTE (1 << (PAGE_SHIFT - 3))
+
+/*
+ * PMD_SHIFT determines the size a level 2 page table entry can map.
+ */
+#define PMD_SHIFT ARM64_HW_PGTABLE_LEVEL_SHIFT(2)
+#define PMD_SIZE (_AC(1, UL) << PMD_SHIFT)
+#define PMD_MASK (~(PMD_SIZE-1))
#define PTRS_PER_PMD PTRS_PER_PTE
-#define PAGE_PRESENT (1 << 0)
+/*
+ * PUD_SHIFT determines the size a level 1 page table entry can map.
+ */
+#define PUD_SHIFT ARM64_HW_PGTABLE_LEVEL_SHIFT(1)
+#define PUD_SIZE (_AC(1, UL) << PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE-1))
+#define PTRS_PER_PUD PTRS_PER_PTE
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map
+ * (depending on the configuration, this level can be 0, 1 or 2).
+ */
+#define PGDIR_SHIFTARM64_HW_PGTABLE_LEVEL_SHIFT(4 -
(pgtable_level))
+#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+#define PTRS_PER_PGD (1 << ((va_bits) - PGDIR_SHIFT))
+
+/*
+ * S
[PATCH v4 3/4] makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA support)
With ARMv8.2-LVA architecture extension availability, arm64 hardware
which supports this extension can support upto 52-bit virtual
addresses. It is specially useful for having a 52-bit user-space virtual
address space while the kernel can still retain 48-bit/52-bit virtual
addressing.
Since at the moment we enable the support of this extension in the
kernel via a CONFIG flag (CONFIG_ARM64_VA_BITS_52), so there are
no clear mechanisms in user-space to determine this CONFIG
flag value and use it to determine the kernel-space VA address range
values.
'makedumpfile' can instead use 'TCR_EL1.T1SZ' value from vmcoreinfo
which indicates the size offset of the memory region addressed by
TTBR1_EL1 (and hence can be used for determining the
vabits_actual value).
The user-space computation for determining whether an address lies in
the linear map range is the same as we have in kernel-space:
#define __is_lm_address(addr) (!(((u64)addr) & BIT(vabits_actual - 1)))
I have sent a kernel patch upstream to add 'TCR_EL1.T1SZ' to
vmcoreinfo for arm64 (see [0]).
This patch is in accordance with ARMv8 Architecture Reference Manual
version D.a
Note that with these changes the '--mem-usage' option will not work
properly for arm64 (a subsequent patch in this series will address the
same) and there is a discussion on-going with the arm64 maintainers to
find a way-out for the same (via standard kernel symbols like _stext).
[0].http://lists.infradead.org/pipermail/kexec/2019-November/023962.html
Cc: Kazuhito Hagio
Cc: John Donnelly
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma
---
arch/arm64.c | 148 +
makedumpfile.c | 2 +
makedumpfile.h | 3 +-
3 files changed, 122 insertions(+), 31 deletions(-)
diff --git a/arch/arm64.c b/arch/arm64.c
index ecb19139e178..094d73b8a60f 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -47,6 +47,7 @@ typedef struct {
static int lpa_52_bit_support_available;
static int pgtable_level;
static int va_bits;
+static int vabits_actual;
static unsigned long kimage_voffset;
#define SZ_4K 4096
@@ -218,12 +219,19 @@ pmd_page_paddr(pmd_t pmd)
#define pte_index(vaddr) (((vaddr) >> PAGESHIFT()) &
(PTRS_PER_PTE - 1))
#define pte_offset(dir, vaddr) (pmd_page_paddr((*dir)) +
pte_index(vaddr) * sizeof(pte_t))
+/*
+ * The linear kernel range starts at the bottom of the virtual address
+ * space. Testing the top bit for the start of the region is a
+ * sufficient check and avoids having to worry about the tag.
+ */
+#define is_linear_addr(addr) (!(((unsigned long)addr) & (1UL <<
(vabits_actual - 1
+
static unsigned long long
__pa(unsigned long vaddr)
{
if (kimage_voffset == NOT_FOUND_NUMBER ||
- (vaddr >= PAGE_OFFSET))
- return (vaddr - PAGE_OFFSET + info->phys_base);
+ is_linear_addr(vaddr))
+ return (vaddr + info->phys_base - PAGE_OFFSET);
else
return (vaddr - kimage_voffset);
}
@@ -253,6 +261,7 @@ static int calculate_plat_config(void)
(PAGESIZE() == SZ_64K && va_bits == 42)) {
pgtable_level = 2;
} else if ((PAGESIZE() == SZ_64K && va_bits == 48) ||
+ (PAGESIZE() == SZ_64K && va_bits == 52) ||
(PAGESIZE() == SZ_4K && va_bits == 39) ||
(PAGESIZE() == SZ_16K && va_bits == 47)) {
pgtable_level = 3;
@@ -287,6 +296,16 @@ get_phys_base_arm64(void)
return TRUE;
}
+ /* If both vabits_actual and va_bits are now initialized, always
+* prefer vabits_actual over va_bits to calculate PAGE_OFFSET
+* value.
+*/
+ if (vabits_actual && va_bits && vabits_actual != va_bits) {
+ info->page_offset = (-(1UL << vabits_actual));
+ DEBUG_MSG("page_offset: %lx (via vabits_actual)\n",
+ info->page_offset);
+ }
+
if (get_num_pt_loads() && PAGE_OFFSET) {
for (i = 0;
get_pt_load(i, &phys_start, NULL, &virt_start, NULL);
@@ -406,6 +425,73 @@ get_stext_symbol(void)
return(found ? kallsym : FALSE);
}
+static int
+get_va_bits_from_stext_arm64(void)
+{
+ ulong _stext;
+
+ _stext = get_stext_symbol();
+ if (!_stext) {
+ ERRMSG("Can't get the symbol of _stext.\n");
+ return FALSE;
+ }
+
+ /* Derive va_bits as per arch/arm64/Kconfig. Note that this is a
+* best case approximation at the moment, as there can be
+* inconsistencies in this calculation (for e.g., for
+* 52-bit kernel VA case, even the 48th bit might be set in
+* the _stext symbol).
+*
+* So, we need to rely on the actual VA_BITS symbol in the
+* vmcoreinfo for a accurate value.
+*
+* TODO:
[PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
Changes since v3: - v3 can be seen here: http://lists.infradead.org/pipermail/kexec/2019-March/022534.html - Added a new patch (via [PATCH 4/4]) which marks '--mem-usage' option as unsupported for arm64 architecture. With the newer arm64 kernels supporting 48-bit/52-bit VA address spaces and keeping a single binary for supporting the same, the address of kernel symbols like _stext, which could be earlier used to determine VA_BITS value, can no longer to determine whether VA_BITS is set to 48 or 52 in the kernel space. Hence for now, it makes sense to mark '--mem-usage' option as unsupported for arm64 architecture until we have more clarity from arm64 kernel maintainers on how to manage the same in future kernel/makedumpfile versions. Changes since v2: - v2 can be seen here: http://lists.infradead.org/pipermail/kexec/2019-February/022456.html - I missed some comments from Kazu sent on the LVA v1 patch when I sent out the v2. So, addressing them now in v3. - Also added a patch that adds a tree-wide feature to read 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available). Changes since v1: - v1 was sent as two separate patches: http://lists.infradead.org/pipermail/kexec/2019-February/022424.html (ARMv8.2-LPA) http://lists.infradead.org/pipermail/kexec/2019-February/022425.html (ARMv8.2-LVA) - v2 combined the two in a single patchset and also addresses Kazu's review comments. This patchset adds support for ARMv8.2 extensions in makedumpfile code. I cover the following two cases with this patchset: - 48-bit kernel VA + 52-bit PA (LPA) - 52-bit kernel VA (LVA) + 52-bit PA (LPA) - 48-bit kernel VA + 52-bit user-space VA (LVA) - 52-bit kernel VA + 52-bit user-space VA (Full LVA) This has been tested for the following user-cases: 1. Creating a dumpfile using /proc/vmcore, 2. Creating a dumpfile using /proc/kcore, and 3. Post-processing a vmcore. I have tested this patchset on the following platforms, with kernels which support/do-not-support ARMv8.2 features: 1. CPUs which don't support ARMv8.2 features, e.g. qualcomm-amberwing, ampere-osprey. 2. Prototype models which support ARMv8.2 extensions (e.g. ARMv8 FVP simulation model). Also a preparation patch has been added in this patchset which adds a common feature for archs (except arm64, for which similar support is added via subsequent patch) to retrieve 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available). I recently posted two kernel patches (see [0] and [1]) which append 'TCR_EL1.T1SZ' and 'MAX_PHYSMEM_BITS' to vmcoreinfo in the kernel code, so that user-space code can benefit from the same. This patchset ensures backward compatibility for kernel versions in which 'TCR_EL1.T1SZ' and 'MAX_PHYSMEM_BITS' are not available in vmcoreinfo. [0]. http://lists.infradead.org/pipermail/kexec/2019-November/023960.html [1]. http://lists.infradead.org/pipermail/kexec/2019-November/023962.html Cc: John Donnelly Cc: Kazuhito Hagio Cc: kexec@lists.infradead.org Bhupesh Sharma (4): tree-wide: Retrieve 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available) makedumpfile/arm64: Add support for ARMv8.2-LPA (52-bit PA support) makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA support) makedumpfile: Mark --mem-usage option unsupported for arm64 arch/arm.c | 8 +- arch/arm64.c | 438 ++--- arch/ia64.c| 7 +- arch/ppc.c | 8 +- arch/ppc64.c | 49 --- arch/s390x.c | 29 ++-- arch/sparc64.c | 9 +- arch/x86.c | 34 +++-- arch/x86_64.c | 27 ++-- makedumpfile.c | 7 + makedumpfile.h | 3 +- 11 files changed, 439 insertions(+), 180 deletions(-) -- 2.7.4 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
