Hi,
bluecode wrote:
Brendan wrote:
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.
bluecode wrote:
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