aboutsummaryrefslogtreecommitdiffstats
path: root/xen/arch/x86/irq.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2012-05-15 09:18:33 +0200
committerJan Beulich <jbeulich@suse.com>2012-05-15 09:18:33 +0200
commitf67f17b13bcf1122f1e95aaf5891236b57fdc527 (patch)
tree549b2d14590228759ee73044804f8563194e3681 /xen/arch/x86/irq.c
parent85c4d8a2ab3904353d88a4f79de164b7fda79adb (diff)
downloadxen-f67f17b13bcf1122f1e95aaf5891236b57fdc527.tar.gz
xen-f67f17b13bcf1122f1e95aaf5891236b57fdc527.tar.bz2
xen-f67f17b13bcf1122f1e95aaf5891236b57fdc527.zip
x86: adjust handling of interrupts coming in via legacy vectors
The debugging code added in c/s 24707:96987c324a4f was hit a (small) number of times (one report being http://lists.xen.org/archives/html/xen-devel/2012-05/msg00332.html), apparently always with a vector within the legacy range. Obviously, besides legacy vectors not normally expected to be in use on systems with IO-APIC(s), they should never make it to the IRQ migration logic. This wasn't being prevented so far: Since we don't have a one-to-one mapping between vectors and IRQs - legacy IRQs may have two vectors associated with them (one used in either 8259A, the other used in one of the IO-APICs) -, vector-to-IRQ translations for legacy vectors (as used in do_IRQ()) would yield a valid IRQ number despite the IRQ really being handled via an IO-APIC. This gets changed here - disable_8259A_irq() zaps the legacy vector-to- IRQ mapping, and enable_8259A_irq(), should it ever be called for a particular interrupts, restores it. The spurious interrupt logic in do_IRQ() gets adjusted too: Interrupts coming in via legacy vectors presumably didn't get reported through the IO-APIC/LAPIC pair (as we never program these vectors into any RTE or LVT). Call ack_APIC_irq() only when the LAPIC's ISR bit says an interrupt is pending at the given vector. Plus, a new function (pointer) bogus_8259A_irq() gets used to have the 8259A driver take care of the bogus interrupt (as outside of automatic EOI mode it may need an EOI to be issued for it to prevent other interrupts legitimately going through the 8259As from getting masked out). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Diffstat (limited to 'xen/arch/x86/irq.c')
-rw-r--r--xen/arch/x86/irq.c14
1 files changed, 11 insertions, 3 deletions
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 2fc676b716..496c8048ae 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -811,9 +811,17 @@ void do_IRQ(struct cpu_user_regs *regs)
if (direct_apic_vector[vector] != NULL) {
(*direct_apic_vector[vector])(regs);
} else {
- ack_APIC_irq();
- printk("%s: %d.%d No irq handler for vector (irq %d)\n",
- __func__, smp_processor_id(), vector, irq);
+ const char *kind = ", LAPIC";
+
+ if ( apic_isr_read(vector) )
+ ack_APIC_irq();
+ else
+ kind = "";
+ if ( vector >= FIRST_LEGACY_VECTOR &&
+ vector <= LAST_LEGACY_VECTOR )
+ bogus_8259A_irq(vector - FIRST_LEGACY_VECTOR);
+ printk("CPU%u: No irq handler for vector %02x (IRQ %d%s)\n",
+ smp_processor_id(), vector, irq, kind);
TRACE_1D(TRC_HW_IRQ_UNMAPPED_VECTOR, vector);
}
goto out_no_unlock;