On Tue, 23 Nov 2021 at 19:22, Shashi Mallela wrote:
>
> 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()
n next irq trigger from source).Is this the behaviour expected? ThanksShashi Sent from Mail for Windows From: Peter MaydellSent: November 23, 2021 12:46 PMTo: qemu-...@nongnu.org; qemu-devel@nongnu.orgCc: Alex Bennée; Shashi MallelaSubject: Re: [for-6.2] hw/intc/arm_gicv3: Update cached state
Peter Maydell writes:
> On Tue, 23 Nov 2021 at 17:10, Peter Maydell 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
>>
On 11/23/21 6:10 PM, Peter Maydell 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
On Tue, 23 Nov 2021 at 17:10, Peter Maydell 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
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