Hello everyone,
I recently started making some experiments on enabling SMP support in my kernel. I can successfully boot all APs. Now I have some thoughts about interrupt handling which results in some questions.
1. Do I need to go IOAPIC or I can do with the old PIC? I want to get all interrupts on the BSP only.
2. Do I have only one PIC on the board or each core has one? I guess it is only one and is connected to the BSP.
3. Does a signal over the PIC send an interrupt to all CPUs or only the BSP?
4. What do I do if no IOAPIC is present? Use PIC?
Regards,
Martin
IOAPIC vs. PIC
-
AndrewBuckley
- Member
- Posts: 95
- Joined: Thu Jan 29, 2009 9:13 am
Re: IOAPIC vs. PIC
Rookie Disclaimer!
The PIC in modern x86 processors is emulated. you can use it up until you start using multiple processors. This is where my lanturn flickers out, but I think you will need to have the IOAPIC setup before you can use SMP.
The PIC in modern x86 processors is emulated. you can use it up until you start using multiple processors. This is where my lanturn flickers out, but I think you will need to have the IOAPIC setup before you can use SMP.
-
gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: IOAPIC vs. PIC
Yo:
2. An IRQ controller takes IRQ pin inputs from multiple devices on the chipset and multiplexes and prioritizes them before they reach the CPU. The CPU does not have an IRQ controller, and it simply receives interrupts from the IRQ controller. There may be one or more IRQ controllers on a board; PCs have the i8259s in tandem, and/or the IO-APICs. The x86 multiprocessor specification requires that an MP capable logical CPU should have a Local APIC unit. The Local APIC unit is not an IRQ controller -- only the i8259s and the IO-APIC units are IRQ controllers. So the answer is that each logical CPU (not each core) has a Local APIC unit, and these Local APIC units intercept IRQ messages from the IRQ controllers on the motherboard.
3. The i8259 IRQ controller does not have the bus logic required for it to address or target specific CPUs. It is connected directly to a single processor, and cannot arbitrate messages to multiple CPUs It is impossible for the i8259 to send interrupts to any CPU other than the one it is wired to.
4. You've said that you don't want to get IRQs on any CPU other than the BSP, so you technically don't need to worry about the IO-APICs. If you want to make doubly sure, you may detect the presence of any IO-APIC and explicitly mask off all of its pins, though that shouldn't be necessary theoretically since the "boot state" of the IO-APICs is defined to have all of the pins masked. My answers will be pretty different if you decide not to limit yourself to using only the BSP for IRQs though
--Peace out,
gravaera
Not necessarily: you may leave the IO-APIC in virtual wire mode and just have all IRQs sent to the BSP; same with the i8259 PICsMerlin wrote:...you will need to have the IOAPIC setup before you can use SMP.
1. If your stated aim is to minimize your workload and only have to handle IRQ routing to a single processor, then yes, the shortest answer is that you can leave the chipset in "legacy" mode and use the i8259s. It is theoretically doable, but since AFAIK no major kernels du jour do this, chipsets may not be expecting it, and may not handle it properly, much like "mixed mode".itportal wrote:...
1. Do I need to go IOAPIC or I can do with the old PIC? I want to get all interrupts on the BSP only.
2. Do I have only one PIC on the board or each core has one? I guess it is only one and is connected to the BSP.
3. Does a signal over the PIC send an interrupt to all CPUs or only the BSP?
4. What do I do if no IOAPIC is present? Use PIC?
2. An IRQ controller takes IRQ pin inputs from multiple devices on the chipset and multiplexes and prioritizes them before they reach the CPU. The CPU does not have an IRQ controller, and it simply receives interrupts from the IRQ controller. There may be one or more IRQ controllers on a board; PCs have the i8259s in tandem, and/or the IO-APICs. The x86 multiprocessor specification requires that an MP capable logical CPU should have a Local APIC unit. The Local APIC unit is not an IRQ controller -- only the i8259s and the IO-APIC units are IRQ controllers. So the answer is that each logical CPU (not each core) has a Local APIC unit, and these Local APIC units intercept IRQ messages from the IRQ controllers on the motherboard.
3. The i8259 IRQ controller does not have the bus logic required for it to address or target specific CPUs. It is connected directly to a single processor, and cannot arbitrate messages to multiple CPUs
It is impossible for the i8259 to send interrupts to any CPU other than the one it is wired to.4. You've said that you don't want to get IRQs on any CPU other than the BSP, so you technically don't need to worry about the IO-APICs. If you want to make doubly sure, you may detect the presence of any IO-APIC and explicitly mask off all of its pins, though that shouldn't be necessary theoretically since the "boot state" of the IO-APICs is defined to have all of the pins masked. My answers will be pretty different if you decide not to limit yourself to using only the BSP for IRQs though
--Peace out,
gravaera
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
-
Owen
- Member
- Posts: 1700
- Joined: Fri Jun 13, 2008 3:21 pm
- Location: Cambridge, United Kingdom
- Contact:
Re: IOAPIC vs. PIC
The PIC could theoretically be wired to one, all or some of the CPUs in your system; be very careful with the IRQ routing if you want to use it in SMP.
In practice, this means understanding the local APIC and IO APIC routing, and ACPI tables sufficiently well that you're pretty much just best off using the IO APIC(s)
In practice, this means understanding the local APIC and IO APIC routing, and ACPI tables sufficiently well that you're pretty much just best off using the IO APIC(s)
Re: IOAPIC vs. PIC
The major reason why to use the IO-APIC when present is that it has more channels, and thus it is possible that some devices have no PIC routing at all, or has a lot more IRQ sharing. If you have no IRQ, or a highly shared IRQ, it means poorer interrupt performance or the meed to use timers instead of IRQs, which wastes CPU cycles.
Re: IOAPIC vs. PIC
Thank you for your answers. I think I will use the I/O APIC, if present.