Re: [Xen-devel] [PATCH v3a 14/39] ARM: new VGIC: Add GICv2 world switch backend

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 03/22/2018 03:12 PM, Andre Przywara wrote:
> Hi,
>
> On 22/03/18 14:06, Julien Grall wrote:
> > Hi Andre,
> >
> > On 03/22/2018 11:56 AM, Andre Przywara wrote:
> > > +        /* The locking order forces us to drop and re-take the locks
> > > here. */
> > > +        if ( irq->hw )
> > > +        {
> > > +            spin_unlock(&irq->irq_lock);
> > > +
> > > +            desc = irq_to_desc(irq->hwintid);
> > > +            spin_lock(&desc->lock);
> > > +            spin_lock(&irq->irq_lock);
> > > +
> > > +            /* This h/w IRQ should still be assigned to the virtual
> > > IRQ. */
> > > +            ASSERT(irq->hw && desc->irq == irq->hwintid);
> > > +
> > > +            have_desc_lock = true;
> > > +        }
> > I am a bit concerned of this dance in fold_lr_state(). This looks
> > awfully complex but I don't have better solution here.
> I agree.
I still have much idea how to solve that nicely. Maybe Stefano has?

Meanwhile, I would be happy to get that in Xen:

Acked-by: Julien Grall <julien.grall@xxxxxxx.

> > I will have a think during the night.
> >
> > However, this is not going to solve the race condition I mentioned
> > between clearing _IRQ_INPROGRESS here and setting _IRQ_INPROGRESS in
> > do_IRQ. This is because you don't know the order they are going to be
> > executed.
> >
> > I wanted to make sure you didn't intend to solve that one. Am I correct?
> This is right, this is orthogonal and not addressed by this patch. I
> have a hunch we need to solve this in irq.c instead.
I guess this should be logged on Jira with the rest of the open items.

> Cheers,
> Andre.
--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel