Hi, On Thu, Jun 11, 2026 at 10:47 AM Kiryl Shutsemau <[email protected]> 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!
