ok, a raised line does not the information how many devices could have raised them, so you have to handle them all to prevent missing one.Yes. For correct handling of shared IRQs, _all_ associate IRQ handlers must have been executed before the EOI can be sent. The reason is this: For level-triggered IRQs, all hardware devices that may have raised the IRQ line must be checked and told to lower it again before sending EOI. Otherwise the IRQ will immediately be triggered again and you end up in an endless loop, bricking your box.
For edge-triggered IRQs, there problem is different. Here the shared IRQ handling algorithm is to consult all handler in a loop until they all reported "not for me" in a row. If you fail to do this, you risk loosing IRQs.
so you should after handling B again have to call all handlers to see if they report all "not for me" ?Consider IRQ source A and B. Now an IRQ is raised by B. First, the handler for A will be called. It return "not for me". Now it happens that A also raised the IRQ right at this time. If you now simply log the IRQ for later handling by B and send the EOI, you take away the chance for handle A to react on the IRQ. At best you create latency, at worst A will never send an IRQ again...
The local APIC queues the fixed interrupts that it accepts in one of two interrupt pending registers: the interrupt request register (IRR) or in-service register (ISR). These two 256-bit read-only registers are shown in Figure 8-20. The 256 bits in these registers represent the 256 possible vectors; vectors 0 through 15 are reserved by the APIC (see also: Section 8.5.2, “Valid Interrupt Vectors”).
The IRR contains the active interrupt requests that have been accepted, but not yet dispatched to the processor for servicing. When the local APIC accepts an interrupt, it sets the bit in the IRR that corresponds the vector of the accepted interrupt. When the processor core is ready to handle the next interrupt, the local APIC clears the highest priority IRR bit that is set and sets the corresponding ISR bit. The vector for the highest priority bit set in the ISR is then dispatched to the processor core for servicing.
While the processor is servicing the highest priority interrupt, the local APIC can send additional fixed interrupts by setting bits in the IRR. When the interrupt service routine issues a write to the EOI register (see Section 8.8.5, “Signaling Interrupt Servicing Completion”), the local APIC responds by clearing the highest priority ISR bit that is set. It then repeats the process of clearing the highest priority bit in the IRR and setting the corresponding bit in the ISR. The processor core then begins executing the service routing for the highest priority bit set in the ISR.
If more than one interrupt is generated with the same vector number, the local APIC can set the bit for the vector both in the IRR and the ISR. This means that for the Pentium 4 and Intel Xeon processors, the IRR and ISR can queue two interrupts for each interrupt vector: one in the IRR and one in the ISR. Any additional interrupts issued for the same interrupt vector are collapsed into the single bit in the IRR.
For the P6 family and Pentium processors, the IRR and ISR registers can queue no more than two interrupts per priority level, and will reject other interrupts that are received within the same priority level.
If the local APIC receives an interrupt with a priority higher than that of the interrupt currently in serviced, and interrupts are enabled in the processor core, the local APIC dispatches the higher priority interrupt to the processor immediately (without waiting for a write to the EOI register). The currently executing interrupt handler is then interrupted so the higher-priority interrupt can be handled. When the handling of the higher-priority interrupt has been completed, the servicing of the interrupted interrupt is resumed.