[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7deQKy1F8BW1ibi@dwarf.suse.cz>
Date: Thu, 20 Feb 2025 17:54:24 +0100
From: Jiri Bohac <jbohac@...e.cz>
To: Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org
Cc: Philipp Rudo <prudo@...hat.com>, Donald Dutile <ddutile@...hat.com>,
Pingfan Liu <piliu@...hat.com>, Tao Liu <ltao@...hat.com>,
linux-kernel@...r.kernel.org,
David Hildenbrand <dhildenb@...hat.com>,
Michal Hocko <mhocko@...e.cz>
Subject: [PATCH v2 3/5] kdump, documentation: describe craskernel CMA
reservation
Describe the new crashkernel ",cma" suffix in Documentation/
---
Documentation/admin-guide/kdump/kdump.rst | 19 +++++++++++++++++--
.../admin-guide/kernel-parameters.txt | 14 ++++++++++++++
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index 5376890adbeb..3f7ff301c604 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -213,8 +213,7 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
kernel.
Otherwise it should be the start of memory region reserved for
- second kernel using boot parameter "crashkernel=Y@X". Here X is
- start of memory region reserved for dump-capture kernel.
+ second kernel using boot parameter "crashkernel=Y@X". Here X is start of memory region reserved for dump-capture kernel.
Generally X is 16MB (0x1000000). So you can set
CONFIG_PHYSICAL_START=0x1000000
@@ -315,6 +314,22 @@ crashkernel syntax
crashkernel=0,low
+4) crashkernel=size,cma
+
+ Reserves additional memory from CMA. A standard crashkernel reservation, as
+ described above, is still needed, but can be just big enough to hold the
+ kernel and initrd. All the memory the crash kernel needs for its runtime and
+ for running the kdump userspace processes can be provided by this CMA
+ reservation, re-using memory available to the production system's userspace.
+ Because of this, the CMA reservation should not be used if kdump is configured
+ to dump userspace memory - the re-used memory ranges won't be in the vmcore.
+
+ This option increases the risk of a kdump failure: DMA transfers configured
+ by the first kernel may end up corrupting the second kernel's memory. This
+ reservation method is intended for systems that can't afford to sacrifice
+ enough memory for standard crashkernel reservation and where less reliable
+ kdump is preferrable to no kdump at all.
+
Boot into System Kernel
-----------------------
1) Update the boot loader (such as grub, yaboot, or lilo) configuration
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fb8752b42ec8..ea4d53435515 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -987,6 +987,20 @@
0: to disable low allocation.
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 CMA.
+ This reservation is usable by the first system's userspace,
+ so this should not be used if dumping of userspace
+ memory is intended. A standard crashkernel reservation,
+ as described above, is still needed to hold the crash
+ kernel and initrd.
+ This option increases the risk of a kdump failure: DMA
+ transfers configured by the first kernel may end up
+ corrupting the second kernel's memory. This reservation
+ method is intended for systems that can't afford to
+ sacrifice enough memory for standard crashkernel
+ reservation and where less reliable kdump is preferrable
+ to no kdump at all.
cryptomgr.notests
[KNL] Disable crypto self-tests
--
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, Prague, Czechia
Powered by blists - more mailing lists