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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
