@@ -571,7 +571,10 @@ int apic_get_interrupt(DeviceState *dev)
apic_sync_vapic(s, SYNC_FROM_VAPIC);
intno = apic_irq_pending(s);
- if (intno == 0) {
+ /* if there is an interrupt from the 8259, let the caller handle
+ * that first since ExtINT interrupts ignore the priority.
+ */
+ if (intno == 0 || apic_check_pic(s)) {
apic_sync_vapic(s, SYNC_TO_VAPIC);
return -1;
} else if (intno < 0) {
@@ -582,9 +585,6 @@ int apic_get_interrupt(DeviceState *dev)
apic_set_bit(s->isr, intno);
apic_sync_vapic(s, SYNC_TO_VAPIC);
- /* re-inject if there is still a pending PIC interrupt */
- apic_check_pic(s);
-
apic_update_irq(s);
return intno;
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> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- hw/intc/apic.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)