Hi,
Love4Boobies wrote:Why is there a need to have interrupt handling support on both the processor and another chip? I'm talking about the local APIC vs 8259B, for instance.
Mostly it's for backward compatibility.
Originally there was only the PIC chips, so people wrote software that assumed the PIC chips were there. However, the PIC chips weren't designed to handle multi-CPU systems; so for multi-CPU systems hardware designers needed something else - they invented local APICs and I/O APICs to replace the PIC chips. That meant that older software that assumes PIC chips are present wouldn't run, unless the multi-CPU computers had both PIC chips and APICs (where the PIC chips were still used, until software capable of using multiple CPUs disabled the PIC chips and enabled the APICs).
Note: The I/O APIC replaces the PIC chip and deals with IRQ signals from devices. The local APIC deals with interrupts (not IRQs), including interrupt requests sent from I/O APICs in response to IRQs.
Of course PIC chips only support 15 IRQs (it would've been possible to add more slave PICs, but that would've broken backward compatibility a little) and I/O APICs support more IRQs (a chipset/motherboard can support any number of IRQs with no backward compatibility problems). Also the local APIC does provide some other nice features. Because of these advantages, APICs are very useful on single-CPU systems too.
Love4Boobies wrote:What advantages/disadvantages does each have and what can they be used for?
I/O APICs let you send interrupts to a specific CPU, to all CPUs, or to a group of CPUs (including "send to lowest priority" mode, where an interrupt is sent to the CPU that is doing the least important work so that CPUs doing more important work don't get interrupted). They also support more IRQs (e.g. less PCI IRQ sharing), have better IRQ priorities and support different interrupt types (e.g. instead of generating a normal interrupt, you could configure the I/O APIC so that an IRQ triggers an NMI or something).
Local APICs have a high precision timer that runs at CPU bus speed. For example, for a CPU with a 800 MHz bus the local APICs timer has 1.25 ns precision (the PIT has about 838 ns precision). Because (for Pentium and later CPUs) the local APIC is built into the CPU it's a lot faster to access it (no need to talk to a slow PIT chip on a slow bus, with lots of other stuff between the CPU and the timer). Also, it's impossible to support the CPUs performance monitoring counters properly without using the "performance monitoring interrupt" that's built into the CPU's local APIC; and it's impossible to properly detect when the CPU changes speed (due to thermal throttling) without using the "thermal monitor interrupt" that's built into the CPU's local APIC; and it's impossible to synchronize CPUs properly (in multi-CPU systems) without using "InterProcessor Interrupts" (which are interrupts sent by software from one CPU to another, using the local APIC).
The only disadvantage for APICs is that they're harder for an OS developer to support - they're technically better than PICs in every possible way.
Love4Boobies wrote:Are they usually both used at the same time?
Mostly, no. An OS that's capable of using the APICs will normally disable the PICs completely and use the APICs instead. It is possible to use both at the same time, but it's almost impossible to think of a sane reason why an OS would want to.
Love4Boobies wrote:How can I mask only certain interrupts using the local APIC?
For normal IRQs you need to mask them in the I/O APIC (not in the local APIC). However, it's possible to set the local APIC's "task priority register" so that the I/O APIC/s won't send any IRQs to the CPU (because none of the IRQs have high enough priority). For the local APIC timer interrupt, the performance monitoring interrupt and the thermal monitoring interrupt; there's flags in the corresponding local APIC registers for enabling/disabling them. IPIs (InterProcessor Interrupts) can't be disabled (if you don't want them, then don't send them).
Cheers,
Brendan