Re: [PATCH 1/3] kexec_load: Use new kexec flag for hotplug support
Hello sourabh,
On 29/05/24 18:43, Sourabh Jain wrote:
Hello Aditya,
On 28/05/24 17:03, Aditya Gupta wrote:
diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index 49f35b1..34531f9 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -148,3 +148,8 @@ int have_sysfs_fdt(void)
{
return !access(SYSFS_FDT, F_OK);
}
+
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/arm64/kexec-arm64.c
b/kexec/arch/arm64/kexec-arm64.c
index 4a67b0d..9d052b0 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -1363,3 +1363,7 @@ void arch_reuse_initrd(void)
void arch_update_purgatory(struct kexec_info *UNUSED(info))
{
}
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/cris/kexec-cris.c
b/kexec/arch/cris/kexec-cris.c
index 3b69709..7f09121 100644
--- a/kexec/arch/cris/kexec-cris.c
+++ b/kexec/arch/cris/kexec-cris.c
@@ -109,3 +109,7 @@ unsigned long add_buffer(struct kexec_info
*info, const void *buf,
buf_min, buf_max, buf_end, 1);
}
+int arch_do_exclude_segment(struct kexec_segment
*UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/hppa/kexec-hppa.c
b/kexec/arch/hppa/kexec-hppa.c
index 77c9739..a64dc3d 100644
--- a/kexec/arch/hppa/kexec-hppa.c
+++ b/kexec/arch/hppa/kexec-hppa.c
@@ -146,3 +146,8 @@ unsigned long virt_to_phys(unsigned long addr)
{
return addr - phys_offset;
}
+
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
index 444cb69..b4947a0 100644
--- a/kexec/arch/i386/kexec-x86.c
+++ b/kexec/arch/i386/kexec-x86.c
@@ -208,3 +208,11 @@ void arch_update_purgatory(struct kexec_info
*info)
elf_rel_set_symbol(>rhdr, "panic_kernel",
_kernel, sizeof(panic_kernel));
}
+
+int arch_do_exclude_segment(struct kexec_segment *seg_ptr, struct
kexec_info *info)
+{
+ if (info->elfcorehdr == (unsigned long) seg_ptr->mem)
+ return 1;
+
+ return 0;
+}
diff --git a/kexec/arch/ia64/kexec-ia64.c
b/kexec/arch/ia64/kexec-ia64.c
index 418d997..8d9c1f3 100644
--- a/kexec/arch/ia64/kexec-ia64.c
+++ b/kexec/arch/ia64/kexec-ia64.c
@@ -245,3 +245,7 @@ void arch_update_purgatory(struct kexec_info
*UNUSED(info))
{
}
+int arch_do_exclude_segment(struct kexec_segment
*UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/loongarch/kexec-loongarch.c
b/kexec/arch/loongarch/kexec-loongarch.c
index 32a42d2..9a50ff6 100644
--- a/kexec/arch/loongarch/kexec-loongarch.c
+++ b/kexec/arch/loongarch/kexec-loongarch.c
@@ -378,3 +378,8 @@ unsigned long add_buffer(struct kexec_info
*info, const void *buf,
return add_buffer_phys_virt(info, buf, bufsz, memsz, buf_align,
buf_min, buf_max, buf_end, 1);
}
+
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/m68k/kexec-m68k.c
b/kexec/arch/m68k/kexec-m68k.c
index cb54927..0c7dbaf 100644
--- a/kexec/arch/m68k/kexec-m68k.c
+++ b/kexec/arch/m68k/kexec-m68k.c
@@ -108,3 +108,8 @@ void add_segment(struct kexec_info *info, const
void *buf, size_t bufsz,
{
add_segment_phys_virt(info, buf, bufsz, base, memsz, 1);
}
+
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/mips/kexec-mips.c
b/kexec/arch/mips/kexec-mips.c
index d8cbea8..94224ee 100644
--- a/kexec/arch/mips/kexec-mips.c
+++ b/kexec/arch/mips/kexec-mips.c
@@ -189,3 +189,7 @@ unsigned long add_buffer(struct kexec_info
*info, const void *buf,
buf_min, buf_max, buf_end, 1);
}
+int arch_do_exclude_segment(const void *UNUSED(seg_ptr), struct
kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/ppc/kexec-ppc.c b/kexec/arch/ppc/kexec-ppc.c
index 03bec36..c8af870 100644
--- a/kexec/arch/ppc/kexec-ppc.c
+++ b/kexec/arch/ppc/kexec-ppc.c
@@ -966,3 +966,7 @@ void arch_update_purgatory(struct kexec_info
*UNUSED(info))
{
}
+int arch_do_exclude_segment(struct kexec_segment
*UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
+{
+ return 0;
+}
diff --git a/kexec/arch/ppc64/kexec-ppc64.c
b/kexec/arch/ppc64/kexec-ppc64.c
index bd5274c..fb27b6b 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -967,3 +967,8 @@ int arch_compat_trampoline(struct kexec_info
*UNUSED(info))
void arch_update_purgatory(struct kexec_info *UNUSED(info))
{
}
+
+int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr),
struct kexe
Re: [PATCH 1/3] kexec_load: Use new kexec flag for hotplug support
Hello sourabh,
On Wed, May 22, 2024 at 06:43:51PM GMT, Sourabh Jain wrote:
> Kernel commit 79365026f869 (crash: add a new kexec flag for hotplug
> support) has introduced a new kexec flag to generalize hotplug support.
> The newly introduced kexec flags for hotplug allow architectures to
> exclude all the required kexec segments from SHA calculation so that
> the kernel can update them on hotplug events. This was not possible
> earlier with the KEXEC_UPDATE_ELFCOREHDR kexec flags since it was added
> only for the elfcorehdr segment.
>
> To enable architectures to control the list of kexec segments to exclude
> when hotplug support is enabled, add a new architecture-specific
> function named arch_do_exclude_segment. During the SHA calculation, this
> function gets called to let the architecture decide whether a specific
> kexec segment should be considered for SHA calculation or not.
>
> Given that the KEXEC_UPDATE_ELFCOREHDR is no longer required and was
> colliding with the KEXEC_LIVE_UPDATE update flag, it is removed.
>
> Cc: Aditya Gupta
> Cc: Baoquan He
> Cc: Coiby Xu
> Cc: Hari Bathini
> Cc: Mahesh Salgaonkar
> Signed-off-by: Sourabh Jain
> ---
> kexec/arch/arm/kexec-arm.c | 5 +
> kexec/arch/arm64/kexec-arm64.c | 4
> kexec/arch/cris/kexec-cris.c | 4
> kexec/arch/hppa/kexec-hppa.c | 5 +
> kexec/arch/i386/kexec-x86.c| 8
> kexec/arch/ia64/kexec-ia64.c | 4
> kexec/arch/loongarch/kexec-loongarch.c | 5 +
> kexec/arch/m68k/kexec-m68k.c | 5 +
> kexec/arch/mips/kexec-mips.c | 4
> kexec/arch/ppc/kexec-ppc.c | 4
> kexec/arch/ppc64/kexec-ppc64.c | 5 +
> kexec/arch/s390/kexec-s390.c | 5 +
> kexec/arch/sh/kexec-sh.c | 5 +
> kexec/arch/x86_64/kexec-x86_64.c | 5 +
> kexec/kexec-syscall.h | 2 +-
> kexec/kexec.c | 14 --
> kexec/kexec.h | 2 ++
> 17 files changed, 79 insertions(+), 7 deletions(-)
>
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index 49f35b1..34531f9 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -148,3 +148,8 @@ int have_sysfs_fdt(void)
> {
> return !access(SYSFS_FDT, F_OK);
> }
> +
> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct
> kexec_info *UNUSED(info))
> +{
> + return 0;
> +}
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 4a67b0d..9d052b0 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -1363,3 +1363,7 @@ void arch_reuse_initrd(void)
> void arch_update_purgatory(struct kexec_info *UNUSED(info))
> {
> }
> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct
> kexec_info *UNUSED(info))
> +{
> + return 0;
> +}
> diff --git a/kexec/arch/cris/kexec-cris.c b/kexec/arch/cris/kexec-cris.c
> index 3b69709..7f09121 100644
> --- a/kexec/arch/cris/kexec-cris.c
> +++ b/kexec/arch/cris/kexec-cris.c
> @@ -109,3 +109,7 @@ unsigned long add_buffer(struct kexec_info *info, const
> void *buf,
> buf_min, buf_max, buf_end, 1);
> }
>
> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct
> kexec_info *UNUSED(info))
> +{
> + return 0;
> +}
> diff --git a/kexec/arch/hppa/kexec-hppa.c b/kexec/arch/hppa/kexec-hppa.c
> index 77c9739..a64dc3d 100644
> --- a/kexec/arch/hppa/kexec-hppa.c
> +++ b/kexec/arch/hppa/kexec-hppa.c
> @@ -146,3 +146,8 @@ unsigned long virt_to_phys(unsigned long addr)
> {
> return addr - phys_offset;
> }
> +
> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct
> kexec_info *UNUSED(info))
> +{
> + return 0;
> +}
> diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
> index 444cb69..b4947a0 100644
> --- a/kexec/arch/i386/kexec-x86.c
> +++ b/kexec/arch/i386/kexec-x86.c
> @@ -208,3 +208,11 @@ void arch_update_purgatory(struct kexec_info *info)
> elf_rel_set_symbol(>rhdr, "panic_kernel",
> _kernel, sizeof(panic_kernel));
> }
> +
> +int arch_do_exclude_segment(struct kexec_segment *seg_ptr, struct kexec_info
> *info)
> +{
> + if (info->elfcorehdr == (unsigned long) seg_ptr->mem)
> + return 1;
> +
> + return 0;
> +}
> diff --git a/kexec/arch/ia64/kexec-ia64.c b/kexec/arch/ia64/kexec-ia64.c
> index 418d997..8d9c1f3 100644
> --- a/kexec/arch/ia64/kexec-i
Re: [PATCH] makedumpfile: ppc64: get vmalloc start address from vmcoreinfo
On 18/03/24 14:18, HAGIO KAZUHITO(萩尾 一仁) wrote:
On 2024/03/18 17:26, Aditya Gupta wrote:
Hi,
The commit removing 'vmap_area_list' is now merged in Linux mainline tree.
commit: 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Applied with this commit id and the fix.
https://github.com/makedumpfile/makedumpfile/commit/94241fd2feed059227a243618f2acc6aabf366e8
Thanks Kazu.
- Aditya Gupta
Thanks,
Kazu
Any comments on this patch ?
Thanks,
Aditya Gupta
On 24/02/24 00:33, Aditya Gupta wrote:
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
...
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to
read non-existent page at 0xc.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0,
addr:c00c, size:16384
[ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't
read the buffer of struct page.
[ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude
unnecessary pages.
[ 17.562632] kdump.sh[404]: The kernel version is not supported.
[ 17.562708] kdump.sh[404]: The makedumpfile operation may be
incomplete.
[ 17.562773] kdump.sh[404]: makedumpfile Failed.
[ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
from the vmcore.
'vmap_area_list' was removed in the linux kernel with below commit:
commit 378eb24a0658dd922b29524e0ce35c6c43f56cba
mm/vmalloc: remove vmap_area_list
Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
get base address of vmalloc area, instead of depending on
'vmap_area_list'
Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
1. Set vmalloc_start based on 'VMALLOC_START'
2. Don't error if vmap_area_list/vmlist are not defined
Reported-by: Sachin Sant
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 19 +--
makedumpfile.c | 3 ++-
makedumpfile.h | 6 +++---
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..bb62e2cd199a 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -568,7 +568,9 @@ get_machdep_info_ppc64(void)
/*
* Get vmalloc_start value from either vmap_area_list or vmlist.
*/
- if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
+ if (NUMBER(vmalloc_start) != NOT_FOUND_SYMBOL) {
+ vmalloc_start = NUMBER(vmalloc_start);
+ } else if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
&& (OFFSET(vmap_area.va_start) != NOT_FOUND_STRUCTURE)
&& (OFFSET(vmap_area.list) != NOT_FOUND_STRUCTURE)) {
if (!readmem(VADDR, SYMBOL(vmap_area_list) +
OFFSET(list_head.next),
@@ -684,11 +686,16 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
if ((SYMBOL(vmap_area_list) == NOT_FOUND_SYMBOL)
|| (OFFSET(vmap_area.va_start) == NOT_FOUND_STRUCTURE)
|| (OFFSET(vmap_area.list) == NOT_FOUND_STRUCTURE)) {
- if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
- || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
- ERRMSG("Can't get info for vmalloc translation.\n");
- return NOT_PADDR;
- }
+ /*
+ * Don't depend on vmap_area_list/vmlist if vmalloc_start is
set in
+ * vmcoreinfo, in that case proceed without error
+ */
+ if (NUMBER(vmalloc_start) == NOT_FOUND_NUMBER)
+ if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+ || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
+ ERRMSG("Can't get info for vmalloc translation.\n");
+ return NOT_PADDR;
+ }
}
return ppc64_vtop_level4(vaddr);
diff --git a/makedumpfile.c b/makedumpfile.c
index b004b93fecb7..b6c63fad15f3 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2978,6 +2978,8 @@ read_vmcoreinfo(void)
READ_NUMBER("PAGE_OFFLINE_MAPCOUNT_VALUE",
PAGE_OFFLINE_MAPCOUNT_VALUE);
READ_NUMBER("phys_base", phys_base);
READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+
+ READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
#ifdef __aarch64__
READ_NUMBER("VA_BITS", VA_BITS);
READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
@@ -2989,7 +2991,6 @@ read_vmcoreinfo(void)
READ_NUMBER("VA_BITS", va_bits);
READ_NUMBER_UNSIGNED("phys_ram_base", phys_ram_base);
READ_NUMBER_UNSIGNED("PAGE_OFFSET", page_offset);
- READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
READ_NUMBER_UNSIGNED("VMALLOC_END", vmalloc_end);
READ_NUMBER_UNSIGNED("VMEMMAP_START", vmemmap_start);
READ_NUMBER_UNSIGNED("VMEMMAP_END", vmemmap_end);
diff --git a/makedumpfile.h b/makedumpfile.h
index 59c83e1d9df3..4021c5
Re: [PATCH] makedumpfile: ppc64: get vmalloc start address from vmcoreinfo
Hi,
The commit removing 'vmap_area_list' is now merged in Linux mainline tree.
commit: 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Any comments on this patch ?
Thanks,
Aditya Gupta
On 24/02/24 00:33, Aditya Gupta wrote:
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
...
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read
non-existent page at 0xc.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0, addr:c00c,
size:16384
[ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't read the
buffer of struct page.
[ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude unnecessary
pages.
[ 17.562632] kdump.sh[404]: The kernel version is not supported.
[ 17.562708] kdump.sh[404]: The makedumpfile operation may be incomplete.
[ 17.562773] kdump.sh[404]: makedumpfile Failed.
[ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
from the vmcore.
'vmap_area_list' was removed in the linux kernel with below commit:
commit 378eb24a0658dd922b29524e0ce35c6c43f56cba
mm/vmalloc: remove vmap_area_list
Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
get base address of vmalloc area, instead of depending on 'vmap_area_list'
Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
1. Set vmalloc_start based on 'VMALLOC_START'
2. Don't error if vmap_area_list/vmlist are not defined
Reported-by: Sachin Sant
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 19 +--
makedumpfile.c | 3 ++-
makedumpfile.h | 6 +++---
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..bb62e2cd199a 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -568,7 +568,9 @@ get_machdep_info_ppc64(void)
/*
* Get vmalloc_start value from either vmap_area_list or vmlist.
*/
- if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
+ if (NUMBER(vmalloc_start) != NOT_FOUND_SYMBOL) {
+ vmalloc_start = NUMBER(vmalloc_start);
+ } else if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
&& (OFFSET(vmap_area.va_start) != NOT_FOUND_STRUCTURE)
&& (OFFSET(vmap_area.list) != NOT_FOUND_STRUCTURE)) {
if (!readmem(VADDR, SYMBOL(vmap_area_list) +
OFFSET(list_head.next),
@@ -684,11 +686,16 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
if ((SYMBOL(vmap_area_list) == NOT_FOUND_SYMBOL)
|| (OFFSET(vmap_area.va_start) == NOT_FOUND_STRUCTURE)
|| (OFFSET(vmap_area.list) == NOT_FOUND_STRUCTURE)) {
- if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
- || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
- ERRMSG("Can't get info for vmalloc translation.\n");
- return NOT_PADDR;
- }
+ /*
+* Don't depend on vmap_area_list/vmlist if vmalloc_start is
set in
+* vmcoreinfo, in that case proceed without error
+*/
+ if (NUMBER(vmalloc_start) == NOT_FOUND_NUMBER)
+ if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+ || (OFFSET(vm_struct.addr) ==
NOT_FOUND_STRUCTURE)) {
+ ERRMSG("Can't get info for vmalloc
translation.\n");
+ return NOT_PADDR;
+ }
}
return ppc64_vtop_level4(vaddr);
diff --git a/makedumpfile.c b/makedumpfile.c
index b004b93fecb7..b6c63fad15f3 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2978,6 +2978,8 @@ read_vmcoreinfo(void)
READ_NUMBER("PAGE_OFFLINE_MAPCOUNT_VALUE", PAGE_OFFLINE_MAPCOUNT_VALUE);
READ_NUMBER("phys_base", phys_base);
READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+
+ READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
#ifdef __aarch64__
READ_NUMBER("VA_BITS", VA_BITS);
READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
@@ -2989,7 +2991,6 @@ read_vmcoreinfo(void)
READ_NUMBER("VA_BITS", va_bits);
READ_NUMBER_UNSIGNED("phys_ram_base", phys_ram_base);
READ_NUMBER_UNSIGNED("PAGE_OFFSET", page_offset);
- READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
READ_NUMBER_UNSIGNED("VMALLOC_END", vmalloc_end);
READ_NUMBER_UNSIGNED("VMEMMAP_START", vmemmap_start);
READ_NUMBER_UNSIGNED("VMEMMAP_END", vmemmap_end);
diff --git a/makedumpfile.h b/makedumpfile.h
index 59c83e1d9df3..4021c5af2a34 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -541,8 +541,6 @@ do { \
* T
Re: [PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo
Hi Kazu,
On Wed, Feb 28, 2024 at 12:25:04AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2024/02/23 17:39, Aditya Gupta wrote:
> > Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
> > symbol to get the current MMU type on PowerPC64.
> >
> > The disadvantage with this approach was that it depends on bit '0x40'
> > ('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
> > which implies kernel developers have to be careful of modifying
> > MMU_FTR_* defines
> >
> > Instead a more stable approach was suggested by contributors in
> > https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/, to
> > pass information about the MMU type in vmcoreinfo itself, instead of
> > depending on the MMU_FTR_* defines
> >
> > This was implemented in linux kernel in:
> > commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to
> > vmcoreinfo")
> >
> > With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
> > to get current mmu type, instead of 'cur_cpu_spec'.
> > On older kernels, where RADIX_MMU number is not there, makedumpfile will
> > simply fall back to using 'cur_cpu_spec'.
> >
> > The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
> > which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
> > being more clear about the value 0x40 with a comment about
> > MMU_FTR_TYPE_RADIX
> >
> > Signed-off-by: Aditya Gupta
>
> Thanks, applied.
> https://github.com/makedumpfile/makedumpfile/commit/71ac00c8a3464608ac19f7c89d7220073d7374a9
Thank you.
- Aditya Gupta
>
> Kazu
>
> > ---
> > arch/ppc64.c | 15 ++-
> > makedumpfile.c | 1 +
> > makedumpfile.h | 9 ++---
> > 3 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/ppc64.c b/arch/ppc64.c
> > index 96c357cb0335..3b4f91981f71 100644
> > --- a/arch/ppc64.c
> > +++ b/arch/ppc64.c
> > @@ -250,7 +250,7 @@ ppc64_vmalloc_init(void)
> > /*
> > * 64K pagesize
> > */
> > - if (info->cur_mmu_type & RADIX_MMU) {
> > + if (info->cur_mmu_type & MMU_TYPE_RADIX) {
> > info->l1_index_size = PTE_INDEX_SIZE_RADIX_64K;
> > info->l2_index_size = PMD_INDEX_SIZE_RADIX_64K;
> > info->l3_index_size = PUD_INDEX_SIZE_RADIX_64K;
> > @@ -300,7 +300,7 @@ ppc64_vmalloc_init(void)
> > /*
> > * 4K pagesize
> > */
> > - if (info->cur_mmu_type & RADIX_MMU) {
> > + if (info->cur_mmu_type & MMU_TYPE_RADIX) {
> > info->l1_index_size = PTE_INDEX_SIZE_RADIX_4K;
> > info->l2_index_size = PMD_INDEX_SIZE_RADIX_4K;
> > info->l3_index_size = PUD_INDEX_SIZE_RADIX_4K;
> > @@ -635,14 +635,19 @@ get_versiondep_info_ppc64()
> > * On PowerISA 3.0 based server processors, a kernel can run with
> > * radix MMU or standard MMU. Get the current MMU type.
> > */
> > - info->cur_mmu_type = STD_MMU;
> > - if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
> > + info->cur_mmu_type = MMU_TYPE_STD;
> > +
> > + if (NUMBER(RADIX_MMU) != NOT_FOUND_SYMBOL) {
> > + if (NUMBER(RADIX_MMU) == 1) {
> > + info->cur_mmu_type = MMU_TYPE_RADIX;
> > + }
> > + } else if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
> > && (OFFSET(cpu_spec.mmu_features) != NOT_FOUND_STRUCTURE)) {
> > if (readmem(VADDR, SYMBOL(cur_cpu_spec), _cpu_spec,
> > sizeof(cur_cpu_spec))) {
> > if (readmem(VADDR, cur_cpu_spec +
> > OFFSET(cpu_spec.mmu_features),
> > _features, sizeof(mmu_features)))
> > - info->cur_mmu_type = mmu_features & RADIX_MMU;
> > + info->cur_mmu_type = mmu_features &
> > MMU_TYPE_RADIX;
> > }
> > }
> >
> > diff --git a/makedumpfile.c b/makedumpfile.c
> > index 3705bdd93deb..1bd7305f49ca 100644
> > --- a/makedumpfile.c
> > +++ b/makedumpfile.c
> > @@ -2987,6 +2987,7 @@ read_vmcoreinfo(void)
> > #endif
> >
> > READ_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
> > + READ_NUMBER("RADIX_MMU", RADIX_MMU);
> >
> > return TRUE;
> > }
> > diff --git a/makedumpfi
Re: [PATCH] makedumpfile: ppc64: get vmalloc start address from vmcoreinfo
Hi Kazu,
On Wed, Feb 28, 2024 at 04:51:28AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Aditya,
>
> thanks for the patch.
>
> On 2024/02/24 4:03, Aditya Gupta wrote:
> > Below error was noticed when running makedumpfile on linux-next kernel
> > crash (linux-next tag next-20240121):
> >
> > ...
> > Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read
> > non-existent page at 0xc.
> > [ 17.551718] kdump.sh[404]: readmem: type_addr: 0,
> > addr:c00c, size:16384
> > [ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't read
> > the buffer of struct page.
> > [ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude
> > unnecessary pages.
> > [ 17.562632] kdump.sh[404]: The kernel version is not supported.
> > [ 17.562708] kdump.sh[404]: The makedumpfile operation may be
> > incomplete.
> > [ 17.562773] kdump.sh[404]: makedumpfile Failed.
> > [ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
> >
> > Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
> > from the vmcore.
> >
> > 'vmap_area_list' was removed in the linux kernel with below commit:
> >
> > commit 378eb24a0658dd922b29524e0ce35c6c43f56cba
> > mm/vmalloc: remove vmap_area_list
> >
> > Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
> > get base address of vmalloc area, instead of depending on 'vmap_area_list'
> >
> > Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
> >1. Set vmalloc_start based on 'VMALLOC_START'
> >2. Don't error if vmap_area_list/vmlist are not defined
> >
> > Reported-by: Sachin Sant
> > Signed-off-by: Aditya Gupta
> > ---
> > arch/ppc64.c | 19 +--
> > makedumpfile.c | 3 ++-
> > makedumpfile.h | 6 +++---
> > 3 files changed, 18 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/ppc64.c b/arch/ppc64.c
> > index 96c357cb0335..bb62e2cd199a 100644
> > --- a/arch/ppc64.c
> > +++ b/arch/ppc64.c
> > @@ -568,7 +568,9 @@ get_machdep_info_ppc64(void)
> > /*
> > * Get vmalloc_start value from either vmap_area_list or vmlist.
> > */
> > - if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
> > + if (NUMBER(vmalloc_start) != NOT_FOUND_SYMBOL) {
>
> I will fix this NOT_FOUND_SYMBOL to NOT_FOUND_NUMBER when applying,
> otherwise makedumpfile will fail for a dumpfile without the
> corresponding kernel patch, correct?
>
> The patch looks good to me except for it. I will apply this with the
> kernel version in the commit log after the kernel patch gets merged.
Sure, thanks Kazu. I just ran it on an older version, it succeeds
collecting dump on 6.5.0 kernel somehow, though I agree with your
suggestion, it should have been NOT_FOUND_NUMBER. I will be more careful
about these things later.
Thanks,
Aditya Gupta
>
> Thanks,
> Kazu
>
>
> > + vmalloc_start = NUMBER(vmalloc_start);
> > + } else if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
> > && (OFFSET(vmap_area.va_start) != NOT_FOUND_STRUCTURE)
> > && (OFFSET(vmap_area.list) != NOT_FOUND_STRUCTURE)) {
> > if (!readmem(VADDR, SYMBOL(vmap_area_list) +
> > OFFSET(list_head.next),
> > @@ -684,11 +686,16 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
> > if ((SYMBOL(vmap_area_list) == NOT_FOUND_SYMBOL)
> > || (OFFSET(vmap_area.va_start) == NOT_FOUND_STRUCTURE)
> > || (OFFSET(vmap_area.list) == NOT_FOUND_STRUCTURE)) {
> > - if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
> > - || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
> > - ERRMSG("Can't get info for vmalloc translation.\n");
> > - return NOT_PADDR;
> > - }
> > + /*
> > +* Don't depend on vmap_area_list/vmlist if vmalloc_start is
> > set in
> > +* vmcoreinfo, in that case proceed without error
> > +*/
> > + if (NUMBER(vmalloc_start) == NOT_FOUND_NUMBER)
> > + if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
> > + || (OFFSET(vm_struct.addr) ==
> > NOT_FOUND_STRUCTURE)) {
> > + ERRMSG("Can't get info for vmalloc
> > translation.\n");
> > + return NOT_PADDR;
> > + }
> > }
> >
> > return ppc64_vtop_level4(vaddr);
> &
[PATCH] makedumpfile: ppc64: get vmalloc start address from vmcoreinfo
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
...
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read
non-existent page at 0xc.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0, addr:c00c,
size:16384
[ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't read the
buffer of struct page.
[ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude unnecessary
pages.
[ 17.562632] kdump.sh[404]: The kernel version is not supported.
[ 17.562708] kdump.sh[404]: The makedumpfile operation may be incomplete.
[ 17.562773] kdump.sh[404]: makedumpfile Failed.
[ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
from the vmcore.
'vmap_area_list' was removed in the linux kernel with below commit:
commit 378eb24a0658dd922b29524e0ce35c6c43f56cba
mm/vmalloc: remove vmap_area_list
Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
get base address of vmalloc area, instead of depending on 'vmap_area_list'
Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
1. Set vmalloc_start based on 'VMALLOC_START'
2. Don't error if vmap_area_list/vmlist are not defined
Reported-by: Sachin Sant
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 19 +--
makedumpfile.c | 3 ++-
makedumpfile.h | 6 +++---
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..bb62e2cd199a 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -568,7 +568,9 @@ get_machdep_info_ppc64(void)
/*
* Get vmalloc_start value from either vmap_area_list or vmlist.
*/
- if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
+ if (NUMBER(vmalloc_start) != NOT_FOUND_SYMBOL) {
+ vmalloc_start = NUMBER(vmalloc_start);
+ } else if ((SYMBOL(vmap_area_list) != NOT_FOUND_SYMBOL)
&& (OFFSET(vmap_area.va_start) != NOT_FOUND_STRUCTURE)
&& (OFFSET(vmap_area.list) != NOT_FOUND_STRUCTURE)) {
if (!readmem(VADDR, SYMBOL(vmap_area_list) +
OFFSET(list_head.next),
@@ -684,11 +686,16 @@ vaddr_to_paddr_ppc64(unsigned long vaddr)
if ((SYMBOL(vmap_area_list) == NOT_FOUND_SYMBOL)
|| (OFFSET(vmap_area.va_start) == NOT_FOUND_STRUCTURE)
|| (OFFSET(vmap_area.list) == NOT_FOUND_STRUCTURE)) {
- if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
- || (OFFSET(vm_struct.addr) == NOT_FOUND_STRUCTURE)) {
- ERRMSG("Can't get info for vmalloc translation.\n");
- return NOT_PADDR;
- }
+ /*
+* Don't depend on vmap_area_list/vmlist if vmalloc_start is
set in
+* vmcoreinfo, in that case proceed without error
+*/
+ if (NUMBER(vmalloc_start) == NOT_FOUND_NUMBER)
+ if ((SYMBOL(vmlist) == NOT_FOUND_SYMBOL)
+ || (OFFSET(vm_struct.addr) ==
NOT_FOUND_STRUCTURE)) {
+ ERRMSG("Can't get info for vmalloc
translation.\n");
+ return NOT_PADDR;
+ }
}
return ppc64_vtop_level4(vaddr);
diff --git a/makedumpfile.c b/makedumpfile.c
index b004b93fecb7..b6c63fad15f3 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2978,6 +2978,8 @@ read_vmcoreinfo(void)
READ_NUMBER("PAGE_OFFLINE_MAPCOUNT_VALUE", PAGE_OFFLINE_MAPCOUNT_VALUE);
READ_NUMBER("phys_base", phys_base);
READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+
+ READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
#ifdef __aarch64__
READ_NUMBER("VA_BITS", VA_BITS);
READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
@@ -2989,7 +2991,6 @@ read_vmcoreinfo(void)
READ_NUMBER("VA_BITS", va_bits);
READ_NUMBER_UNSIGNED("phys_ram_base", phys_ram_base);
READ_NUMBER_UNSIGNED("PAGE_OFFSET", page_offset);
- READ_NUMBER_UNSIGNED("VMALLOC_START", vmalloc_start);
READ_NUMBER_UNSIGNED("VMALLOC_END", vmalloc_end);
READ_NUMBER_UNSIGNED("VMEMMAP_START", vmemmap_start);
READ_NUMBER_UNSIGNED("VMEMMAP_END", vmemmap_end);
diff --git a/makedumpfile.h b/makedumpfile.h
index 59c83e1d9df3..4021c5af2a34 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -541,8 +541,6 @@ do { \
* The value of dependence on machine
*/
#define PAGE_OFFSET(info->page_offset)
-#define VMALLOC_START (info->vmalloc_start)
-#define VMALLOC_END(info->vmalloc_end)
#define VMEMMAP_START (info->vmemmap_start)
#define VMEMMAP_END(
[PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be careful of modifying
MMU_FTR_* defines
Instead a more stable approach was suggested by contributors in
https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/, to
pass information about the MMU type in vmcoreinfo itself, instead of
depending on the MMU_FTR_* defines
This was implemented in linux kernel in:
commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to vmcoreinfo")
With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
to get current mmu type, instead of 'cur_cpu_spec'.
On older kernels, where RADIX_MMU number is not there, makedumpfile will
simply fall back to using 'cur_cpu_spec'.
The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
being more clear about the value 0x40 with a comment about MMU_FTR_TYPE_RADIX
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 15 ++-
makedumpfile.c | 1 +
makedumpfile.h | 9 ++---
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..3b4f91981f71 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -250,7 +250,7 @@ ppc64_vmalloc_init(void)
/*
* 64K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_64K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_64K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_64K;
@@ -300,7 +300,7 @@ ppc64_vmalloc_init(void)
/*
* 4K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_4K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_4K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_4K;
@@ -635,14 +635,19 @@ get_versiondep_info_ppc64()
* On PowerISA 3.0 based server processors, a kernel can run with
* radix MMU or standard MMU. Get the current MMU type.
*/
- info->cur_mmu_type = STD_MMU;
- if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
+ info->cur_mmu_type = MMU_TYPE_STD;
+
+ if (NUMBER(RADIX_MMU) != NOT_FOUND_SYMBOL) {
+ if (NUMBER(RADIX_MMU) == 1) {
+ info->cur_mmu_type = MMU_TYPE_RADIX;
+ }
+ } else if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
&& (OFFSET(cpu_spec.mmu_features) != NOT_FOUND_STRUCTURE)) {
if (readmem(VADDR, SYMBOL(cur_cpu_spec), _cpu_spec,
sizeof(cur_cpu_spec))) {
if (readmem(VADDR, cur_cpu_spec +
OFFSET(cpu_spec.mmu_features),
_features, sizeof(mmu_features)))
- info->cur_mmu_type = mmu_features & RADIX_MMU;
+ info->cur_mmu_type = mmu_features &
MMU_TYPE_RADIX;
}
}
diff --git a/makedumpfile.c b/makedumpfile.c
index 3705bdd93deb..1bd7305f49ca 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2987,6 +2987,7 @@ read_vmcoreinfo(void)
#endif
READ_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
+ READ_NUMBER("RADIX_MMU", RADIX_MMU);
return TRUE;
}
diff --git a/makedumpfile.h b/makedumpfile.h
index 3ed3ba551d96..a7b344974636 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -747,12 +747,13 @@ unsigned long get_kvbase_arm64(void);
/*
* Supported MMU types
*/
-#define STD_MMU 0x0
+#define MMU_TYPE_STD 0x0
/*
* The flag bit for radix MMU in cpu_spec.mmu_features
- * in the kernel. Use the same flag here.
+ * in the kernel (MMU_FTR_TYPE_RADIX).
+ * Use the same flag here.
*/
-#define RADIX_MMU 0x40
+#define MMU_TYPE_RADIX 0x40
#define PGD_MASK_L4\
@@ -2258,6 +2259,8 @@ struct number_table {
unsigned long kernel_link_addr;
unsigned long va_kernel_pa_offset;
#endif
+
+ unsigned long RADIX_MMU;
};
struct srcfile_table {
--
2.43.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo
On Fri, Feb 23, 2024 at 03:54:12PM +0800, Baoquan He wrote:
> Add maintainer Kazu to CC.
Thanks, I missed him, will resend this patch with him in CC.
Thanks,
Aditya Gupta
>
> On 02/23/24 at 11:23am, Aditya Gupta wrote:
> > Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
> > symbol to get the current MMU type on PowerPC64.
> >
> > The disadvantage with this approach was that it depends on bit '0x40'
> > ('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
> > which implies kernel developers have to be careful of modifying
> > MMU_FTR_* defines
> >
> > Instead a more stable approach was suggested by contributors in
> > https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/, to
> > pass information about the MMU type in vmcoreinfo itself, instead of
> > depending on the MMU_FTR_* defines
> >
> > This was implemented in linux kernel in:
> > commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to
> > vmcoreinfo")
> >
> > With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
> > to get current mmu type, instead of 'cur_cpu_spec'.
> > On older kernels, where RADIX_MMU number is not there, makedumpfile will
> > simply fall back to using 'cur_cpu_spec'.
> >
> > The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
> > which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
> > being more clear about the value 0x40 with a comment about
> > MMU_FTR_TYPE_RADIX
> >
> > Signed-off-by: Aditya Gupta
> > ---
> > arch/ppc64.c | 15 ++-
> > makedumpfile.c | 1 +
> > makedumpfile.h | 9 ++---
> > 3 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/ppc64.c b/arch/ppc64.c
> > index 96c357cb0335..3b4f91981f71 100644
> > --- a/arch/ppc64.c
> > +++ b/arch/ppc64.c
> > @@ -250,7 +250,7 @@ ppc64_vmalloc_init(void)
> > /*
> > * 64K pagesize
> > */
> > - if (info->cur_mmu_type & RADIX_MMU) {
> > + if (info->cur_mmu_type & MMU_TYPE_RADIX) {
> > info->l1_index_size = PTE_INDEX_SIZE_RADIX_64K;
> > info->l2_index_size = PMD_INDEX_SIZE_RADIX_64K;
> > info->l3_index_size = PUD_INDEX_SIZE_RADIX_64K;
> > @@ -300,7 +300,7 @@ ppc64_vmalloc_init(void)
> > /*
> > * 4K pagesize
> > */
> > - if (info->cur_mmu_type & RADIX_MMU) {
> > + if (info->cur_mmu_type & MMU_TYPE_RADIX) {
> > info->l1_index_size = PTE_INDEX_SIZE_RADIX_4K;
> > info->l2_index_size = PMD_INDEX_SIZE_RADIX_4K;
> > info->l3_index_size = PUD_INDEX_SIZE_RADIX_4K;
> > @@ -635,14 +635,19 @@ get_versiondep_info_ppc64()
> > * On PowerISA 3.0 based server processors, a kernel can run with
> > * radix MMU or standard MMU. Get the current MMU type.
> > */
> > - info->cur_mmu_type = STD_MMU;
> > - if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
> > + info->cur_mmu_type = MMU_TYPE_STD;
> > +
> > + if (NUMBER(RADIX_MMU) != NOT_FOUND_SYMBOL) {
> > + if (NUMBER(RADIX_MMU) == 1) {
> > + info->cur_mmu_type = MMU_TYPE_RADIX;
> > + }
> > + } else if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
> > && (OFFSET(cpu_spec.mmu_features) != NOT_FOUND_STRUCTURE)) {
> > if (readmem(VADDR, SYMBOL(cur_cpu_spec), _cpu_spec,
> > sizeof(cur_cpu_spec))) {
> > if (readmem(VADDR, cur_cpu_spec +
> > OFFSET(cpu_spec.mmu_features),
> > _features, sizeof(mmu_features)))
> > - info->cur_mmu_type = mmu_features & RADIX_MMU;
> > + info->cur_mmu_type = mmu_features &
> > MMU_TYPE_RADIX;
> > }
> > }
> >
> > diff --git a/makedumpfile.c b/makedumpfile.c
> > index 3705bdd93deb..1bd7305f49ca 100644
> > --- a/makedumpfile.c
> > +++ b/makedumpfile.c
> > @@ -2987,6 +2987,7 @@ read_vmcoreinfo(void)
> > #endif
> >
> > READ_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
> > + READ_NUMBER("RADIX_MMU", RADIX_MMU);
> >
> > return TRUE;
> > }
> > diff --git a/makedumpfile.h b/makedumpfile.h
> > index 3ed3ba551d96..a7b344974636 100644
> >
[PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be careful of modifying
MMU_FTR_* defines
Instead a more stable approach was suggested by contributors in
https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/, to
pass information about the MMU type in vmcoreinfo itself, instead of
depending on the MMU_FTR_* defines
This was implemented in linux kernel in:
commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to vmcoreinfo")
With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
to get current mmu type, instead of 'cur_cpu_spec'.
On older kernels, where RADIX_MMU number is not there, makedumpfile will
simply fall back to using 'cur_cpu_spec'.
The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
being more clear about the value 0x40 with a comment about MMU_FTR_TYPE_RADIX
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 15 ++-
makedumpfile.c | 1 +
makedumpfile.h | 9 ++---
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..3b4f91981f71 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -250,7 +250,7 @@ ppc64_vmalloc_init(void)
/*
* 64K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_64K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_64K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_64K;
@@ -300,7 +300,7 @@ ppc64_vmalloc_init(void)
/*
* 4K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_4K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_4K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_4K;
@@ -635,14 +635,19 @@ get_versiondep_info_ppc64()
* On PowerISA 3.0 based server processors, a kernel can run with
* radix MMU or standard MMU. Get the current MMU type.
*/
- info->cur_mmu_type = STD_MMU;
- if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
+ info->cur_mmu_type = MMU_TYPE_STD;
+
+ if (NUMBER(RADIX_MMU) != NOT_FOUND_SYMBOL) {
+ if (NUMBER(RADIX_MMU) == 1) {
+ info->cur_mmu_type = MMU_TYPE_RADIX;
+ }
+ } else if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
&& (OFFSET(cpu_spec.mmu_features) != NOT_FOUND_STRUCTURE)) {
if (readmem(VADDR, SYMBOL(cur_cpu_spec), _cpu_spec,
sizeof(cur_cpu_spec))) {
if (readmem(VADDR, cur_cpu_spec +
OFFSET(cpu_spec.mmu_features),
_features, sizeof(mmu_features)))
- info->cur_mmu_type = mmu_features & RADIX_MMU;
+ info->cur_mmu_type = mmu_features &
MMU_TYPE_RADIX;
}
}
diff --git a/makedumpfile.c b/makedumpfile.c
index 3705bdd93deb..1bd7305f49ca 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2987,6 +2987,7 @@ read_vmcoreinfo(void)
#endif
READ_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
+ READ_NUMBER("RADIX_MMU", RADIX_MMU);
return TRUE;
}
diff --git a/makedumpfile.h b/makedumpfile.h
index 3ed3ba551d96..a7b344974636 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -747,12 +747,13 @@ unsigned long get_kvbase_arm64(void);
/*
* Supported MMU types
*/
-#define STD_MMU 0x0
+#define MMU_TYPE_STD 0x0
/*
* The flag bit for radix MMU in cpu_spec.mmu_features
- * in the kernel. Use the same flag here.
+ * in the kernel (MMU_FTR_TYPE_RADIX).
+ * Use the same flag here.
*/
-#define RADIX_MMU 0x40
+#define MMU_TYPE_RADIX 0x40
#define PGD_MASK_L4\
@@ -2258,6 +2259,8 @@ struct number_table {
unsigned long kernel_link_addr;
unsigned long va_kernel_pa_offset;
#endif
+
+ unsigned long RADIX_MMU;
};
struct srcfile_table {
--
2.43.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] kexec: ppc64: print help to stdout instead of stderr
Currently 'kexec --help' on powerpc64 prints the generic help/usage to
stdout, and the powerpc64 specific options to stderr
That is, if the stdout of 'kexec --help' is redirected to some file,
some of the help options will not be redirected, and instead printed on
the terminal/stderr:
[root@machine kexec-tools]# kexec --help > /tmp/out
--command-line= command line to append.
--append= same as --command-line.
--ramdisk= Initial RAM disk.
--initrd= same as --ramdisk.
--devicetreeblob= Specify device tree blob file.
Not applicable while using
--kexec-file-syscall.
--dtb= same as --devicetreeblob.
elf support is still broken
--elf64-core-headers Prepare core headers in ELF64 format
--dt-no-old-root Do not reuse old kernel root= param.
while creating flatten device tree.
Fix this inconsistency by writing powerpc64 specific options to stdout,
similar to the generic 'kexec --help'
With the proposed changes, it is like this (nothing printed to stderr):
[root@machine kexec-tools]# ./build/sbin/kexec --help > /tmp/out
Reported-by: Srikar Dronamraju
Signed-off-by: Aditya Gupta
---
kexec/arch/ppc64/kexec-elf-ppc64.c| 22 +++---
kexec/arch/ppc64/kexec-ppc64.c| 6 +++---
kexec/arch/ppc64/kexec-zImage-ppc64.c | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c
b/kexec/arch/ppc64/kexec-elf-ppc64.c
index 01d045f..bdcfd20 100644
--- a/kexec/arch/ppc64/kexec-elf-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
@@ -482,15 +482,15 @@ int elf_ppc64_load(int argc, char **argv, const char
*buf, off_t len,
void elf_ppc64_usage(void)
{
- fprintf(stderr, " --command-line= command line to
append.\n");
- fprintf(stderr, " --append= same as
--command-line.\n");
- fprintf(stderr, " --ramdisk= Initial RAM disk.\n");
- fprintf(stderr, " --initrd= same as --ramdisk.\n");
- fprintf(stderr, " --devicetreeblob= Specify device tree
blob file.\n");
- fprintf(stderr, " ");
- fprintf(stderr, "Not applicable while using --kexec-file-syscall.\n");
- fprintf(stderr, " --reuse-cmdline Use kernel command line from
running system.\n");
- fprintf(stderr, " --dtb= same as --devicetreeblob.\n");
-
- fprintf(stderr, "elf support is still broken\n");
+ printf(" --command-line= command line to append.\n");
+ printf(" --append= same as --command-line.\n");
+ printf(" --ramdisk= Initial RAM disk.\n");
+ printf(" --initrd= same as --ramdisk.\n");
+ printf(" --devicetreeblob= Specify device tree blob
file.\n");
+ printf(" ");
+ printf("Not applicable while using --kexec-file-syscall.\n");
+ printf(" --reuse-cmdline Use kernel command line from running
system.\n");
+ printf(" --dtb= same as --devicetreeblob.\n");
+
+ printf("elf support is still broken\n");
}
diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
index 611809f..19f17cb 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -910,9 +910,9 @@ int file_types = sizeof(file_type) / sizeof(file_type[0]);
void arch_usage(void)
{
- fprintf(stderr, " --elf64-core-headers Prepare core headers in
ELF64 format\n");
- fprintf(stderr, " --dt-no-old-root Do not reuse old kernel root=
param.\n" \
- " while creating flatten device
tree.\n");
+ printf(" --elf64-core-headers Prepare core headers in ELF64
format\n");
+ printf(" --dt-no-old-root Do not reuse old kernel root= param.\n"
+ " while creating flatten device tree.\n");
}
struct arch_options_t arch_options = {
diff --git a/kexec/arch/ppc64/kexec-zImage-ppc64.c
b/kexec/arch/ppc64/kexec-zImage-ppc64.c
index e946205..7f45751 100644
--- a/kexec/arch/ppc64/kexec-zImage-ppc64.c
+++ b/kexec/arch/ppc64/kexec-zImage-ppc64.c
@@ -180,5 +180,5 @@ int zImage_ppc64_load(FILE *file, int UNUSED(argc), char
**UNUSED(argv),
void zImage_ppc64_usage(void)
{
- fprintf(stderr, "zImage support is still broken\n");
+ printf("zImage support is still broken\n");
}
--
2.39.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] makedumpfile: ppc64: do page traversal if vmemmap_list not populated
On Wed, Sep 27, 2023 at 06:32:44AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/09/14 18:22, Aditya Gupta wrote:
> > Currently 'makedumpfile' fails to collect vmcore on upstream kernel,
> > with the errors:
> >
> > readpage_elf: Attempt to read non-existent page at 0x4000.
> > readmem: type_addr: 0, addr:0, size:8
> > get_vmemmap_list_info: Can't get vmemmap region addresses
> > get_machdep_info_ppc64: Can't get vmemmap list info.
> >
> > This occurs since makedumpfile depends on 'vmemmap_list' for translating
> > vmemmap addresses. But with below commit in Linux, vmemmap_list can be
> > empty, in case of Radix MMU on PowerPC64
> >
> > 368a0590d954: (powerpc/book3s64/vmemmap: switch radix to use a
> > different vmemmap handling function)
> >
> > In case vmemmap_list is empty, then it's head is NULL, which causes
> > makedumpfile to fail with above error.
> >
> > Since with above commit, 'vmemmap_list' is not populated (when MMU is
> > Radix MMU), kernel populates corresponding page table entries in kernel
> > page table. Hence, instead of depending on 'vmemmap_list' for address
> > translation for vmemmap addresses, do a kernel pagetable walk.
> >
> > And since the pte can also be introduced at higher levels in the page
> > table, such as at PMD level, add hugepage support, by checking for
> > PAGE_PTE flag
> >
> > Reported-by: Sachin Sant
> > Signed-off-by: Aditya Gupta
>
> Thank you for the patch, applied.
>
> https://github.com/makedumpfile/makedumpfile/commit/a34f017965583e89c4cb0b00117c200a6c191e54
Thanks for the update.
>
> Sorry for the delay, exceptionally busy this month..
No issues :)
Thanks,
- Aditya Gupta
>
> Thanks,
> Kazu
>
> > ---
> > arch/ppc64.c | 111 ++---
> > makedumpfile.h | 6 +++
> > 2 files changed, 84 insertions(+), 33 deletions(-)
> >
> > diff --git a/arch/ppc64.c b/arch/ppc64.c
> > index 5e70acb51aba..9456b8b570c5 100644
> > --- a/arch/ppc64.c
> > +++ b/arch/ppc64.c
> > @@ -196,6 +196,10 @@ ppc64_vmemmap_init(void)
> > int psize, shift;
> > ulong head;
> >
> > + /* initialise vmemmap_list in case SYMBOL(vmemmap_list) is not found */
> > + info->vmemmap_list = NULL;
> > + info->vmemmap_cnt = 0;
> > +
> > if ((SYMBOL(vmemmap_list) == NOT_FOUND_SYMBOL)
> > || (SYMBOL(mmu_psize_defs) == NOT_FOUND_SYMBOL)
> > || (SYMBOL(mmu_vmemmap_psize) == NOT_FOUND_SYMBOL)
> > @@ -216,15 +220,24 @@ ppc64_vmemmap_init(void)
> > return FALSE;
> > info->vmemmap_psize = 1 << shift;
> >
> > - if (!readmem(VADDR, SYMBOL(vmemmap_list), , sizeof(unsigned long)))
> > - return FALSE;
> > -
> > /*
> > -* Get vmemmap list count and populate vmemmap regions info
> > -*/
> > - info->vmemmap_cnt = get_vmemmap_list_info(head);
> > - if (info->vmemmap_cnt == 0)
> > - return FALSE;
> > +* vmemmap_list symbol can be missing or set to 0 in the kernel.
> > +* This would imply vmemmap region is mapped in the kernel pagetable.
> > +*
> > +* So, read vmemmap_list anyway, and use 'vmemmap_list' if it's not
> > empty
> > +* (head != NULL), or we will do a kernel pagetable walk for vmemmap
> > address
> > +* translation later
> > +**/
> > + readmem(VADDR, SYMBOL(vmemmap_list), , sizeof(unsigned long));
> > +
> > + if (head) {
> > + /*
> > +* Get vmemmap list count and populate vmemmap regions info
> > +*/
> > + info->vmemmap_cnt = get_vmemmap_list_info(head);
> > + if (info->vmemmap_cnt == 0)
> > + return FALSE;
> > + }
> >
> > info->flag_vmemmap = TRUE;
> > return TRUE;
> > @@ -347,29 +360,6 @@ ppc64_vmalloc_init(void)
> > return TRUE;
> > }
> >
> > -/*
> > - * If the vmemmap address translation information is stored in the kernel,
> > - * make the translation.
> > - */
> > -static unsigned long long
> > -ppc64_vmemmap_to_phys(unsigned long vaddr)
> > -{
> > - int i;
> > - ulong offset;
> > - unsigned long long paddr = NOT_PADDR;
> > -
> > - for (i = 0; i < info->vmemmap_cnt; i++) {
> > - if ((vaddr >= info->vmemmap_list[i].virt) && (vaddr <
> > - (info->vmemma
Re: [PATCH] makedumpfile: ppc64: do page traversal if vmemmap_list not populated
To be able to test this on a system with Radix MMU, the kernel needs to be patched with given kernel patch, since makedumpfile requires 'cpu_features.mmu_features' to check if MMU was Radix MMU: https://lore.kernel.org/linuxppc-dev/20230911091409.415662-1-adit...@linux.ibm.com/T/#u Or, the vmlinux can be provided to makedumpfile, so that it finds the 'cur_cpu_spec.mmu_features' symbol, run makedumpfile with '-x' flag similar to this: makedumpfile -l -d 31 -x VMLINUX /proc/vmcore /var/crash/vmcore.kdump Thanks, Aditya Gupta ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] makedumpfile: ppc64: do page traversal if vmemmap_list not populated
Currently 'makedumpfile' fails to collect vmcore on upstream kernel,
with the errors:
readpage_elf: Attempt to read non-existent page at 0x4000.
readmem: type_addr: 0, addr:0, size:8
get_vmemmap_list_info: Can't get vmemmap region addresses
get_machdep_info_ppc64: Can't get vmemmap list info.
This occurs since makedumpfile depends on 'vmemmap_list' for translating
vmemmap addresses. But with below commit in Linux, vmemmap_list can be
empty, in case of Radix MMU on PowerPC64
368a0590d954: (powerpc/book3s64/vmemmap: switch radix to use a
different vmemmap handling function)
In case vmemmap_list is empty, then it's head is NULL, which causes
makedumpfile to fail with above error.
Since with above commit, 'vmemmap_list' is not populated (when MMU is
Radix MMU), kernel populates corresponding page table entries in kernel
page table. Hence, instead of depending on 'vmemmap_list' for address
translation for vmemmap addresses, do a kernel pagetable walk.
And since the pte can also be introduced at higher levels in the page
table, such as at PMD level, add hugepage support, by checking for
PAGE_PTE flag
Reported-by: Sachin Sant
Signed-off-by: Aditya Gupta
---
arch/ppc64.c | 111 ++---
makedumpfile.h | 6 +++
2 files changed, 84 insertions(+), 33 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 5e70acb51aba..9456b8b570c5 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -196,6 +196,10 @@ ppc64_vmemmap_init(void)
int psize, shift;
ulong head;
+ /* initialise vmemmap_list in case SYMBOL(vmemmap_list) is not found */
+ info->vmemmap_list = NULL;
+ info->vmemmap_cnt = 0;
+
if ((SYMBOL(vmemmap_list) == NOT_FOUND_SYMBOL)
|| (SYMBOL(mmu_psize_defs) == NOT_FOUND_SYMBOL)
|| (SYMBOL(mmu_vmemmap_psize) == NOT_FOUND_SYMBOL)
@@ -216,15 +220,24 @@ ppc64_vmemmap_init(void)
return FALSE;
info->vmemmap_psize = 1 << shift;
- if (!readmem(VADDR, SYMBOL(vmemmap_list), , sizeof(unsigned long)))
- return FALSE;
-
/*
-* Get vmemmap list count and populate vmemmap regions info
-*/
- info->vmemmap_cnt = get_vmemmap_list_info(head);
- if (info->vmemmap_cnt == 0)
- return FALSE;
+* vmemmap_list symbol can be missing or set to 0 in the kernel.
+* This would imply vmemmap region is mapped in the kernel pagetable.
+*
+* So, read vmemmap_list anyway, and use 'vmemmap_list' if it's not
empty
+* (head != NULL), or we will do a kernel pagetable walk for vmemmap
address
+* translation later
+**/
+ readmem(VADDR, SYMBOL(vmemmap_list), , sizeof(unsigned long));
+
+ if (head) {
+ /*
+* Get vmemmap list count and populate vmemmap regions info
+*/
+ info->vmemmap_cnt = get_vmemmap_list_info(head);
+ if (info->vmemmap_cnt == 0)
+ return FALSE;
+ }
info->flag_vmemmap = TRUE;
return TRUE;
@@ -347,29 +360,6 @@ ppc64_vmalloc_init(void)
return TRUE;
}
-/*
- * If the vmemmap address translation information is stored in the kernel,
- * make the translation.
- */
-static unsigned long long
-ppc64_vmemmap_to_phys(unsigned long vaddr)
-{
- int i;
- ulong offset;
- unsigned long long paddr = NOT_PADDR;
-
- for (i = 0; i < info->vmemmap_cnt; i++) {
- if ((vaddr >= info->vmemmap_list[i].virt) && (vaddr <
- (info->vmemmap_list[i].virt + info->vmemmap_psize))) {
- offset = vaddr - info->vmemmap_list[i].virt;
- paddr = info->vmemmap_list[i].phys + offset;
- break;
- }
- }
-
- return paddr;
-}
-
static unsigned long long
ppc64_vtop_level4(unsigned long vaddr)
{
@@ -379,6 +369,8 @@ ppc64_vtop_level4(unsigned long vaddr)
unsigned long long pgd_pte, pud_pte;
unsigned long long pmd_pte, pte;
unsigned long long paddr = NOT_PADDR;
+ uint is_hugepage = 0;
+ uint pdshift;
uint swap = 0;
if (info->page_buf == NULL) {
@@ -413,6 +405,13 @@ ppc64_vtop_level4(unsigned long vaddr)
if (!pgd_pte)
return NOT_PADDR;
+ if (IS_HUGEPAGE(pgd_pte)) {
+ is_hugepage = 1;
+ pte = pgd_pte;
+ pdshift = info->l4_shift;
+ goto out;
+ }
+
/*
* Sometimes we don't have level3 pagetable entries
*/
@@ -426,6 +425,13 @@ ppc64_vtop_level4(unsigned long vaddr)
pud_pte = swap64(ULONG((info->page_buf +
PAGEOFFSET(page_upper))), swap);
if (!pud_pte)
return NOT_PADDR;
+
+
