Re: [PATCH 4/4] arm64: route crash_smp_send_stop() last resort through SDEI

[Kiryl Shutsemau <kirill@shutemov.name>]

On Fri, Jun 05, 2026 at 10:46:11PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 05, 2026 at 01:42:57PM -0700, Doug Anderson wrote:
> > > +       sdei_nmi_crash_smp_send_stop();
> > 
> > It feels weird to me that you're adding SDEI for "crash stop" but not
> > for regular "stop". It feels like you should modify smp_send_stop() to
> > fall back to SDEI if sending the NMI failed, instead of adding this
> > separate path.
> 
> Fair. A wedged CPU ignores the reboot-path stop just the same, and the
> escalation logic already lives in smp.c, so I'll restructure in v2.
> 
> One thing to sort out there: this patch parks the stopped CPU inside
> its SDEI handler without completing the event, which is fine for the
> crash case (nothing expects the CPU back before reset), but a generic
> stop path probably wants SDEI_EVENT_COMPLETE_AND_RESUME into a parking
> stub instead, so that e.g. a regular kexec can bring all CPUs back up
> in the new kernel. I'll look into that as part of the rework.

Regular kexec takes different path and offlines CPU normally. So the
next kernel can start them. But crash kernel cannot re-use wedged CPU.

C&R alone doesn't buy us anything. We need to get the CPU to CPU_OFF.

I am trying to do this, but so far no luck. Crash kernel fails to start
at all if try to do C&R and then CPU_OFF. C&R alone works, but CPU is
still unreachable by the next kernel, as expected.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov