Re: [Xen-devel] [PATCH v8 09/13] xen/arm: second irq injection while the first irq is still inflight

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-05-22 at 13:32 +0100, Stefano Stabellini wrote:
> @@ -626,19 +644,36 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>      ASSERT(spin_is_locked(&v->arch.vgic.lock));
>  
>      lr = GICH[GICH_LR + i];
> -    if ( !(lr & (GICH_LR_PENDING|GICH_LR_ACTIVE)) )
> +    irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
> +    p = irq_to_pending(v, irq);
> +    if ( lr & GICH_LR_ACTIVE )
>      {
> +        if ( test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) &&
> +             test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status) )
> +        {
> +            if ( p->desc == NULL )
> +                GICH[GICH_LR + i] = lr | GICH_LR_PENDING;
> +            else
> +                gdprintk(XENLOG_WARNING, "unable to inject hw irq=%d into 
> d%dv%d: already active in LR%d\n",
> +                         irq, v->domain->domain_id, v->vcpu_id, i);

How common is this? Or should it never actually happen in reality?

> +        }
> +    } else if ( lr & GICH_LR_PENDING ) {
> +        int q __attribute__ ((unused)) = 
> test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> +#ifdef GIC_DEBUG
> +        if ( q )

           if ( test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status) ) 
#ifdef GIC_DEBUG
> +            gdprintk(XENLOG_DEBUG, "trying to inject irq=%d into d%dv%d, 
> when it is already pending in LR%d\n",
> +                    irq, v->domain->domain_id, v->vcpu_id, i);
#else
               ; /* Nothing to do */
#endif

would be nicer than attribute unused IMHO.

As it's a XENLOG_DEBUG this wouldn't be all that bad by default BTW,
given that the already active case isn't even conditional.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel