Re: [PATCH v5] powerpc/kdump: Add support for crashkernel CMA reservation
From: Sourabh Jain <hidden>
Date: 2025-11-04 12:38:42
Also in:
kexec
On 04/11/25 15:54, Ritesh Harjani (IBM) wrote:
Sourabh Jain [off-list ref] writes:quoted
On 04/11/25 10:48, Sourabh Jain wrote:quoted
On 03/11/25 15:40, Ritesh Harjani (IBM) wrote:quoted
Sourabh Jain [off-list ref] writes:quoted
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel= command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. Extend crashkernel CMA reservation support to powerpc. The following changes are made to enable CMA reservation on powerpc: - Parse and obtain the CMA reservation size along with other crashkernel parameters - Call reserve_crashkernel_cma() to allocate the CMA region for kdump - Include the CMA-reserved ranges in the usable memory ranges for the kdump kernel to use. - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore. With the introduction of the CMA crashkernel regions, crash_exclude_mem_range() needs to be called multiple times to exclude both crashk_res and crashk_cma_ranges from the crash memory ranges. To avoid repetitive logic for validating mem_ranges size and handling reallocation when required, this functionality is moved to a new wrapper function crash_exclude_mem_range_guarded(). To ensure proper CMA reservation, reserve_crashkernel_cma() is called after pageblock_order is initialized. Update kernel-parameters.txt to document CMA support for crashkernel on powerpc architecture. Cc: Baoquan he <redacted> Cc: Jiri Bohac <redacted> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Shivang Upadhyay <redacted> Cc: kexec@lists.infradead.org Signed-off-by: Sourabh Jain <redacted> --- Changlog: v3 -> v4 - Removed repeated initialization to tmem in crash_exclude_mem_range_guarded() - Call crash_exclude_mem_range() with right crashk ranges v4 -> v5: - Document CMA-based crashkernel support for ppc64 in kernel-parameters.txt --- .../admin-guide/kernel-parameters.txt | 2 +- arch/powerpc/include/asm/kexec.h | 2 + arch/powerpc/kernel/setup-common.c | 4 +- arch/powerpc/kexec/core.c | 10 ++++- arch/powerpc/kexec/ranges.c | 43 ++++++++++++++----- 5 files changed, 47 insertions(+), 14 deletions(-)diff --git a/Documentation/admin-guide/kernel-parameters.txtb/Documentation/admin-guide/kernel-parameters.txt index 6c42061ca20e..0f386b546cec 100644--- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt@@ -1013,7 +1013,7 @@ It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. crashkernel=size[KMG],cma - [KNL, X86] Reserve additional crash kernel memory from + [KNL, X86, ppc64] Reserve additional crash kernelmemory fromShouldn't this be PPC and not ppc64? If I see the crash_dump support... config ARCH_SUPPORTS_CRASH_DUMP def_bool PPC64 || PPC_BOOK3S_32 || PPC_85xx || (44x && !SMP) The changes below aren't specific to ppc64 correct?The thing is this feature is only supported with KEXEC_FILE and which only supported on PPC64: config ARCH_SUPPORTS_KEXEC_FILE def_bool PPC64 Hence I kept it as ppc64.I am not much familiar with the kexec_load v/s kexec_file_load internals. Maybe because of that I am unable to clearly understand your above points. But let me try and explain what I think you meant :) We first call "get_usable_memory_ranges(&umem)" which updates the usable memory ranges in "umem". We then call "update_usable_mem_fdt(fdt, umem)" which updates the FDT for the kdump kernel's fdt to inform about these usable memory ranges to the kdump kernel. Now since your patch only does that in get_usable_memory_range(), this extra CMA reservation is mainly only useful when the kdump load happens via kexec_file_load(), (because get_usable_memory_range() only gets called from kexec_file_load() path) Is this what you meant here?
Yeah, for kexec_file_load, the FDT for the kdump kernel is prepared in the Linux kernel (using the functions you mentioned), whereas for kexec_load, it is prepared in the kexec tool (userspace). Hence, these changes are not sufficient to support this feature with the kexec_load syscall. The kexec tool must be updated to ensure that the FDT is prepared in a way that marks the crashkernel CMA reservation as usable in the kdump FDT for the kexec_load system call. Anyway, it makes more sense to say that crashkernel=xM,cma support is available on ppc rather than ppc64, since restricting crashkernel CMA reservation to KEXEC_FILE does not help. The details are explained below.
quoted
quoted
I think I should update that in the commit message. Also do you think is it good to restrict this feature to KEXEC_FILE?Putting this under KEXEC_FILE may not help much because KEXEC_FILE is enabled by default in most configurations. Once it is enabled, the CMA reservation will happen regardless of which system call is used to load the kdump kernel (kexec_load or kexec_file_load).What I understood from the feature was that, on the normal production kernel this feature crashkernel=xM,cma allows to reserve an extra xMB of memory as a CMA region for kdump kernel's memory allocations. But this CMA reservation would happen in the normal kernel itself during setup_arch() -> kdump_cma_reserve().. And this CMA reservation happens irrespective of whether the kdump kernel will get loaded via whichever system call.
Yeah that's right.
quoted
However, not restricting this feature to KEXEC_FILE will allow the kexec tool to independently add support for this feature in the future for the kexec_load system call.Sure.quoted
With that logic, I think if we do not restrict this feature to KEXEC_FILE, the support will be available for ppc and not limited to ppc64.Yes, that make sense. If one doesn't want to make the CMA reservation, then we need not pass the extra cmdline argument and no reservation will be made. So, no need to restrict this to PPC64 by making it available only for KEXEC_FILE.
Agree.