OSDev.org

In the ACPI spec, it says that:

Do I really do this, or just as I remap the PIC to use ISRs 32 onwards, should I actually adjust the global system interrupts (in both overridden and implied entries?) to not overlap with the exceptions?

I feel as this is an obvious yes, so sorry if this is the case, but I thought I'd just check my preconceptions. Thanks!

Hi,



I think you might be confusing "global interrupt numbers" (which are an abstraction) with something that actually exists (interrupt vectors?).

Assume that a (very hypothetical) computer has three IO APICs; where one IO APIC has 12 inputs, another IO APIC has 8 inputs, and another has 16 inputs. For the firmware to say "this device is connected to that input on this IO APIC" (without some kind of standardised numbering system) it'd be messy - the firmware would have to provide something to identify which IO APIC and something else to identify which input. To avoid that ACPI uses a "global interrupt number" scheme where the IO APICs are described in a certain order and then the inputs of all IO APICs are treated as being consecutive. For example, for the hypothetical computer, maybe the IO APIC with 8 inputs is "first" and has global interrupts 0 to 7, the IO APIC with 12 inputs is "second" and has global interrupts 8 to 19, and the IO APIC with 16 inputs is "third" and has global interrupts 20 to 36.

This "global interrupt numbering" scheme is what ACPI uses to describe how legacy interrupts (interrupts that used to be old ISA bus IRQs) are connected to IO APIC inputs. However; rather than describing every legacy interrupt it uses an "assume they're connected the same as they would be for the legacy PIC chips (unless you're told otherwise)" shortcut so that typically the ACPI table only has to describe a few of them.

Note that this is only about how devices are connected to IO APIC inputs (and a few other things, like if they're edge triggered or level triggered, or active high or active low); and has nothing to do with the CPU's interrupt vectors at all (the OS can configure the interrupt vector used by each IO APIC input however it likes).

Of course if you're not using IO APICs and only using the old PIC chips; then you don't care how devices are connected to IO APIC inputs and therefore don't care about ACPI's Interrupt Source Overrides.


Cheers,

Brendan

The ACPI spec means that the I/O APIC can be used to deliver legacy ISA IRQs, that are normally wired through the dual PICs. It says that to use the PIC IRQs with the I/O APIC, you configure GSI 0-15 the same as PIC IRQs 0-15, and the default for this is active-high and edge-triggered. However, if there is an interrupt source override, you apply it instead. An override may specify a GSI different than the PIC IRQ, and it may specify a configuration different than active-high/edge-triggered, in which case you follow the override information.

The next thing, I just want to clarify there is no point of using both the PIC and I/O APIC at the same time because the I/O APIC is capable of delivering PIC interrupts. You will need to configure the PIC even when using the I/O APIC however, because theoretically the PIC can fire spurious IRQs even when it's all masked, and thus you need to handle those spurious IRQs, so the CPU doesn't think exceptions are happening. The approach I use in my OS is that I map the PIC to interrupts 0x20-0x2F and mask everything except the cascade, thus I can handle spurious IRQs from the master and the slave PIC. I then map each I/O APIC input to interrupts 0x30 and until as many I/O APIC inputs are present.

Ah, right, thanks for the clarification Brendan. I have realised that that document is also targeted at hardware designers, and misunderstood that it was something I had to do. So just for final clarification, when it says "IRQ" here in this article on the wiki, does it really index the 'global interrupt numbers'? QEMU has only the one IOAPIC, with 24 pins afaict, so do the ISA IRQs map to pins 0 through 15 on this IOAPIC?


Yep, I promise I've read the docs (even if it doesn't seem like it ). I'm only trying to use the IOAPIC, but also handle ISA IRQs through it as I'm not very close to implementing PCI or USB drivers or anything yet. Atm, I'm remapping the i8259 PICs to 0x20-0x2F and masking everything (why shouldn't I mask the cascade as well, does it prevent the spurious interrupts from being handled correctly?).

Last question, you say you map all of the IOAPIC inputs to 0x30 onwards - if I only want to handle certain ISA interrupts can I just leave all the others masked in the APIC, or is it good practice to unmask and assign them all to a interrupt vector?

No. It means the specific IRQ line on that specific I/O APIC. Like Brendan explained the GSI system, if you have two I/O APICs, for example, the first with 20 IRQ lines, and the second with 10 IRQ lines. GSI 2 would correspond to IRQ 2 on the first I/O APIC, while GSI 20 would correspond to IRQ 0 on the second I/O APIC, and GSI 26 would correspond to IRQ 6 on the second I/O APIC.


Yes.


In theory, masking the cascade prevents all slave PIC IRQs from happening, and the slave PIC IRQ is connected to the master, which is why you need to EOI the master in the slave's spurious IRQ handler. So personally, I don't think the cascade should be masked, although there probably aren't any real harms from doing it.


Just like the PIC, you leave all IRQs masked, and when you initialize a device driver that uses an IRQ, you unmask that device's IRQ line.

Yeah, sorry that's what I was trying to get at. Thank you both for your explanations, I have now been able to correctly receive some interrupts from the IOAPIC!