We recently noticed Michael Lotz (mmlr) has been quite busy committing to Haiku lately. We thought an interview would be timely, and thank Michael for helping explain what he's been up to in such great detail! The interview:

#1 - We've noticed a flurry of commits from you recently regarding ACPI and IRQ tables/routing. Could you please explain if this will help close ticket #5, and help Haiku realize proposition #4 from Haiku's 'must have R1 features' poll? Also, perhaps translate into plain English what it is you've done? :)

What I've done is finish implementing IO-APIC support that I started implementing back in 2008. Back then I only implemented programming of the actual IO-APIC controller, but not the required mapping between PCIinterrupt pins and the IO-APIC inputs. While the IO-APIC basically worked since then, it wasn't usable at all because the essential information, i.e. what pins are physically connected to what inputs was simply missing.

To provide a bit more background about interrupts and interrupt controllers in a nutshell: Interrupts are signals that are generated by devices to inform the OS that some event happened (like a key was pressed, data arrived on a network card, a USB transaction completed or similar). It does that by asserting a hardware pin that is connected to an interrupt controller. That controller then checks whether or not the interrupt is enabled or not (whether the OS decided it was interested in that event or not). If it is enabled (or more precisely not masked)it communicates that interrupt further to the CPU by asserting the interrupt pin of the CPU. The CPU is then actually interrupted and leaves whatever task it was currently working on (hence the name) and jumps into a software function that was registered by the OS to handle the event (most often that'd be some code in a driver to actually handle the event). Besides the actual interrupt signal, the interrupt controller also provides the so called interrupt vector, a number to descern the different interrupt sources. Traditionally the keyboard controller would for example use vector 1 to indicate a key press, IDE controllers driving harddisk/CD-ROMs were on vectors (interrupts) 14 and 15 and so on.

Now, to this date computers still provide the very same software interface to the legacy PIC (Programmable Interrupt Controller). Programmable because you could actually enable or disable the lines individually and because you could tell the controller what kind of signal would arrive at a certain line (polarity and trigger). The software interface is still the one of the reference Intel 8259 PIC chip. By now it has been replaced by a virtual interface that actually is implemented into the IO-APIC and local APIC of the CPU, but how it behaves and how it is programmed still is the same as for the legacy PIC. IO-APICs are now a new generation of controller, they are Input/Output Advanced Programmable Interrupt Controllers. These are more flexible, they allow for directing interrupts to CPUs other than the boot CPU in multi processor systems and they allow for more interrupt inputs than the traditional 16 that are present on the legacy PIC. So basically what happens when you enable IO-APICs is that the legacy PIC is disabled and only the newer IO-APIC is used.

So far so good, all of that was already implemented back in 2008. Setting up the IO-APIC and programming it so that it would work. But one problem remained up until the recent changes. To actually make use of the new interrupt inputs the IO-APIC provides, PCI devices (that includes add-in cards as well as chipset devices like on-board USB, audio, graphics, network, etc.) are usually connected to separate IO-APIC inputs and, where possible, connected in a way that as few as possible devices share the same interrupt input. Since on every interrupt, the OS has to run all of the installed interrupt handlers for the given vector to let them check if the interrupt was directed to them, it is obviously an advantage if only few or ideally no interrupts are shared. Now, while these better connections are generally desirable, they bring the need for the OS to know how exactly the PCI devices and the IO-APIC interrupt inputs are connected to each other. If the OS doesn't know that, it can't programm the IO-APIC correctly and it can't tell where an interrupt handler needs to be installed tosuccessfully receive interrupts from a specific device. This knowledge and making use of that knowledge to configure the involved devices as well as communicating this information to device drivers is what was missing from the IO-APIC implementation.

Acquiring that information and putting it to use is now implemented and therefore allows a current Haiku installation to utilize the IO-APIC.

How does this whole mess relate to ticket #5 now? Well, what ticket #5 is about is that on modern systems, the BIOS often decides not to configure PCI interrupt lines (because it assumes that the OS will reconfigure them anyway or assumes the OS will switch to using IO-APICs where such configuration would become meaningless) and consequently leaves that task to the OS. But our PCI bus_manager didn't do that, it didn't configure interrupt lines for devices that weren't configured, rendering those devices unusable under Haiku. This resulted in quite a few tickets of devices not working properly, all essentially boiling down to that missing configuration, hence the large amount of tickets closed as duplicates of #5. When the IO-APIC comes into play now, it technically doesn't fix #5, because the PCI bus_manager still doesn't configure interrupt lines. But by utilizing the IO-APIC, configuration of interrupt lines on the PCI level becomes superflous, because any such configuration always only relates to the legacy PIC setup. That means that as soon as we use the IO-APIC and fully configure the interrupt line values as related to IO-APIC pins, devices that previously weren't configured, now are and become usable.

In that way, using IO-APICs fixes the problems seen due to #5, at least for everyone using a system that has an IO-APIC and provides enough information to actually configure it. Since on systems that don't come with an IO-APIC, the BIOS usually does configure all devices, and on systems where an IO-APIC is available we're going to use it, this defacto fixes #5.