[PATCH] ARM: kexec: EOI active and mask all interrupts in kexec crash path

[will.deacon@arm.com (Will Deacon)]

On Wed, Jan 18, 2012 at 03:40:44PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2012 at 03:31:20PM +0000, Will Deacon wrote:
> > On Wed, Jan 18, 2012 at 03:07:24PM +0000, Russell King - ARM Linux wrote:
> > > On Wed, Jan 18, 2012 at 03:01:25PM +0000, Will Deacon wrote:
> > > > The kexec machine crash code can be called in interrupt context via a
> > > > sysrq trigger made using the magic key combination. If the irq chip
> > > > dealing with the serial interrupt is using the fasteoi flow handler,
> > > > then we will never EOI the interrupt because the interrupt handler will
> > > > be fatal. In the case of a GIC, this results in the crash kernel not
> > > > receiving interrupts on that CPU interface.
> > > > 
> > > > This patch adds code (based on the PowerPC implementation) to EOI any
> > > > pending interrupts on the crash CPU before masking and disabling all
> > > > interrupts. Secondary cores are not a problem since they are placed into
> > > > a cpu_relax() loop via an IPI.
> > > 
> > > So, what happens if we fault in an interrupt handler, we have
> > > panic_on_oops set, and we have panic configured to automatically
> > > reboot after a period?
> > 
> > If we fault in an interrupt handler, we'll end up with the faulting CPU in
> > machine_crash_shutdown, with the secondaries getting put into
> > machine_crash_nonpanic_core. Then the faulting CPU will EOI the interrupt it
> > was previously handling, before masking it.
> 
> How does the faulting interrupt get EOI'd?  If we've faulted in an
> interrupt handler, we don't return to the interrupt handler to complete
> the handling.

That's what the new machine_kexec_mask_interrupts is supposed to do. It
iterates over all of the irq_descs and does:

	if (chip->irq_eoi && irqd_irq_inprogress(&desc->irq_data))
		chip->irq_eoi(&desc->irq_data);

This is called from machine_crash_shutdown, so we should pick up the
previous interrupt there without having to return to the handler.

> > The problem with that is working out which interrupts to EOI, on which
> > CPU interfaces and in which order. The GIC manual states that EOIing an
> > interrupt which hasn't been previously acked on that interface is
> > UNPREDICTABLE.
> 
> Is there no way to re-initialize the gic after an interrupt has begun
> to be processed, but not EOI'd ?

Unfortunately, I'm not aware of anything like this (I was hoping for some
reset functionality). I'll double check that I didn't miss anything, but it
seems that you can't reset the GIC state machine without manually putting it
all back.

Will