Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI

[Kiryl Shutsemau <kirill@shutemov.name>]

On Mon, Jun 29, 2026 at 04:54:18PM +0100, Catalin Marinas wrote:
> Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE
> won't return to the kernel. We have sdei_handler_abort() to complete the
> event and, hopefully, you can continue with the CPU_OFF. It's a work
> around the TF-A non-compliance but I think this is useful even if you
> don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop).

Tried it. The result is the opposite of what I expected, and it argues
against doing the complete at all under QEMU's TF-A.

Same A/B harness as before -- a CPU wedged with interrupts masked is
stopped via the SDEI rung; I only vary how its handler ends. kdump
capture kernel boot under QEMU:

  - park, event left uncompleted (current series):   boots to a shell
  - sdei_handler_abort() then CPU_OFF:               hangs at SDEI re-init
  - sdei_handler_abort() then park (no CPU_OFF):     hangs at SDEI re-init
  - CPU_OFF, event left uncompleted:                 hangs at SDEI re-init

The third line is the surprising one: completing the event via
sdei_handler_abort() and then just parking -- no CPU_OFF at all -- breaks
the capture kernel too, at the same point as CPU_OFF does. The only
variant that boots is the one that leaves the event uncompleted and
parks. So here it's completing the event that the capture kernel trips
over, not the dangling dispatch -- backwards from the non-compliance
theory, where completing should be the safe thing and "useful even
without CPU_OFF".

-- 
  Kiryl Shutsemau / Kirill A. Shutemov