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

[Marc Zyngier <maz@kernel.org>]

On Thu, 24 Sep 2026 10:03:56 +0100,
Andrea della Porta <andrea.porta@suse.com> wrote:
> 
> Hi Will and Marc,
> 
> On 19:23 Wed 23 Sep     , Marc Zyngier wrote:
> > On Wed, 23 Sep 2026 16:41:42 +0100,
> > Will Deacon <will@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?
> 
> It is not, in fact I should have put the EOI in all cases, but I just
> focused on the crash driver by IPI only. The patch should be extended
> but from the following discussion it does not seem relevant anymore.

The other problem here is that you're looking at the IPI that got you
there. But this IPI could have a higher priority than other interrupts
(NMI), and therefore have preempted them whilst they were active.

What happens with them? You'd need to iterate over all the interrupts
that are in progress and EOI/DIR them *in the correct order*. Which
would be replicating the GIC state machine. You can't do that in an
arbitrary order as that would violate the interrupt life cycle which
on some implementations results in a terminal SError.

[...]

> > >
> > > 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.
> 
> We're in a non returning handler which is about to shutdown the CPU in a few
> instructions, so I'm not sure how to callback into the GIC driver.

I reckon crash_kexec_post_notifiers and co could be of help, and could
be to some extent tucked away in the HV-specific code (but see below
for my full take on this).

> > 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.
> 
> That's what I suppose, but obviously I have no access to the implementation
> so I canot add more. This is currently under investigation by the folks who
> can, though...

OK. It'd be interesting to understand why the existing code fails in
your context, and getting feedback from the HV people would help.

> 
> So the bottom line is that we need to wait for a patch from the hypervisor 
> vendor (and from any vendor that *could* suffer from the same issue), I guess?

My take is that there is no point adding anything to the kernel until
we understand exactly what is at stake. The kernel's expectation is
that there is no difference between bare metal and virtualised, and
that fundamental parts of the architecture (such as interrupts) should
work as expected, no ifs, no buts.

If this isn't fixable, or that we don't know when this will be fixed,
we can always add an erratum workaround. But it needs to be captured
as such, which implies that we have the full understanding of the
issue.

Thanks,

	M.

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