Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Julien Grall <julien.grall@xxxxxxx>]

Hi Andrii,

On 03/12/2018 12:08, Andrii Anisov wrote:
> On 27.11.18 17:13, Julien Grall wrote:
> > The steps for Xen IRQ is roughly:
> >      -> read_irq
> >      -> local_irq_enable
> >      -> do_IRQ
> >         -> local_irq_enable (via spin_unlock_irq)
> >         -> call handlers
> >         -> local_irq_disable (via spin_lock_irq)
> >         -> EOI
> >         -> DIR
> >      -> local_irq_disable
> >
> > The steps of for Guest IRQ is roughly:
> >      -> read_irq
> >      -> local_irq_enable
> >      -> do_IRQ
> >          -> EOI
> So here we might have lower priority interrupt fired, getting us back to 
> `hyp_irq()` to run `do_trap_irq()` again.
> >          -> vgic_inject_irq
> >              -> local_irq_disable  (via spin_lock_irqsave)
> >              -> local_irq_enable   (via spin_lock_irqrestore)
> >      -> local_irq_disable
> >
> > All vgic_inject_irq is pretty much running with interrupts disabled. The Xen 
> > IRQ path seem to continue pointless enable/disable.
> > So I think the following steps should suit you.
> Well, do you state they do not suit mainline?
No. I meant that I would be happy with that and I think should also suit you.

> > Xen IRQ:
> >      -> read_irq
> >      -> do_IRQ
> >          -> local_irq_enable (via spin_unlock_irq)
> I suppose, isb() should be moved here from `do_trap_irq()` as well
There are no isb() in do_trap_irq(). So did you mean gic_interrupt()?

But then, I am not sure why you want to avoid the isb() in the guest path.

Cheers,

--
Julien Grall

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