From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH-4.5 4/4] xen/arm: set GICH_HCR_NPIE if all the LRs are in use Date: Fri, 07 Feb 2014 23:39:21 +0000 Message-ID: <52F56EA9.9020903@linaro.org> References: <1391799378-31664-4-git-send-email-stefano.stabellini@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1391799378-31664-4-git-send-email-stefano.stabellini@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , xen-devel@lists.xensource.com Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 07/02/14 18:56, Stefano Stabellini wrote: > On return to guest, if there are no free LRs and we still have more > interrupt to inject, set GICH_HCR_NPIE so that we are going to receive a > maintenance interrupt when no pending interrupts are present in the LR > registers. > The maintenance interrupt handler won't do anything anymore, but > receiving the interrupt is going to cause gic_inject to be called on > return to guest that is going to clear the old LRs and inject new > interrupts. > > Signed-off-by: Stefano Stabellini > --- > xen/arch/arm/gic.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 87bd5d3..bee2618 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -810,8 +810,14 @@ void gic_inject(void) > gic_restore_pending_irqs(current); > if (!gic_events_need_delivery()) > gic_inject_irq_stop(); > - else > + else { > gic_inject_irq_start(); > + } > + > + if ( !list_empty(¤t->arch.vgic.lr_pending) ) > + GICH[GICH_HCR] = GICH_HCR_EN | GICH_HCR_NPIE; > + else > + GICH[GICH_HCR] = GICH_HCR_EN; Any reason to not move this in the else? BTW, I think we can safely avoid to reinject the IRQ for the event channels if there is pending events. It will also avoid spurious IRQ on some specific case :). -- Julien Grall