PIC spurious interrupts and I/O APIC

[bluecode]

hi,

As I found out PIC spurious interrupts also occur when all irqs in the PIC are masked. So my question is whether they are also signaled when I am in I/O APIC mode, because the only things required to go there is mask all irqs in the PIC (and possibly write to the ICMR). The problem is, if this is not sufficient, then I would have to disable the interrupt lines the PIC is connected to, which could be an ExtInt in the I/O APIC or a LINT0/1 of a Local APIC, right?

Thanks in advance!

[Brendan]

Hi,

As I found out PIC spurious interrupts also occur when all irqs in the PIC are masked.

Spurious interrupts are typically used to resolve race conditions in hardware. For example, if your code disables interrupts in the CPU (CLI instruction), then an IRQ occurs, then the PIC tells the CPU an IRQ occured, then your code masks the IRQ in the PIC, then your code enables interrupts in the CPU (STI instruction), then the CPU asks the PIC to send an interrupt vector, then the PIC doesn't know what to send because the IRQ is now masked so it sends a spurious interrupt to keep the CPU happy.

To prevent these race conditions you'd need to do things in a different order - leave interrupts enabled in the CPU, then mask all IRQs in the PIC, then have a small delay to let any pending IRQs be handled, then disable interrupts in the CPU if you can think of a reason to bother.

I have heard rumours that noisy interrupt lines can also cause spurious interrupts, but I've never seen it happen in practice (and can't confirm or deny the rumour)...

So my question is whether they are also signaled when I am in I/O APIC mode, because the only things required to go there is mask all irqs in the PIC (and possibly write to the ICMR).

The problem is, if this is not sufficient, then I would have to disable the interrupt lines the PIC is connected to, which could be an ExtInt in the I/O APIC or a LINT0/1 of a Local APIC, right?

Disabling the ExtINT entries (in the I/O APIC and/or local APICs) should work in theory. For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...


Cheers,

Brendan

[bluecode]

Thanks for clearing up the spurious interrupt thing

For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...

Do they have the same interrupt vector in APIC mode as without all the APIC foo, e.g. if I remapped the PIC to 0x20 and 0x28, will the spurious interrupts still be 0x27 and 0x2F in APIC mode?

Another not so related question: How do you handle bochs/qemu PCI interrupts? Because they are mapped to the ISA interrupts (edge-triggered vs. level-triggered). Are the PCI I/O Interrupt Assignments supposed to be like an override of what's in the PCI config space in the Interrupt field? Does the interrupt line field (INTA, INTB, ...) in the PCI config space matter at all?

Thanks in advance!

[Brendan]

Hi,

For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...

Do they have the same interrupt vector in APIC mode as without all the APIC foo, e.g. if I remapped the PIC to 0x20 and 0x28, will the spurious interrupts still be 0x27 and 0x2F in APIC mode?

Yes.

Another not so related question: How do you handle bochs/qemu PCI interrupts? Because they are mapped to the ISA interrupts (edge-triggered vs. level-triggered). Are the PCI I/O Interrupt Assignments supposed to be like an override of what's in the PCI config space in the Interrupt field? Does the interrupt line field (INTA, INTB, ...) in the PCI config space matter at all?

The interrupt pin field in PCI config space is hardwired, and indicates which interrupt line the PCI device/function uses (A, B, C or D). This is mostly meaningless, as you don't know how the interrupt lines at the card (or at the PCI slot) are connected to interrupt lines at the PCI host controller or how they're routed from the PCI host controller to the PIC chips or I/O APICs.

During boot the BIOS looks at the interrupt pin field and (using motherboard specific knowledge) sets the interrupt line field, which is (from the PCI device's point of view) just a read/write field that is unused by the hardware (and could be set to anything without making any difference). The BIOS sets the interrupt line field to the PIC input number that the PCI IRQ happens to be routed to during boot, so that an OS (that doesn't use APICs) can find out which PIC IRQ each device/function is using.

For PCI devices/functions, the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables are used to find out which I/O APIC input each PCI device/function uses.

For Bochs (and any rare and obsolete real computers that have "Pentium era" I/O APIC IRQ handling), the "I/O Interrupt Assignment Entries" (used for I/O APIC inputs) will probably match the values in the interrupt line field in PCI configuration space (used for PIC inputs) because the PICs and the I/O APIC will probably be wired identically.

For modern computers the PICs and the I/O APIC won't be wired identically - the IRQs connected to the APICs will be connected to different inputs (e.g. input 16 to input 20) and won't be connected to the I/O APIC via. the ELCR or PCI IRQ router, so the "I/O Interrupt Assignment Entries" (used for I/O APIC inputs) probably won't match the values in the interrupt line field in PCI configuration space (used for PIC inputs).

Basically, for the rare and obsolete "Pentium era" I/O APIC IRQ handling (used by Bochs and Qemu) I program the I/O APIC according to how the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables tell me to program them; and for modern computers I program the I/O APIC according to how the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables tell me to program them...

This makes it fairly simple - it's just a pity it all turns into an over-complicated puddle of hot sticky vomit once you try to use ACPI...


Cheers,

Brendan