On Fri, Jun 05, 2026 at 01:54:00PM -0700, Doug Anderson wrote: > Hi, > > On Wed, Jun 3, 2026 at 7:36 AM Kiryl Shutsemau <[email protected]> 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(...);
Makes sense. > > } > > > > 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". No real downside -- without the software-signalled event the driver stays inert, and there is no cost until an event actually fires. The "say N" is caution, not a technical limit: so far this has run on QEMU (TF-A) and one hardware platform, and the interesting paths depend on each vendor's SDEI implementation at EL3. I'm not sure vendors would care to run SDEI_EVENT_SIGNAL validation. Maybe we want to see more data points first? But maybe I am too cautious. Happy to flip the recommendation (or add default y) in v2 if that the consensus. > Other than the nit, this looks reasoanble to me, though I'm a complete > noob when it comes to SDEI... > > Reviewed-by: Douglas Anderson <[email protected]> Thanks! -- Kiryl Shutsemau / Kirill A. Shutemov
