OSDev.org

When setting up the IOAPIC, we have to account for non-identity mappings from IRQ sources to global system interrupts using the interrupt source overrides in the MADT. The common override we need to deal with is when the IRQ source 0 for the PIT is mapped to the global system interrupt 2.

This tells us that the PIT will trigger interrupt 2 instead of 0, but what do we do with interrupt 0 now? Are we safe to simply map the IOAPIC input 2 to interrupt 0? Is interrupt 0 to be used for something else, and if it isn't then what was the purpose of the interrupt source override in the first place?

23scurtu wrote:This tells us that the PIT will trigger interrupt 2 instead of 0, but what do we do with interrupt 0 now?

Configure IOAPIC input 0 according to whatever device is connected. You'll have to refer to ACPI or the MP tables to figure it out. One common configuration has the PIC output routed to IOAPIC input 0, for example, in which case you would probably mask it since you wouldn't be using the PICs. (FreeBSD assumes the hardware is configured this way if the firmware doesn't specify otherwise.)

23scurtu wrote:Are we safe to simply map the IOAPIC input 2 to interrupt 0?

Interrupt 0 is reserved for the #DE exception. You certainly can continue using the same interrupt vectors that you did with the PICs, but keep in mind that the local APIC assigns higher priority to higher interrupt vectors.

23scurtu wrote: This tells us that the PIT will trigger interrupt 2 instead of 0, but what do we do with interrupt 0 now? Are we safe to simply map the IOAPIC input 2 to interrupt 0? Is interrupt 0 to be used for something else, and if it isn't then what was the purpose of the interrupt source override in the first place?

The terminology here is a bit confusing, IOAPIC is like an added layer or a separate front end to receive interrupts.

"PIT will trigger interrupt 2 instead of 0" is more like "PIT is routed to input vector 2 of IOAPIC".

So if you want to receive interrupt from PIT via IOAPIC you can configure IOAPIC to route its input vector 2 to CPU (or LAPIC, the actual receiver AFAIK)'s input vector <whatever> as needed, using IOAPIC's remap registers.

CPU's input vector is the vectors described in IDT (256 in total, lower 32 are exceptions, etc).

As of what to do with input vector 0 of IOAPIC, it depends on what is connected to it and what you want to do with that thing, neither PIT nor CPU (LAPIC)'s input vector 0 is relevant here.

As of what to do with input vector 0 of the CPU, I think you know that the best course of action is to avoid using it as an interrupt vector and let it be handled by an exception handler instead.

xeyes wrote: The terminology here is a bit confusing, IOAPIC is like an added layer or a separate front end to receive interrupts.

"PIT will trigger interrupt 2 instead of 0" is more like "PIT is routed to input vector 2 of IOAPIC".

So if you want to receive interrupt from PIT via IOAPIC you can configure IOAPIC to route its input vector 2 to CPU (or LAPIC, the actual receiver AFAIK)'s input vector <whatever> as needed, using IOAPIC's remap registers.

CPU's input vector is the vectors described in IDT (256 in total, lower 32 are exceptions, etc).

As of what to do with input vector 0 of IOAPIC, it depends on what is connected to it and what you want to do with that thing, neither PIT nor CPU (LAPIC)'s input vector 0 is relevant here.

Okay thanks, I was getting confused with the terminology. Saying that the "PIT is routed to input vector 2 of IOAPIC" makes sense. I guess what I'd like to know is what's routed to the input vector 0 of the IOAPIC, since the ACPI spec says "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources" if not overridden. When you say it depends on what's connected to it, is there a way to figure that out?

xeyes wrote: As of what to do with input vector 0 of the CPU, I think you know that the best course of action is to avoid using it as an interrupt vector and let it be handled by an exception handler instead.

Yeah, definitely shouldn't touch any CPU input vectors under 32. I really should have said CPU input vector 32 instead of 0, since that's where I begin mapping the ISA IRQs.

23scurtu wrote:When you say it depends on what's connected to it, is there a way to figure that out?

Yes. You can use ACPI or the MP tables.