OSDev.org

Hi,

Let's say I have enabled interrupts but has not yet installed an interrupt handler for anything except something very basic that will just ignore every incoming interrupt and return back to the previous state. During this time the PIT or the keyboard could fire an interrupt (depending on what the bootloader left their state in) but because no interrupt handler is installed for them yet there is no code that will send the EOI to the APIC and therefor no new interrupts will be sent from the APIC again. So far so good.

Later on I add an interrupt handler for the APIC. As part of the initialization, what is the recommended way to reset the APIC so interrupts can start firing again? I tried to send the EOIs to the primary and secondary APIC and that solved the problem in an emulator but not on real hardware. What if I first turn the APIC off and then on again, will that reset it? I suspect there is a better way. Also, I'd like to add that I do not want to disable the APIC before enabling interrupts because this code knows nothing about the APIC and would be considered a hackish workaround. Any ideas?

What if the dummy interrupt handler you install in the early boot stages properly sends an EOI and then returns, without doing anything else?

Thanks for the reply but I'm trying to avoid that situation because that code should know nothing about the APIC. It has no clue wether the interrupt came from the APIC or the CPU or any other device for that matter. Hell, there might not even exist an APIC in the system at all.

So... If the interrupt handler should do absolutely nothing... Why is the interrupt enabled / unmasked at all?

Interrupts are enabled in order to do syscalls for which there exist handlers. From userspace i load the apic module which in turn will register handlers for itself but the time between entering userspace and loading the apic module is where these interrupts could occur. Thats why i need to clear them during module initialization.

Many interrupts (especially PCI interrupts) cannot be cleared with EOI alone, so that is not an option. The only option I can suggest is either not to enable interrupts, or to keep interrupts that have no handler from firing by masking them in the APIC/PIC. In fact, the default initialization of the APIC/PIC should be to have all interrupts masked (or to have a default handler that detects the interrupt and then masks it). It is then up to code that handle the devices to specifically define the handler and unmask the APIC/PIC (in that order).

Hi,



During boot; the "most correct" sequence (assuming PC BIOS) is:

• mask all IRQs in the PIC
• with interrupts enabled (STI) do a dew dummy instructions (e.g. NOP, NOP) to make sure the BIOS has a chance to handle any IRQs that were received before you masked them. Failure to do this can cause "PIC jam" later.
• Don't bother doing CLI - the only IRQs that are possible now are IPIs that you send yourself and NMIs.
• Set the IDT limit to zero. NMIs normally indicate serious hardware failures and therefore shouldn't be ignored; but your boot code isn't prepared to properly handle an NMI at this stage (especially if an NMI occurs while you're switching CPU modes). Simple solution is to make sure NMIs cause a reset/triple fault.
• Switch to protected mode (and/or long mode)
• Install a suitable IDT (including NMI handler)
• Disable PCI devices (except bridges, the "PCI to LPC brige" and the video card if you're using it) by writing 0xFFFF to their Device Control register in PCI configuration space. This makes sure that a device can't generate a level triggered interrupt before you've installed a suitable device driver; even if the IRQ is shared by several devices and that IRQ is unmasked in the PIC or IO APIC. If a device's IRQ is unmasked in the PIC or IO APIC and a "device without a driver" does generate a (level triggered) interrupt, you end up with an "IRQ flood" (e.g. where you get an interrupt, send an EOI, get the same interrupt again, send an EOI, ...).
• Intialise device drivers. For each device you would:
  • If the device is PCI, enable the device by writing 0x0000 to the Device Control register in PCI configuration space.
  • Start initialising the device (including any reset, and including performing any self tests it has)
  • Install the device driver's interrupt handler/s (if any)
  • Make sure the interrupt/s are unmasked in the PIC or IO APIC (if any)
  • Finish initialising the device

Note that you should be able to bring a device online and take a device offline. For example, if a PCI device's driver crashes (possibly while the device is in the middle of a bus mastering transfer with all sorts of interrupts about to happen) then you'd want to write 0xFFFF to the device's Device Control register in PCI configuration space to stop it; then let the user download/install a new device driver; then start the new device driver in the same way as above.



Software interrupts (e.g. "int 0x80") are not IRQs and are not effected by the IF flag in EFLAGS (e.g. CLI/STI).


Cheers,

Brendan

By "enabling interrupts" I meant only hardware interrupts, and as Brendan pointed out, you don't need to enable them in order to do syscalls. You could simply mask all interrupts in the PIC / APIC or do a CLI instead of installing dummy handlers - so that those handlers won't eat up incoming interrupts without handling them properly.

Ah ****, I actually though cli/sli turned on/off software interrupts as well. Now I feel silly. This changes things slightly.

Thanks guys!

How are the interrupt messages delivered to the cpu ?

In most cases this will be trough the lapic.
You can't use the IOAPIC without first making sure IPI's work.
The lapic uses ipi's to inform to selected core of an pending interrupt.