[PATCH v2 3/3] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort

[Doug Anderson]

Hi,

On Thu, Jun 11, 2026 at 10:47 AM Kiryl Shutsemau <kirill at shutemov.name> wrote:
>
> > FWIW, I'm not totally sure I followed the logic for why "die_on_crash"
> > needs to be "false" for the SDEI case,
>
> It's not about kexec mechanics, it's about the SDEI dispatch state.
>
> The SDEI stop handler parks inside an SDEI event that it deliberately
> never completes — completing it makes firmware resume the wedged
> context, which is the opposite of what we want. PSCI CPU_OFF from inside
> that not-yet-completed event silently wedges EL3 on at least one
> production firmware (still root-causing on the firmware side), so the
> SDEI path saves the crashed context and parks instead of powering off.
>
> The only consequence is that an SMP capture kernel can't re-online that
> CPU. The dump itself is complete. I've left "power the SDEI-stopped CPU
> off too" as a follow-up and called it out in the cover letter. The IPI
> crash path is unaffected and still does CPU_OFF, exactly as before.

Ah, OK. This makes sense. I read the cover letter, but I guess this
part of it didn't stick in my mind. I wouldn't mind an explanation of
what's going on being included as a comment in the code. Then someone
down the line won't be left wondering.


> > Do you have any reasoning for why you don't pick a separate EVENT ID
> > for "backtrace" vs. "stop". If you absolutely have to share an ID
> > because they're a limited resource then I guess it's fine, but it
> > would make the code easier to understand / reason about if they were
> > separate IDs.
> >
> > If you had a separate EVENT ID, then it seems like you could
> > completely eliminate the (potentially large) `sdei_nmi_stop_mask`
> > variable, right? Any time a "STOP" event fires you can unconditionally
> > consider it to be a stop w/ no globals needed, right?
>
> Separate event IDs aren't available: SDEI_EVENT_SIGNAL only ever signals
> event 0 — it's the one architecturally software-signalled event. Every
> other event number is an interrupt-bound event that firmware has to
> define and bind, which is the firmware dependency this series is
> specifically trying not to add. So backtrace and stop are stuck sharing
> event 0.

Oh well.


> But you're right that the mask should go — just not via a second event. A
> stop is terminal and system-wide (sdei_nmi_stop_cpus() is only reached
> from smp_send_stop(), which never returns), so once a stop is requested
> every later event-0 fire is a stop too. I replaced the cpumask with a
> single write-once flag the handler reads; a backtrace that races in
> after a stop has begun just stops that CPU, which is fine. So the
> (potentially large) variable is gone.

Yeah, this sounds much better, thanks!