Spurious interrupt in Bochs?

[Alpha]

Hi everyone,

I am writing a kernel and when testing things on Bochs my IRQ7 handler started to fire.
I was wondering why, since i don't have written any drivers except for the PIT and PIC. On the PIC i have masked out all the IRQ lines except IRQ0, so i wonder why i get IRQ7 interrupts.
After some research i found out about spurious interrupts, but i don't really understand what is going on and what is causing this to happen.
It only seems to happen on Bochs, not on Qemu or real hardware.

After initialising my kernel, i set up some tasks, schedule the first task, switch the stack and start executing the task via an iret instruction. This also enables interrupts via the EFLAGS value on the stack. After this instruction, the task gets to execute a single instruction and then the IRQ7 fires.

Using the bochs debugger i can check the internal registers of the PIC (see image). The values are the same before and just after the interrupt, all interrupts lines are masked out except IRQ0.

Can anybody explain to me what is going on?

[Octocontrabass]

If a device attached to the PIC raises an IRQ and then withdraws the IRQ before the PIC can interrupt the CPU, some chipsets will give you a spurious IRQ instead of ignoring the withdrawn IRQ.

If you've programmed the PIT to keep ticking without waiting for the CPU, it will periodically raise and then withdraw the IRQ. If there's enough time between initializing the PIC and the IRET into the first task, the PIT could raise and then withdraw its IRQ, resulting in an immediate spurious IRQ.

When you enable interrupts via EFLAGS.IF, the CPU executes at least one instruction before responding to any pending interrupts.