[Top][All Lists]

[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

From: Shashi Mallela
Subject: RE: [for-6.2] hw/intc/arm_gicv3: Update cached state after acknowledging LPI
Date: Tue, 23 Nov 2021 14:22:23 -0500

Since LPIs do not have an active or active and pending state,the current implementation only clears the LPI pending state from the pending table once ICC_IAR1_EL1 acknowledges the interrupt.

But, as part of gicv3_lpi_pending() processing, cs->hpplpi is updated with the next best priotiy lpi (only if the current acknowledged irq was best priority irq).

By calling gicv3_redist_update() in icc_activate_irq(), we are re-initiating high priority irqs scan in redistributor and if applicable trigger of next best pending lpi from the latest cs->hpplpi info(which otherwise would have happened on next irq trigger from source).Is this the behaviour expected?





Sent from Mail for Windows


From: Peter Maydell
Sent: November 23, 2021 12:46 PM
To: qemu-arm@nongnu.org; qemu-devel@nongnu.org
Cc: Alex Bennée; Shashi Mallela
Subject: Re: [for-6.2] hw/intc/arm_gicv3: Update cached state after acknowledging LPI


On Tue, 23 Nov 2021 at 17:10, Peter Maydell <peter.maydell@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...


-- PMM


reply via email to

[Prev in Thread] Current Thread [Next in Thread]