Peter Maydell <peter.mayd...@linaro.org> writes:
> On Tue, 23 Nov 2021 at 17:10, Peter Maydell <peter.mayd...@linaro.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... Hmm interesting - does this affect the kvm-unit-tests for GICv3? > > -- PMM -- Alex Bennée
