|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |