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

[Andrii Anisov <andrii.anisov@gmail.com>]

On 23.11.18 14:18, Andre Przywara wrote:
> Fundamentally there is a semantic difference between edge and level
> triggered IRQs:
> When the guest has handled an *edge* IRQ (EOIed so the LR's state goes
> to 0), this is done and dusted, and Xen doesn't need to care
> about this anymore until the next IRQ occurs.
> 
> For level triggered IRQs, even though the guest has handled it, we need
> to resample the (potentially virtual) IRQ line, as it may come up or
> down at the *device*'s discretion: the interrupt reason might have gone
> away (GPIO condition no longer true), even before we were able to
> inject it, or there might be another interrupt reason not yet handled
> (incoming serial character while serving a transmit interrupt). Also
> typically it's up to the interrupt handler to confirm handling the
> interrupt, either explicitly by clearing an interrupt bit in some
> status register or implicitly, for instance by draining a FIFO, say on
> a serial device. So even though from the (V)GIC's point of view the
> interrupt has been processed (EOIed), it might still be pending.
> 
> My intimate "old Xen VGIC" knowledge has been swapped out from my brain
> meanwhile, but IIRC Xen treats every IRQ as if it would be an edge IRQ.
> Which works if the guest's interrupt handler behaves correctly. Most
> IRQ handlers have a loop to iterate over all possible interrupt
> reasons and process them, so the line goes indeed down before they EOI
> the IRQ.
Thank you for the explanation. I'll read it carefully.


-- 
Sincerely,
Andrii Anisov.

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