[Xen-devel] Re: [PATCH][FIX] Possible fix for spurious interrupts

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 20 Apr 2006, at 09:53, Jan Beulich wrote:

> Hmm, I read that mail, but it seemed to indicate that this would 
> affect only a single line. We had been seeing this on
> multiple lines, however. Also, to me lines 16 and above aren't really 
> 'legacy', so the implication might rather be for
> routing in systems with multiple IO-APICs where older software only 
> finds one. As this would then seem to be
> deterministic, the question would be if there is a way to know which 
> IO-APIC triggers which line (this must be possible,
> or else the 'older software' wouldn't be able to know where the 
> interrupts arrive at the first IO-APIC), and use this
> knowledge, or at least restrict the fix currently in use to all but 
> the first ('legacy') IO-APIC (which should improve
> things namely on single-IO-APIC systems).
I am certain that we have been hitting *at least* this issue. Maybe 
there are others, but I'll be surprised if you continue to hit spurious 
interrupt problems with the workaround in place.
Here is my understanding of this boot interrupt mode and why it affects 
us:
 1. PCI-X bridge interrupt inputs are not configurable directly as 
inputs to the 859 PICs (I/O hubs usually allow that for normal PCI 
interrupt inputs)
 2. So any OS not aware of APICs cannot get at those interrupt lines 
unless a hardware hack is introduced
 3. Intel introduce a 'boot interrupt' line by wire-ORing together all 
the interrupt inputs to an IO-APIC that services PCI-X interrupts, and 
forwarding the resulting 'boot interrupt' line to some INTx line or pin 
on the 8259 (note: I'm unsure where this boot interrupt actually gets 
wired to).
 4. I guess that if you have more than one PCI-X IO-APIC, they may 
forward their boot interrupts to different INTx lines and so appear as 
different interrupts to the OS.
What I'm not sure about:
 1. How are legacy OSes supposed to detect these devices and know that 
the interrupt lines are routed to a particular 8259 pin?
 2. Why does this alias with an IOAPIC0 input? Perhaps the boot 
interrupt fires on an INTx line that is then routed to both 8259 and 
IOAPIC0 -- so you get it on whichever happens to be enabled, and it 
ends up looking like an interrupt from whichever device is bound to 
that INTx line. Or perhaps the 8259 output is wired into IOAPIC0. I'm 
not sure.
The workaround shouldn't hurt performance, assuming interrupts are 
usually delivered to the CPU on which they are serviced. I'm also 
confident of its correctness, assuming driver domains service their 
interrupts in a reasonably timely fashion (a shame to have to make that 
assumption, but once we have MSI support we can recommend people use 
that if they want better driver-domain isolation).
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel