OSDev.org

Hi all,
The PIC page on the wiki says:

For a spurious IRQ, there is no real IRQ and the PIC chip's ISR (In Service Register) flag for the corresponding IRQ will not be set. This means that the interrupt handler must not send an EOI back to the PIC to reset the ISR flag.

The correct way to handle an IRQ 7 is to first check the master PIC chip's ISR to see if the IRQ is a spurious IRQ or a real IRQ. If it is a real IRQ then it is treated the same as any other real IRQ. If it is a spurious IRQ then you ignore it (and do not send the EOI).

I understand that the PIC itself can generate spurious interrupts using the IRQ 7 vector, but I think that it's important to check if any interrupt is spurious (since userspace can easily execute INT xx instruction for any interrupt anyway, and you certainly don't want to send EOI to the PIC in that case). Am I misunderstanding something?

Edit: oh wait, I was missing something. You can set privilege level in the IDT to prevent user space raising interrupts.

davmac314 wrote:I understand that the PIC itself can generate spurious interrupts using the IRQ 7 vector, but I think that it's important to check if any interrupt is spurious (since userspace can easily execute INT xx instruction for any interrupt anyway, and you certainly don't want to send EOI to the PIC in that case). Am I misunderstanding something?

Edit: oh wait, I was missing something. You can set privilege level in the IDT to prevent user space raising interrupts.

Well, you caught it yourself. Yes, you can just prevent userspace from executing software interrupts on IRQ vectors. Moreover, interrupt handlers should be written in a way to ensure safe operation even if the interrupt was spurious (i.e. not actually caused by the device attached). For the PIC driver itself, I would borrow a page from Linux's book and mask out interrupts that are being served. If you also keep a copy of the PIC mask in software, it is pretty fast to notice if a masked IRQ happened anyway. Such an IRQ must be spurious. It won't find all spurious IRQs, but it will find most of them, and spurious IRQs are rare enough that slowing down every IRQ is probably not worth it.

Not that any of this matters one jot or tittle these days, since APIC exists and is faster and typically preferable.