apic: fix incorrect handling of ExtINT interrupts wrt processor priority
commit5224c88dd3f771702d450780a25f155e0fc8bb2b
authorPaolo Bonzini <pbonzini@redhat.com>
Tue, 11 Nov 2014 12:14:18 +0000 (11 13:14 +0100)
committerPaolo Bonzini <pbonzini@redhat.com>
Mon, 24 Nov 2014 13:37:45 +0000 (24 14:37 +0100)
tree1b0c5806fb6599f184a861598ed057481ee1300f
parent8092cb71322ca488deeb7c750ff8022ffcc2f9a6
apic: fix incorrect handling of ExtINT interrupts wrt processor priority

This fixes another failure with ExtINT, demonstrated by QNX.  The failure
mode is as follows:
- IPI sent to cpu 0 (bit set in APIC irr)
- IPI accepted by cpu 0 (bit cleared in irr, set in isr)
- IPI sent to cpu 0 (bit set in both irr and isr)
- PIC interrupt sent to cpu 0

The PIC interrupt causes CPU_INTERRUPT_HARD to be set, but
apic_irq_pending observes that the highest pending APIC interrupt priority
(the IPI) is the same as the processor priority (since the IPI is still
being handled), so apic_get_interrupt returns a spurious interrupt rather
than the pending PIC interrupt. The result is an endless sequence of
spurious interrupts, since nothing will clear CPU_INTERRUPT_HARD.

Instead, ExtINT interrupts should have ignored the processor priority.
Calling apic_check_pic early in apic_get_interrupt ensures that
apic_deliver_pic_intr is called instead of delivering the spurious
interrupt.  apic_deliver_pic_intr then clears CPU_INTERRUPT_HARD if needed.

Reported-by: Richard Bilson <rbilson@qnx.com>
Tested-by: Richard Bilson <rbilson@qnx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
hw/intc/apic.c