[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [for-6.2] hw/intc/arm_gicv3: Update cached state after acknowledging
Re: [for-6.2] hw/intc/arm_gicv3: Update cached state after acknowledging LPI
Tue, 23 Nov 2021 17:46:27 +0000
On Tue, 23 Nov 2021 at 17:10, Peter Maydell <firstname.lastname@example.org> wrote:
> In gicv3_redist_lpi_pending() we update cs->hpplpi to indicate the
> new highest priority pending LPI after changing the requested LPI
> pending bit. However the overall highest priority pending interrupt
> information won't be updated unless we call gicv3_redist_update().
> We do that from the callsite in gicv3-redist_process_lpi(), but not
> from the callsite in icc_activate_irq(). The effect is that when the
> guest acknowledges an LPI by reading ICC_IAR1_EL1, we mark it as not
> pending in the data structure but still leave it in cs->hppi so will
> offer it to the guest again.
> The effect is that if we are using an emulated GICv3 and ITS and
> using devices which use LPIs (ie PCI devices) then Linux will
> complain "irq 54: nobody cared" and then hang (probably because the
> stale bogus interrupt info meant we never tried to deliver some other
> real interrupt).
Hmm; this is definitely a bug, but maybe it's not the cause of
the symptoms listed above -- I've just seen them again even
with this fix. I'll keep digging...