[PATCH] arm64: smp: Signal EOI after handling IPI_CPU_STOP*

[Marc Zyngier]

On Wed, 23 Sep 2026 16:41:42 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> [+Marc]
> 
> On Tue, Sep 22, 2026 at 04:01:09PM +0200, Andrea della Porta wrote:
> > On kdump/kexec, the boot CPU triggers an IPI_CPU_STOP (and subsequently
> > an IPI_CPU_STOP_NMI if the first one does not respond) to the secondary
> > CPUs, and the IPI handler eventually calls the firmware to shut down
> > each CPU. Since the IPI is never acknowledged via EOI, the interrupt
> > remains in an active state when the CPU goes idle.
> > 
> > In a virtualized environment, if the hypervisor does not reset the
> > interrupt state, this causes the crashkernel (with cmdline option
> > maxcpus > 1) to be unable to synchronize between the boot CPU and
> > secondary CPUs via IPI_CALL_FUNC, leading the kernel to wait indefinitely
> > for the CPUs to respond. This has been observed with the Hyper-V
> > implementation.
> 
> Hmm, how is this different from panic()ing inside an interrupt
> handler?

Also, what is the architectural requirement for the hypervisor to do
*anything* on the state of the interrupts? This doesn't happen on HW,
and there is no reason to impose this on a hypervisor either.

The expectations are that the guest kernel should reset the interrupt
state on boot, and it feels that this is missing somehow, see below.

> 
> > Both the Linux kernel and the Hyper-V firmware appear to violate the
> > PSCI specification:
> > 
> > - The PSCI spec states that the OS kernel must migrate any interrupt away
> > from the CPU that is about to be shut down via CPU_OFF, which by extension
> > implies that no active interrupts are allowed. The kernel does not
> > currently do this in the kdump crash path.

No. This is strictly about affinity, nothing else. It is there so that
global devices can continue to have their interrupts handled. This
evidently can't affect CPU-local interrupts.

> > 
> > - The PSCI spec also states that the PSCI firmware must reset the CPU
> > registers to their default values when turning on a CPU via the CPU_ON
> > command.

CPU registers. Not external peripherals such as the GIC.

> > 
> > Fixing this on the kernel side has the advantage of being
> > hypervisor-agnostic.
> > 
> > Signal EOI at the end of the crash handler to prevent the subsequent
> > crashkernel from hanging.
> > 
> > Signed-off-by: Andrea della Porta <andrea.porta at suse.com>
> > ---
> >  arch/arm64/kernel/smp.c | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index a61dc3016a117..cc7f3261fe537 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -988,6 +988,27 @@ void kgdb_roundup_cpus(void)
> >  }
> >  #endif
> >  
> > +static void ipi_eoi(int ipinr)
> > +{
> > +	unsigned int cpu = smp_processor_id();
> > +	struct irq_desc *desc;
> > +	struct irq_chip *chip;
> > +	struct irq_data *d;
> > +
> > +	if (ipinr >= MAX_IPI)
> > +		return;
> > +
> > +	desc = get_ipi_desc(cpu, ipinr);
> > +
> > +	if (desc) {
> > +		chip = irq_desc_get_chip(desc);
> > +		d = irq_desc_get_irq_data(desc);
> > +
> > +		if (chip && chip->irq_eoi)
> > +			chip->irq_eoi(d);
> > +	}
> > +}
> 
> Doesn't this hard-code the flow handler for the irqchip? It feels like it
> would be better for the GIC driver to get a callback during the kexec
> sequence (if it doesn't already) to prepare itself.

Yeah, that's not an acceptable approach.

The other observation is that the GIC drivers already clear the active
state at boot time (gic_cpu_init()). So what isn't that working?

Could it be that the hypervisor doesn't correctly handle the writes to
GICR_ICACTIVER0 to nuke the active state? Because this works correctly
on KVM as is.

Thanks,

	M.


-- 
Without deviation from the norm, progress is not possible.