[PATCH 2/4] drivers/firmware: add SDEI cross-CPU NMI service for arm64
Doug Anderson
dianders at chromium.org
Fri Jun 5 13:54:00 PDT 2026
Hi,
On Wed, Jun 3, 2026 at 7:36 AM Kiryl Shutsemau <kirill at shutemov.name> wrote:
>
> @@ -928,11 +929,19 @@ static void arm64_backtrace_ipi(cpumask_t *mask)
> void arch_trigger_cpumask_backtrace(const cpumask_t *mask, int exclude_cpu)
> {
> /*
> + * Prefer the SDEI cross-CPU NMI provider when active: firmware
> + * dispatches the event out of EL3 and reaches CPUs that have
> + * interrupts locally masked, without the per-IRQ-mask cost that
> + * pseudo-NMI pays for the same reach. The plain IPI path below
> + * can't reach such a CPU unless pseudo-NMI is enabled.
> + *
> * NOTE: though nmi_trigger_cpumask_backtrace() has "nmi_" in the name,
> * nothing about it truly needs to be implemented using an NMI, it's
> * just that it's _allowed_ to work with NMIs. If ipi_should_be_nmi()
> * returned false our backtrace attempt will just use a regular IPI.
> */
> + if (sdei_nmi_trigger_cpumask_backtrace(mask, exclude_cpu))
> + return;
> nmi_trigger_cpumask_backtrace(mask, exclude_cpu, arm64_backtrace_ipi);
nit: instead of one comment block, I would have broken it up in two. Like:
/*
* Prefer the SDEI ...
*/
if (sdei_nmi_trigger_cpumask_backtrace(mask, exclude_cpu))
return;
/*
* NOTE: though ...
*/
nmi_trigger_cpumask_backtrace(...);
> }
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index bbd2155d8483..6501087ff90d 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -36,6 +36,25 @@ config ARM_SDE_INTERFACE
> standard for registering callbacks from the platform firmware
> into the OS. This is typically used to implement RAS notifications.
>
> +config ARM_SDEI_NMI
> + bool "SDEI-based cross-CPU NMI service (arm64)"
> + depends on ARM64 && ARM_SDE_INTERFACE
> + help
> + Provides SDEI-based cross-CPU NMI delivery for hooks that need
> + to reach interrupt-masked CPUs on silicon that lacks FEAT_NMI:
> +
> + - arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls,
> + hardlockup_all_cpu_backtrace, soft-lockup secondary dumps,
> + hung-task auxiliary dumps)
> +
> + The driver registers a handler for the SDEI software-signalled
> + event (event 0) and reaches a target CPU by signalling it with
> + SDEI_EVENT_SIGNAL. Firmware delivers the event out of EL3
> + regardless of the target's PSTATE.DAIF -- forced delivery into a
> + CPU wedged with interrupts locally masked.
> +
> + If unsure, say N.
Is there some downside to this? It seems like anyone who has the SDE
interface would want this. Not sure why you'd suggest people say "N".
Other than the nit, this looks reasoanble to me, though I'm a complete
noob when it comes to SDEI...
Reviewed-by: Douglas Anderson <dianders at chromium.org>
More information about the kexec
mailing list