2019-06-03 07:44:46 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-12-04 18:39:43 +11:00
|
|
|
/*
|
|
|
|
* Architecture specific (PPC64) functions for kexec based crash dumps.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2005, IBM Corp.
|
|
|
|
*
|
|
|
|
* Created by: Haren Myneni
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/reboot.h>
|
|
|
|
#include <linux/kexec.h>
|
2011-05-27 10:46:24 -04:00
|
|
|
#include <linux/export.h>
|
2005-12-04 18:39:43 +11:00
|
|
|
#include <linux/crash_dump.h>
|
|
|
|
#include <linux/delay.h>
|
2006-04-04 13:43:01 +02:00
|
|
|
#include <linux/irq.h>
|
2005-12-04 18:39:43 +11:00
|
|
|
#include <linux/types.h>
|
powerpc/crash: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
2024-03-26 11:24:12 +05:30
|
|
|
#include <linux/libfdt.h>
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
#include <linux/memory.h>
|
2005-12-04 18:39:43 +11:00
|
|
|
|
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/machdep.h>
|
2006-06-23 15:29:34 -07:00
|
|
|
#include <asm/kexec.h>
|
2006-01-10 19:25:25 -08:00
|
|
|
#include <asm/smp.h>
|
2008-01-18 15:50:30 +11:00
|
|
|
#include <asm/setjmp.h>
|
2012-03-28 18:30:02 +01:00
|
|
|
#include <asm/debug.h>
|
2021-04-14 19:00:33 +08:00
|
|
|
#include <asm/interrupt.h>
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
#include <asm/kexec_ranges.h>
|
2005-12-04 18:39:43 +11:00
|
|
|
|
2011-11-30 00:23:16 +00:00
|
|
|
/*
|
|
|
|
* The primary CPU waits a while for all secondary CPUs to enter. This is to
|
|
|
|
* avoid sending an IPI if the secondary CPUs are entering
|
|
|
|
* crash_kexec_secondary on their own (eg via a system reset).
|
|
|
|
*
|
|
|
|
* The secondary timeout has to be longer than the primary. Both timeouts are
|
|
|
|
* in milliseconds.
|
|
|
|
*/
|
|
|
|
#define PRIMARY_TIMEOUT 500
|
|
|
|
#define SECONDARY_TIMEOUT 1000
|
|
|
|
|
|
|
|
#define IPI_TIMEOUT 10000
|
|
|
|
#define REAL_MODE_TIMEOUT 10000
|
|
|
|
|
2011-11-30 00:23:17 +00:00
|
|
|
static int time_to_dump;
|
2022-06-30 12:19:42 +05:30
|
|
|
|
|
|
|
/*
|
|
|
|
* In case of system reset, secondary CPUs enter crash_kexec_secondary with out
|
|
|
|
* having to send an IPI explicitly. So, indicate if the crash is via
|
|
|
|
* system reset to avoid sending another IPI.
|
|
|
|
*/
|
|
|
|
static int is_via_system_reset;
|
|
|
|
|
2017-12-15 19:14:55 +11:00
|
|
|
/*
|
|
|
|
* crash_wake_offline should be set to 1 by platforms that intend to wake
|
|
|
|
* up offline cpus prior to jumping to a kdump kernel. Currently powernv
|
|
|
|
* sets it to 1, since we want to avoid things from happening when an
|
|
|
|
* offline CPU wakes up due to something like an HMI (malfunction error),
|
|
|
|
* which propagates to all threads.
|
|
|
|
*/
|
|
|
|
int crash_wake_offline;
|
2005-12-04 18:39:43 +11:00
|
|
|
|
2011-01-21 13:43:59 +11:00
|
|
|
#define CRASH_HANDLER_MAX 3
|
2016-05-11 10:57:32 +10:00
|
|
|
/* List of shutdown handles */
|
|
|
|
static crash_shutdown_t crash_shutdown_handles[CRASH_HANDLER_MAX];
|
2008-01-18 15:50:30 +11:00
|
|
|
static DEFINE_SPINLOCK(crash_handlers_lock);
|
|
|
|
|
2011-11-30 00:23:11 +00:00
|
|
|
static unsigned long crash_shutdown_buf[JMP_BUF_LEN];
|
|
|
|
static int crash_shutdown_cpu = -1;
|
|
|
|
|
|
|
|
static int handle_fault(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
if (crash_shutdown_cpu == smp_processor_id())
|
|
|
|
longjmp(crash_shutdown_buf, 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-12-04 18:39:43 +11:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
|
2012-01-17 19:13:05 +00:00
|
|
|
static atomic_t cpus_in_crash;
|
2017-12-15 19:14:55 +11:00
|
|
|
void crash_ipi_callback(struct pt_regs *regs)
|
2005-12-04 18:39:43 +11:00
|
|
|
{
|
2011-11-30 00:23:17 +00:00
|
|
|
static cpumask_t cpus_state_saved = CPU_MASK_NONE;
|
|
|
|
|
2005-12-04 18:39:43 +11:00
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
[POWERPC] Lazy interrupt disabling for 64-bit machines
This implements a lazy strategy for disabling interrupts. This means
that local_irq_disable() et al. just clear the 'interrupts are
enabled' flag in the paca. If an interrupt comes along, the interrupt
entry code notices that interrupts are supposed to be disabled, and
clears the EE bit in SRR1, clears the 'interrupts are hard-enabled'
flag in the paca, and returns. This means that interrupts only
actually get disabled in the processor when an interrupt comes along.
When interrupts are enabled by local_irq_enable() et al., the code
sets the interrupts-enabled flag in the paca, and then checks whether
interrupts got hard-disabled. If so, it also sets the EE bit in the
MSR to hard-enable the interrupts.
This has the potential to improve performance, and also makes it
easier to make a kernel that can boot on iSeries and on other 64-bit
machines, since this lazy-disable strategy is very similar to the
soft-disable strategy that iSeries already uses.
This version renames paca->proc_enabled to paca->soft_enabled, and
changes a couple of soft-disables in the kexec code to hard-disables,
which should fix the crash that Michael Ellerman saw. This doesn't
yet use a reserved CR field for the soft_enabled and hard_enabled
flags. This applies on top of Stephen Rothwell's patches to make it
possible to build a combined iSeries/other kernel.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-04 16:47:49 +10:00
|
|
|
hard_irq_disable();
|
2011-11-30 00:23:17 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, &cpus_state_saved)) {
|
2006-12-06 20:40:41 -08:00
|
|
|
crash_save_cpu(regs, cpu);
|
2011-11-30 00:23:17 +00:00
|
|
|
cpumask_set_cpu(cpu, &cpus_state_saved);
|
|
|
|
}
|
|
|
|
|
|
|
|
atomic_inc(&cpus_in_crash);
|
2014-03-13 19:00:35 +01:00
|
|
|
smp_mb__after_atomic();
|
2005-12-04 18:39:43 +11:00
|
|
|
|
2006-06-23 15:29:34 -07:00
|
|
|
/*
|
|
|
|
* Starting the kdump boot.
|
|
|
|
* This barrier is needed to make sure that all CPUs are stopped.
|
|
|
|
*/
|
2011-11-30 00:23:17 +00:00
|
|
|
while (!time_to_dump)
|
2006-06-23 15:29:34 -07:00
|
|
|
cpu_relax();
|
|
|
|
|
|
|
|
if (ppc_md.kexec_cpu_down)
|
|
|
|
ppc_md.kexec_cpu_down(1, 1);
|
2006-07-05 14:39:43 +10:00
|
|
|
|
|
|
|
#ifdef CONFIG_PPC64
|
2005-12-04 18:39:43 +11:00
|
|
|
kexec_smp_wait();
|
2006-07-05 14:39:43 +10:00
|
|
|
#else
|
|
|
|
for (;;); /* FIXME */
|
|
|
|
#endif
|
|
|
|
|
2005-12-04 18:39:43 +11:00
|
|
|
/* NOTREACHED */
|
|
|
|
}
|
|
|
|
|
2022-06-30 12:19:42 +05:30
|
|
|
static void crash_kexec_prepare_cpus(void)
|
2005-12-04 18:39:43 +11:00
|
|
|
{
|
|
|
|
unsigned int msecs;
|
2021-04-29 10:06:38 +02:00
|
|
|
volatile unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
|
|
|
|
volatile int tries = 0;
|
2011-11-30 00:23:11 +00:00
|
|
|
int (*old_handler)(struct pt_regs *regs);
|
2005-12-04 18:39:43 +11:00
|
|
|
|
2011-11-30 00:23:10 +00:00
|
|
|
printk(KERN_EMERG "Sending IPI to other CPUs\n");
|
|
|
|
|
2017-12-15 19:14:55 +11:00
|
|
|
if (crash_wake_offline)
|
|
|
|
ncpus = num_present_cpus() - 1;
|
|
|
|
|
2022-06-30 12:19:42 +05:30
|
|
|
/*
|
|
|
|
* If we came in via system reset, secondaries enter via crash_kexec_secondary().
|
|
|
|
* So, wait a while for the secondary CPUs to enter for that case.
|
|
|
|
* Else, send IPI to all other CPUs.
|
|
|
|
*/
|
|
|
|
if (is_via_system_reset)
|
|
|
|
mdelay(PRIMARY_TIMEOUT);
|
|
|
|
else
|
|
|
|
crash_send_ipi(crash_ipi_callback);
|
2005-12-04 18:39:43 +11:00
|
|
|
smp_wmb();
|
|
|
|
|
2011-11-30 00:23:11 +00:00
|
|
|
again:
|
2005-12-04 18:39:43 +11:00
|
|
|
/*
|
2011-01-21 13:43:59 +11:00
|
|
|
* FIXME: Until we will have the way to stop other CPUs reliably,
|
2005-12-04 18:39:43 +11:00
|
|
|
* the crash CPU will send an IPI and wait for other CPUs to
|
2006-06-23 15:29:34 -07:00
|
|
|
* respond.
|
2005-12-04 18:39:43 +11:00
|
|
|
*/
|
2011-11-30 00:23:16 +00:00
|
|
|
msecs = IPI_TIMEOUT;
|
2011-11-30 00:23:17 +00:00
|
|
|
while ((atomic_read(&cpus_in_crash) < ncpus) && (--msecs > 0))
|
2005-12-04 18:39:43 +11:00
|
|
|
mdelay(1);
|
|
|
|
|
|
|
|
/* Would it be better to replace the trap vector here? */
|
|
|
|
|
2011-11-30 00:23:17 +00:00
|
|
|
if (atomic_read(&cpus_in_crash) >= ncpus) {
|
2011-11-30 00:23:11 +00:00
|
|
|
printk(KERN_EMERG "IPI complete\n");
|
|
|
|
return;
|
2006-06-23 15:29:34 -07:00
|
|
|
}
|
2011-11-30 00:23:10 +00:00
|
|
|
|
2011-11-30 00:23:11 +00:00
|
|
|
printk(KERN_EMERG "ERROR: %d cpu(s) not responding\n",
|
2011-11-30 00:23:17 +00:00
|
|
|
ncpus - atomic_read(&cpus_in_crash));
|
2011-11-30 00:23:11 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have a panic timeout set then we can't wait indefinitely
|
|
|
|
* for someone to activate system reset. We also give up on the
|
|
|
|
* second time through if system reset fail to work.
|
|
|
|
*/
|
|
|
|
if ((panic_timeout > 0) || (tries > 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A system reset will cause all CPUs to take an 0x100 exception.
|
|
|
|
* The primary CPU returns here via setjmp, and the secondary
|
|
|
|
* CPUs reexecute the crash_kexec_secondary path.
|
|
|
|
*/
|
|
|
|
old_handler = __debugger;
|
|
|
|
__debugger = handle_fault;
|
|
|
|
crash_shutdown_cpu = smp_processor_id();
|
|
|
|
|
|
|
|
if (setjmp(crash_shutdown_buf) == 0) {
|
|
|
|
printk(KERN_EMERG "Activate system reset (dumprestart) "
|
|
|
|
"to stop other cpu(s)\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A system reset will force all CPUs to execute the
|
|
|
|
* crash code again. We need to reset cpus_in_crash so we
|
|
|
|
* wait for everyone to do this.
|
|
|
|
*/
|
2011-11-30 00:23:17 +00:00
|
|
|
atomic_set(&cpus_in_crash, 0);
|
2011-11-30 00:23:11 +00:00
|
|
|
smp_mb();
|
|
|
|
|
2011-11-30 00:23:17 +00:00
|
|
|
while (atomic_read(&cpus_in_crash) < ncpus)
|
2011-11-30 00:23:11 +00:00
|
|
|
cpu_relax();
|
|
|
|
}
|
|
|
|
|
|
|
|
crash_shutdown_cpu = -1;
|
|
|
|
__debugger = old_handler;
|
|
|
|
|
|
|
|
tries++;
|
|
|
|
goto again;
|
2005-12-04 18:39:43 +11:00
|
|
|
}
|
2006-06-23 15:29:34 -07:00
|
|
|
|
|
|
|
/*
|
2011-11-30 00:23:10 +00:00
|
|
|
* This function will be called by secondary cpus.
|
2006-06-23 15:29:34 -07:00
|
|
|
*/
|
|
|
|
void crash_kexec_secondary(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2011-11-30 00:23:16 +00:00
|
|
|
int msecs = SECONDARY_TIMEOUT;
|
2006-06-23 15:29:34 -07:00
|
|
|
|
|
|
|
local_irq_save(flags);
|
2011-11-30 00:23:10 +00:00
|
|
|
|
2011-11-30 00:23:16 +00:00
|
|
|
/* Wait for the primary crash CPU to signal its progress */
|
2006-06-23 15:29:34 -07:00
|
|
|
while (crashing_cpu < 0) {
|
|
|
|
if (--msecs < 0) {
|
2011-11-30 00:23:10 +00:00
|
|
|
/* No response, kdump image may not have been loaded */
|
2006-06-23 15:29:34 -07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
return;
|
|
|
|
}
|
2011-11-30 00:23:10 +00:00
|
|
|
|
2006-06-23 15:29:34 -07:00
|
|
|
mdelay(1);
|
|
|
|
}
|
2011-11-30 00:23:10 +00:00
|
|
|
|
2006-06-23 15:29:34 -07:00
|
|
|
crash_ipi_callback(regs);
|
|
|
|
}
|
|
|
|
|
2011-04-13 06:30:08 +00:00
|
|
|
#else /* ! CONFIG_SMP */
|
|
|
|
|
2022-06-30 12:19:42 +05:30
|
|
|
static void crash_kexec_prepare_cpus(void)
|
2005-12-04 18:39:43 +11:00
|
|
|
{
|
|
|
|
/*
|
2011-11-30 00:23:12 +00:00
|
|
|
* move the secondaries to us so that we can copy
|
2005-12-04 18:39:43 +11:00
|
|
|
* the new kernel 0-0x100 safely
|
|
|
|
*
|
|
|
|
* do this if kexec in setup.c ?
|
|
|
|
*/
|
2006-07-05 14:39:43 +10:00
|
|
|
#ifdef CONFIG_PPC64
|
2005-12-04 18:39:43 +11:00
|
|
|
smp_release_cpus();
|
2006-07-05 14:39:43 +10:00
|
|
|
#else
|
|
|
|
/* FIXME */
|
|
|
|
#endif
|
2005-12-04 18:39:43 +11:00
|
|
|
}
|
|
|
|
|
2006-06-23 15:29:34 -07:00
|
|
|
void crash_kexec_secondary(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
}
|
2011-04-13 06:30:08 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
2005-12-04 18:39:43 +11:00
|
|
|
|
2011-04-24 15:04:31 +00:00
|
|
|
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
|
2015-10-06 22:48:16 -05:00
|
|
|
#if defined(CONFIG_SMP) && defined(CONFIG_PPC64)
|
2022-05-19 17:45:21 +10:00
|
|
|
noinstr static void __maybe_unused crash_kexec_wait_realmode(int cpu)
|
2011-04-24 15:04:31 +00:00
|
|
|
{
|
|
|
|
unsigned int msecs;
|
|
|
|
int i;
|
|
|
|
|
2011-11-30 00:23:16 +00:00
|
|
|
msecs = REAL_MODE_TIMEOUT;
|
2011-05-10 19:28:41 +00:00
|
|
|
for (i=0; i < nr_cpu_ids && msecs > 0; i++) {
|
2011-04-24 15:04:31 +00:00
|
|
|
if (i == cpu)
|
|
|
|
continue;
|
|
|
|
|
2018-02-14 01:08:12 +10:00
|
|
|
while (paca_ptrs[i]->kexec_state < KEXEC_STATE_REAL_MODE) {
|
2011-04-24 15:04:31 +00:00
|
|
|
barrier();
|
2011-07-04 20:40:10 +00:00
|
|
|
if (!cpu_possible(i) || !cpu_online(i) || (msecs <= 0))
|
2011-04-24 15:04:31 +00:00
|
|
|
break;
|
|
|
|
msecs--;
|
|
|
|
mdelay(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mb();
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void crash_kexec_wait_realmode(int cpu) {}
|
2015-10-06 22:48:16 -05:00
|
|
|
#endif /* CONFIG_SMP && CONFIG_PPC64 */
|
2011-04-24 15:04:31 +00:00
|
|
|
|
2022-06-30 12:19:42 +05:30
|
|
|
void crash_kexec_prepare(void)
|
|
|
|
{
|
|
|
|
/* Avoid hardlocking with irresponsive CPU holding logbuf_lock */
|
|
|
|
printk_deferred_enter();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is only called after the system
|
|
|
|
* has panicked or is otherwise in a critical state.
|
|
|
|
* The minimum amount of code to allow a kexec'd kernel
|
|
|
|
* to run successfully needs to happen here.
|
|
|
|
*
|
|
|
|
* In practice this means stopping other cpus in
|
|
|
|
* an SMP system.
|
|
|
|
* The kernel is broken so disable interrupts.
|
|
|
|
*/
|
|
|
|
hard_irq_disable();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make a note of crashing cpu. Will be used in machine_kexec
|
|
|
|
* such that another IPI will not be sent.
|
|
|
|
*/
|
|
|
|
crashing_cpu = smp_processor_id();
|
|
|
|
|
|
|
|
crash_kexec_prepare_cpus();
|
|
|
|
}
|
|
|
|
|
2008-01-18 15:50:30 +11:00
|
|
|
/*
|
|
|
|
* Register a function to be called on shutdown. Only use this if you
|
|
|
|
* can't reset your device in the second kernel.
|
|
|
|
*/
|
|
|
|
int crash_shutdown_register(crash_shutdown_t handler)
|
|
|
|
{
|
|
|
|
unsigned int i, rc;
|
|
|
|
|
|
|
|
spin_lock(&crash_handlers_lock);
|
|
|
|
for (i = 0 ; i < CRASH_HANDLER_MAX; i++)
|
|
|
|
if (!crash_shutdown_handles[i]) {
|
|
|
|
/* Insert handle at first empty entry */
|
|
|
|
crash_shutdown_handles[i] = handler;
|
|
|
|
rc = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == CRASH_HANDLER_MAX) {
|
|
|
|
printk(KERN_ERR "Crash shutdown handles full, "
|
|
|
|
"not registered.\n");
|
|
|
|
rc = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&crash_handlers_lock);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crash_shutdown_register);
|
|
|
|
|
|
|
|
int crash_shutdown_unregister(crash_shutdown_t handler)
|
|
|
|
{
|
|
|
|
unsigned int i, rc;
|
|
|
|
|
|
|
|
spin_lock(&crash_handlers_lock);
|
|
|
|
for (i = 0 ; i < CRASH_HANDLER_MAX; i++)
|
|
|
|
if (crash_shutdown_handles[i] == handler)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (i == CRASH_HANDLER_MAX) {
|
|
|
|
printk(KERN_ERR "Crash shutdown handle not found\n");
|
|
|
|
rc = 1;
|
|
|
|
} else {
|
|
|
|
/* Shift handles down */
|
2016-05-11 10:57:32 +10:00
|
|
|
for (; i < (CRASH_HANDLER_MAX - 1); i++)
|
2008-01-18 15:50:30 +11:00
|
|
|
crash_shutdown_handles[i] =
|
|
|
|
crash_shutdown_handles[i+1];
|
2016-05-11 10:57:32 +10:00
|
|
|
/*
|
|
|
|
* Reset last entry to NULL now that it has been shifted down,
|
|
|
|
* this will allow new handles to be added here.
|
|
|
|
*/
|
|
|
|
crash_shutdown_handles[i] = NULL;
|
2008-01-18 15:50:30 +11:00
|
|
|
rc = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&crash_handlers_lock);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crash_shutdown_unregister);
|
|
|
|
|
2005-12-04 18:39:43 +11:00
|
|
|
void default_machine_crash_shutdown(struct pt_regs *regs)
|
|
|
|
{
|
2023-08-09 15:10:08 +02:00
|
|
|
volatile unsigned int i;
|
2008-01-18 15:50:30 +11:00
|
|
|
int (*old_handler)(struct pt_regs *regs);
|
|
|
|
|
2021-04-14 19:00:33 +08:00
|
|
|
if (TRAP(regs) == INTERRUPT_SYSTEM_RESET)
|
2022-06-30 12:19:42 +05:30
|
|
|
is_via_system_reset = 1;
|
2011-11-30 00:23:16 +00:00
|
|
|
|
2025-02-11 10:20:54 -06:00
|
|
|
if (IS_ENABLED(CONFIG_SMP))
|
|
|
|
crash_smp_send_stop();
|
|
|
|
else
|
|
|
|
crash_kexec_prepare();
|
2011-11-30 00:23:17 +00:00
|
|
|
|
|
|
|
crash_save_cpu(regs, crashing_cpu);
|
|
|
|
|
|
|
|
time_to_dump = 1;
|
|
|
|
|
2010-08-02 20:39:41 +00:00
|
|
|
crash_kexec_wait_realmode(crashing_cpu);
|
|
|
|
|
2010-09-16 17:58:23 -05:00
|
|
|
machine_kexec_mask_interrupts();
|
2008-01-18 15:50:30 +11:00
|
|
|
|
|
|
|
/*
|
2011-11-30 00:23:12 +00:00
|
|
|
* Call registered shutdown routines safely. Swap out
|
2008-01-18 15:50:30 +11:00
|
|
|
* __debugger_fault_handler, and replace on exit.
|
|
|
|
*/
|
|
|
|
old_handler = __debugger_fault_handler;
|
|
|
|
__debugger_fault_handler = handle_fault;
|
2010-05-10 16:25:51 +00:00
|
|
|
crash_shutdown_cpu = smp_processor_id();
|
2016-07-11 14:17:31 +10:00
|
|
|
for (i = 0; i < CRASH_HANDLER_MAX && crash_shutdown_handles[i]; i++) {
|
2008-01-18 15:50:30 +11:00
|
|
|
if (setjmp(crash_shutdown_buf) == 0) {
|
|
|
|
/*
|
|
|
|
* Insert syncs and delay to ensure
|
|
|
|
* instructions in the dangerous region don't
|
|
|
|
* leak away from this protected region.
|
|
|
|
*/
|
|
|
|
asm volatile("sync; isync");
|
|
|
|
/* dangerous region */
|
|
|
|
crash_shutdown_handles[i]();
|
|
|
|
asm volatile("sync; isync");
|
|
|
|
}
|
2006-04-04 13:43:01 +02:00
|
|
|
}
|
2010-05-10 16:25:51 +00:00
|
|
|
crash_shutdown_cpu = -1;
|
2008-01-18 15:50:30 +11:00
|
|
|
__debugger_fault_handler = old_handler;
|
2006-04-04 13:43:01 +02:00
|
|
|
|
2006-06-23 15:29:34 -07:00
|
|
|
if (ppc_md.kexec_cpu_down)
|
|
|
|
ppc_md.kexec_cpu_down(1, 0);
|
2005-12-04 18:39:43 +11:00
|
|
|
}
|
powerpc/crash: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
2024-03-26 11:24:12 +05:30
|
|
|
|
|
|
|
#ifdef CONFIG_CRASH_HOTPLUG
|
|
|
|
#undef pr_fmt
|
|
|
|
#define pr_fmt(fmt) "crash hp: " fmt
|
|
|
|
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
/*
|
|
|
|
* Advertise preferred elfcorehdr size to userspace via
|
|
|
|
* /sys/kernel/crash_elfcorehdr_size sysfs interface.
|
|
|
|
*/
|
|
|
|
unsigned int arch_crash_get_elfcorehdr_size(void)
|
|
|
|
{
|
|
|
|
unsigned long phdr_cnt;
|
|
|
|
|
|
|
|
/* A program header for possible CPUs + vmcoreinfo */
|
|
|
|
phdr_cnt = num_possible_cpus() + 1;
|
|
|
|
if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
|
|
|
|
phdr_cnt += CONFIG_CRASH_MAX_MEMORY_RANGES;
|
|
|
|
|
|
|
|
return sizeof(struct elfhdr) + (phdr_cnt * sizeof(Elf64_Phdr));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* update_crash_elfcorehdr() - Recreate the elfcorehdr and replace it with old
|
|
|
|
* elfcorehdr in the kexec segment array.
|
|
|
|
* @image: the active struct kimage
|
|
|
|
* @mn: struct memory_notify data handler
|
|
|
|
*/
|
|
|
|
static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *mn)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct crash_mem *cmem = NULL;
|
|
|
|
struct kexec_segment *ksegment;
|
|
|
|
void *ptr, *mem, *elfbuf = NULL;
|
|
|
|
unsigned long elfsz, memsz, base_addr, size;
|
|
|
|
|
|
|
|
ksegment = &image->segment[image->elfcorehdr_index];
|
|
|
|
mem = (void *) ksegment->mem;
|
|
|
|
memsz = ksegment->memsz;
|
|
|
|
|
|
|
|
ret = get_crash_memory_ranges(&cmem);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("Failed to get crash mem range\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The hot unplugged memory is part of crash memory ranges,
|
|
|
|
* remove it here.
|
|
|
|
*/
|
|
|
|
if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
|
|
|
|
base_addr = PFN_PHYS(mn->start_pfn);
|
|
|
|
size = mn->nr_pages * PAGE_SIZE;
|
|
|
|
ret = remove_mem_range(&cmem, base_addr, size);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = crash_prepare_elf64_headers(cmem, false, &elfbuf, &elfsz);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("Failed to prepare elf header\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is unlikely that kernel hit this because elfcorehdr kexec
|
|
|
|
* segment (memsz) is built with addition space to accommodate growing
|
|
|
|
* number of crash memory ranges while loading the kdump kernel. It is
|
|
|
|
* Just to avoid any unforeseen case.
|
|
|
|
*/
|
|
|
|
if (elfsz > memsz) {
|
|
|
|
pr_err("Updated crash elfcorehdr elfsz %lu > memsz %lu", elfsz, memsz);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ptr = __va(mem);
|
|
|
|
if (ptr) {
|
|
|
|
/* Temporarily invalidate the crash image while it is replaced */
|
|
|
|
xchg(&kexec_crash_image, NULL);
|
|
|
|
|
|
|
|
/* Replace the old elfcorehdr with newly prepared elfcorehdr */
|
|
|
|
memcpy((void *)ptr, elfbuf, elfsz);
|
|
|
|
|
|
|
|
/* The crash image is now valid once again */
|
|
|
|
xchg(&kexec_crash_image, image);
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
kvfree(cmem);
|
2024-05-02 23:50:40 +05:30
|
|
|
kvfree(elfbuf);
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
}
|
|
|
|
|
powerpc/crash: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
2024-03-26 11:24:12 +05:30
|
|
|
/**
|
|
|
|
* get_fdt_index - Loop through the kexec segment array and find
|
|
|
|
* the index of the FDT segment.
|
|
|
|
* @image: a pointer to kexec_crash_image
|
|
|
|
*
|
|
|
|
* Returns the index of FDT segment in the kexec segment array
|
|
|
|
* if found; otherwise -1.
|
|
|
|
*/
|
|
|
|
static int get_fdt_index(struct kimage *image)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
unsigned long mem;
|
|
|
|
int i, fdt_index = -1;
|
|
|
|
|
|
|
|
/* Find the FDT segment index in kexec segment array. */
|
|
|
|
for (i = 0; i < image->nr_segments; i++) {
|
|
|
|
mem = image->segment[i].mem;
|
|
|
|
ptr = __va(mem);
|
|
|
|
|
|
|
|
if (ptr && fdt_magic(ptr) == FDT_MAGIC) {
|
|
|
|
fdt_index = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return fdt_index;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* update_crash_fdt - updates the cpus node of the crash FDT.
|
|
|
|
*
|
|
|
|
* @image: a pointer to kexec_crash_image
|
|
|
|
*/
|
|
|
|
static void update_crash_fdt(struct kimage *image)
|
|
|
|
{
|
|
|
|
void *fdt;
|
|
|
|
int fdt_index;
|
|
|
|
|
|
|
|
fdt_index = get_fdt_index(image);
|
|
|
|
if (fdt_index < 0) {
|
|
|
|
pr_err("Unable to locate FDT segment.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
fdt = __va((void *)image->segment[fdt_index].mem);
|
|
|
|
|
|
|
|
/* Temporarily invalidate the crash image while it is replaced */
|
|
|
|
xchg(&kexec_crash_image, NULL);
|
|
|
|
|
|
|
|
/* update FDT to reflect changes in CPU resources */
|
|
|
|
if (update_cpus_node(fdt))
|
|
|
|
pr_err("Failed to update crash FDT");
|
|
|
|
|
|
|
|
/* The crash image is now valid once again */
|
|
|
|
xchg(&kexec_crash_image, image);
|
|
|
|
}
|
|
|
|
|
|
|
|
int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_KEXEC_FILE
|
|
|
|
if (image->file_mode)
|
|
|
|
return 1;
|
|
|
|
#endif
|
|
|
|
return kexec_flags & KEXEC_CRASH_HOTPLUG_SUPPORT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* arch_crash_handle_hotplug_event - Handle crash CPU/Memory hotplug events to update the
|
|
|
|
* necessary kexec segments based on the hotplug event.
|
|
|
|
* @image: a pointer to kexec_crash_image
|
|
|
|
* @arg: struct memory_notify handler for memory hotplug case and NULL for CPU hotplug case.
|
|
|
|
*
|
|
|
|
* Update the kdump image based on the type of hotplug event, represented by image->hp_action.
|
|
|
|
* CPU add: Update the FDT segment to include the newly added CPU.
|
|
|
|
* CPU remove: No action is needed, with the assumption that it's okay to have offline CPUs
|
|
|
|
* part of the FDT.
|
|
|
|
* Memory add/remove: No action is taken as this is not yet supported.
|
|
|
|
*/
|
|
|
|
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
|
|
|
|
{
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
struct memory_notify *mn;
|
|
|
|
|
powerpc/crash: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
2024-03-26 11:24:12 +05:30
|
|
|
switch (image->hp_action) {
|
|
|
|
case KEXEC_CRASH_HP_REMOVE_CPU:
|
|
|
|
return;
|
|
|
|
|
|
|
|
case KEXEC_CRASH_HP_ADD_CPU:
|
|
|
|
update_crash_fdt(image);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case KEXEC_CRASH_HP_REMOVE_MEMORY:
|
|
|
|
case KEXEC_CRASH_HP_ADD_MEMORY:
|
powerpc/crash: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot remove, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <----> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-7-sourabhjain@linux.ibm.com
2024-03-26 11:24:13 +05:30
|
|
|
mn = (struct memory_notify *)arg;
|
|
|
|
update_crash_elfcorehdr(image, mn);
|
powerpc/crash: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240326055413.186534-6-sourabhjain@linux.ibm.com
2024-03-26 11:24:12 +05:30
|
|
|
return;
|
|
|
|
default:
|
|
|
|
pr_warn_once("Unknown hotplug action\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_CRASH_HOTPLUG */
|