On 04/11/25 15:54, Ritesh Harjani (IBM) wrote:
Sourabh Jain <[email protected]> writes:
On 04/11/25 10:48, Sourabh Jain wrote:
On 03/11/25 15:40, Ritesh Harjani (IBM) wrote:
Sourabh Jain <[email protected]> writes:
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 <[email protected]>
Cc: Jiri Bohac <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Madhavan Srinivasan <[email protected]>
Cc: Mahesh Salgaonkar <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Ritesh Harjani (IBM) <[email protected]>
Cc: Shivang Upadhyay <[email protected]>
Cc: [email protected]
Signed-off-by: Sourabh Jain <[email protected]>
---
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.txt
b/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 kernel
memory from
Shouldn'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.
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.
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.
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.
