This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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