Re: [PATCH 2/4] drivers/firmware: add SDEI cross-CPU NMI service for arm64

[Kiryl Shutsemau]

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 <kirill@xxxxxxxxxxxxx> 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 <dianders@xxxxxxxxxxxx>

Thanks!

-- 
  Kiryl Shutsemau / Kirill A. Shutemov