Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown

[Marc Zyngier]

On 09/03/18 10:33, Grzegorz Jaszczyk wrote:
>> Not using EOImode==1 is definitely an oddity (at least on the host), but
>> that doesn't mean it shouldn't work.
>>
>> The reason the thing is hanging is that although we correctly deactivate
>> the interrupt, nothing performs the priority drop. Your write to EOI
>> helps in the sense that it guarantees that both priority drop and
>> deactivate are done with the same operation, but that's not something
>> we'd want to expose.
>>
>> My preferred approach would be to nuke the active priority registers at
>> boot time, as the CPUs come up. I'll try to write something this week.
> 
> I've made a PoC which performs priority drop at boot time as you
> suggested and it works with both GICv2 and GICv3 but I see some
> problem:
> It seems that the only way to drop the priority is to perform write to
> EOI register (the GIC_RPR is RO). According to GIC documentation a
> write to EOI register must correspond to the most recent valid read
> from IAR. The problem is that the interrupt was already acked in the
> 'original' kernel, so reading GICC_IAR in crashdump kernel returns
> spurious interrupt and it seems that there is no way to figure out
> appropriate irqnr for EOI write. Nevertheless I've observed that
> choosing random irqnr for EOI write works fine (maybe because all
> interrupts in Linux uses the same priority?).
> 
> Here is the PoC (not ready for submission only for further
> discussion): https://pastebin.com/gLYNuRiZ
> 
> Looking forward to your feedback.

Well, the feedback is that this patch is really horrible, and choosing a 
random IRQ is at best hilarious. It also doesn't account for multiple 
priorities being active... In short, this is just fundamentally broken.

I gave you a clue about the active priority registers. Why didn't you 
try that?

Anyway, here's something that should fix it.

	M.