OSDev.org

I have already start all the processors and I have set PICs to handle IRQs. My question is how I select where to send the IRQs? For example let's say that I want PIT IRQ (IRQ0) to be handled by 1st processor and keyboard (IRQ1) by the second, what I need to do? Also what IOAPIC is doing?

The legacy PIC does not support multiple processors. You'll need the I/O APIC, x2APIC, or other modern hardware interrupt controller. The I/O APIC works with a similar idea to that of the legacy PIC, except that the number of interrupts are variable as the number of I/O APICs themselves are variable, and each interrupt can be delivered to a different local APIC, which in turn delivers each interrupt to a different processor.

To simplify things, if I had multiprocessor support, I'd implement the I/O APIC only and simply leave the PIC disabled from boot time. Even with one processor only, the I/O APIC (most likely) gives you more available interrupts, because most PCs have I/O APICs with 24 interrupt lines, and any PC since the early 2000's has at least one I/O APIC. Using the APIC will also improve performance, because at the end of the interrupt handler, you have to send an EOI. With the legacy PIC, this is done with I/O ports, which means the access has to pass through the system bus, and generally I/O ports are slow. With the I/O APIC (and probably other APICs), the EOI is sent to the local APIC, which is on the same circuit as the CPU and done via memory-mapped I/O, thus not wasting as many CPU cycles as the access doesn't pass through the system bus.

The only case where using the legacy PIC is preferable over the I/O APIC is implementing PCI IRQs, because you'll need a decent ACPI implementation for that.

omarrx024 wrote:The legacy PIC does not support multiple processors. You'll need the I/O APIC, x2APIC, or other modern hardware interrupt controller. The I/O APIC works with a similar idea to that of the legacy PIC, except that the number of interrupts are variable as the number of I/O APICs themselves are variable, and each interrupt can be delivered to a different local APIC, which in turn delivers each interrupt to a different processor.

To simplify things, if I had multiprocessor support, I'd implement the I/O APIC only and simply leave the PIC disabled from boot time. Even with one processor only, the I/O APIC (most likely) gives you more available interrupts, because most PCs have I/O APICs with 24 interrupt lines, and any PC since the early 2000's has at least one I/O APIC. Using the APIC will also improve performance, because at the end of the interrupt handler, you have to send an EOI. With the legacy PIC, this is done with I/O ports, which means the access has to pass through the system bus, and generally I/O ports are slow. With the I/O APIC (and probably other APICs), the EOI is sent to the local APIC, which is on the same circuit as the CPU and done via memory-mapped I/O, thus not wasting as many CPU cycles as the access doesn't pass through the system bus.

The only case where using the legacy PIC is preferable over the I/O APIC is implementing PCI IRQs, because you'll need a decent ACPI implementation for that.

Do you know any good IOAPIC tutorial or I need to read the Intel datasheet?
(Also I didn't believe that exist someone else 15 years old who is writing an OS in pure assembly!)

ARISTOS wrote:(Also I didn't believe that exist someone else 15 years old who is writing an OS in pure assembly!)

Most people choosing to write their OS using pure assembler seem to be fairly young. The older programmers have gained more wisdom.