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
