aleph/lkl_linux
1
0
Fork 0
mirror of https://github.com/lkl/linux.git synced 2025-12-19 08:03:01 +09:00
Code Issues Packages Projects Releases Wiki Activity
Files
24726275612140af6b1c0afc7c6611ad66233207
lkl_linux/kernel/Kconfig.kexec
Eric DeVolder 2472627561 crash: add generic infrastructure for crash hotplug support 
To support crash hotplug, a mechanism is needed to update the crash
elfcorehdr upon CPU or memory changes (eg.  hot un/plug or off/ onlining).
The crash elfcorehdr describes the CPUs and memory to be written into the
vmcore.

To track CPU changes, callbacks are registered with the cpuhp mechanism
via cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN).  The crash hotplug
elfcorehdr update has no explicit ordering requirement (relative to other
cpuhp states), so meets the criteria for utilizing CPUHP_BP_PREPARE_DYN. 
CPUHP_BP_PREPARE_DYN is a dynamic state and avoids the need to introduce a
new state for crash hotplug.  Also, CPUHP_BP_PREPARE_DYN is the last state
in the PREPARE group, just prior to the STARTING group, which is very
close to the CPU starting up in a plug/online situation, or stopping in a
unplug/ offline situation.  This minimizes the window of time during an
actual plug/online or unplug/offline situation in which the elfcorehdr
would be inaccurate.  Note that for a CPU being unplugged or offlined, the
CPU will still be present in the list of CPUs generated by
crash_prepare_elf64_headers().  However, there is no need to explicitly
omit the CPU, see justification in 'crash: change
crash_prepare_elf64_headers() to for_each_possible_cpu()'.

To track memory changes, a notifier is registered to capture the memblock
MEM_ONLINE and MEM_OFFLINE events via register_memory_notifier().

The CPU callbacks and memory notifiers invoke crash_handle_hotplug_event()
which performs needed tasks and then dispatches the event to the
architecture specific arch_crash_handle_hotplug_event() to update the
elfcorehdr with the current state of CPUs and memory.  During the process,
the kexec_lock is held.

Link: https://lkml.kernel.org/r/20230814214446.6659-3-eric.devolder@oracle.com
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Akhil Raj <lf32.dev@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-24 16:25:13 -07:00

147 lines
4.9 KiB
Plaintext
Raw Blame History

# SPDX-License-Identifier: GPL-2.0-only
menu "Kexec and crash features"
config CRASH_CORE
bool
config KEXEC_CORE
select CRASH_CORE
bool
config KEXEC_ELF
bool
config HAVE_IMA_KEXEC
bool
config KEXEC
bool "Enable kexec system call"
depends on ARCH_SUPPORTS_KEXEC
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
but it is independent of the system firmware. And like a reboot
you can start any kernel with it, not just Linux.
The name comes from the similarity to the exec system call.
It is an ongoing process to be certain the hardware in a machine
is properly shutdown, so do not be surprised if this code does not
initially work for you. As of this writing the exact hardware
interface is strongly in flux, so no good recommendation can be
made.
config KEXEC_FILE
bool "Enable kexec file based system call"
depends on ARCH_SUPPORTS_KEXEC_FILE
select KEXEC_CORE
help
This is new version of kexec system call. This system call is
file based and takes file descriptors as system call argument
for kernel and initramfs as opposed to list of segments as
accepted by kexec system call.
config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on ARCH_SUPPORTS_KEXEC_SIG
depends on KEXEC_FILE
help
This option makes the kexec_file_load() syscall check for a valid
signature of the kernel image. The image can still be loaded without
a valid signature unless you also enable KEXEC_SIG_FORCE, though if
there's a signature that we can check, then it must be valid.
In addition to this option, you need to enable signature
verification for the corresponding kernel image type being
loaded in order for this to work.
config KEXEC_SIG_FORCE
bool "Require a valid signature in kexec_file_load() syscall"
depends on ARCH_SUPPORTS_KEXEC_SIG_FORCE
depends on KEXEC_SIG
help
This option makes kernel signature verification mandatory for
the kexec_file_load() syscall.
config KEXEC_IMAGE_VERIFY_SIG
bool "Enable Image signature verification support (ARM)"
default ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG
depends on ARCH_SUPPORTS_KEXEC_IMAGE_VERIFY_SIG
depends on KEXEC_SIG
depends on EFI && SIGNED_PE_FILE_VERIFICATION
help
Enable Image signature verification support.
config KEXEC_BZIMAGE_VERIFY_SIG
bool "Enable bzImage signature verification support"
depends on ARCH_SUPPORTS_KEXEC_BZIMAGE_VERIFY_SIG
depends on KEXEC_SIG
depends on SIGNED_PE_FILE_VERIFICATION
select SYSTEM_TRUSTED_KEYRING
help
Enable bzImage signature verification support.
config KEXEC_JUMP
bool "kexec jump"
depends on ARCH_SUPPORTS_KEXEC_JUMP
depends on KEXEC && HIBERNATION
help
Jump between original kernel and kexeced kernel and invoke
code in physical address mode via KEXEC
config CRASH_DUMP
bool "kernel crash dumps"
depends on ARCH_SUPPORTS_CRASH_DUMP
depends on ARCH_SUPPORTS_KEXEC
select CRASH_CORE
select KEXEC_CORE
select KEXEC
help
Generate crash dump after being started by kexec.
This should be normally only set in special crash dump kernels
which are loaded in the main kernel with kexec-tools into
a specially reserved region and then later executed after
a crash by kdump/kexec. The crash dump kernel must be compiled
to a memory address not used by the main kernel or BIOS using
PHYSICAL_START, or it must be built as a relocatable image
(CONFIG_RELOCATABLE=y).
For more details see Documentation/admin-guide/kdump/kdump.rst
For s390, this option also enables zfcpdump.
See also <file:Documentation/s390/zfcpdump.rst>
config CRASH_HOTPLUG
bool "Update the crash elfcorehdr on system configuration changes"
default y
depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG)
depends on ARCH_SUPPORTS_CRASH_HOTPLUG
help
Enable direct update to the crash elfcorehdr (which contains
the list of CPUs and memory regions to be dumped upon a crash)
in response to hot plug/unplug or online/offline of CPUs or
memory. This is a much more advanced approach than userspace
attempting that.
If unsure, say Y.
config CRASH_MAX_MEMORY_RANGES
int "Specify the maximum number of memory regions for the elfcorehdr"
default 8192
depends on CRASH_HOTPLUG
help
For the kexec_file_load() syscall path, specify the maximum number of
memory regions that the elfcorehdr buffer/segment can accommodate.
These regions are obtained via walk_system_ram_res(); eg. the
'System RAM' entries in /proc/iomem.
This value is combined with NR_CPUS_DEFAULT and multiplied by
sizeof(Elf64_Phdr) to determine the final elfcorehdr memory buffer/
segment size.
The value 8192, for example, covers a (sparsely populated) 1TiB system
consisting of 128MiB memblocks, while resulting in an elfcorehdr
memory buffer/segment size under 1MiB. This represents a sane choice
to accommodate both baremetal and virtual machine configurations.
endmenu
Reference in New Issue View Git Blame Copy Permalink