Re: [PATCH] hw/intc/arm_gicv3_cpuif: Make GIC maintenance interrupts work

[Marc Zyngier]

Hi Peter,

On 2020-10-09 16:39, Peter Maydell wrote:
> In gicv3_init_cpuif() we copy the ARMCPU gicv3_maintenance_interrupt
> into the GICv3CPUState struct's maintenance_irq field.  This will
> only work if the board happens to have already wired up the CPU
> maintenance IRQ before the GIC was realized.  Unfortunately this is
> not the case for the 'virt' board, and so the value that gets copied
> is NULL (since a qemu_irq is really a pointer to an IRQState struct
> under the hood).  The effect is that the CPU interface code never
> actually raises the maintenance interrupt line.
>
> Instead, since the GICv3CPUState has a pointer to the CPUState, make
> the dereference at the point where we want to raise the interrupt, to
> avoid an implicit requirement on board code to wire things up in a
> particular order.
>
> Reported-by: Jose Martins <josemartins90@gmail.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>
> QEMU's implementation here is a bit odd because we've put all the
> logic into the "GIC" device where in real hardware it's split between
> a GIC device and the CPU interface part in the CPU.  If we had
> arranged it in that way then we wouldn't have this odd bit of code
> where the GIC device needs to raise an IRQ line that belongs to the
> CPU.
>
> Not sure why we've never noticed this bug previously with KVM as a
> guest, you'd think we'd have spotted "maintenance interrupts just
> don't work"...

That's because the maintenance interrupt is only used in KVM to trigger
an exit if nothing else causes one, and we end-up suppressing the cause
of the maintenance interrupt (by turning the VGIC off) before actually
coming to a point where we'd handle it.

The lack of MI would at worse delay the injection of new virtual 
interrupts,
not something you'd notice unless you start looking very closely at the
delivery latency.

Thanks,

        M.
--
Jazz is not dead. It just smells funny...