Reputation: 61
Over here, several answers say some variant of:
when a second hardware interrupt occurs while an initial one is being serviced, that interrupt will be put on hold until the first one has finished.
How does this work? For example, is it the case that I/O devices are made aware of the state of the IF flag, and they wait for the IF flag to be set to 1 before they send their interrupts? Or, is there some buffer between I/O devices and the CPU that store interrupts that are sent while the IF flag is set to 0?
Upvotes: 0
Views: 82
Reputation: 37232
On 80x86 PCs there are 2 types of interrupt controller: the old "8259 Programmable Interrupt Controller chip" which was merged into the chipset and (at least in theory) may not exist on modern UEFI systems; and the newer "external IO APIC plus a local APIC for each CPU" arrangement that is necessary to support multiple CPUs.
Both the old PIC chip and the newer local APIC have internal "interrupt received" flags, so that when an interrupt is received (from a device) the flag corresponding to that interrupt is set. When an interrupt can be sent to the CPU (possibly much later) the highest priority interrupt is found, sent to the CPU and its "interrupt received" flag is cleared (and its "interrupt in service" flag is set).
When a second interrupt of the same type arrives and the "interrupt received" flag is already set, then setting the same flag twice does nothing so one of the interrupts is lost (but you can have one interrupt "in service" while another is "received" without losing the new/received interrupt). This problem is either prevented by design (e.g. requiring the device driver's interrupt handler to read a status register in the device before the device will send another interrupt, with no more than one device as an interrupt source) or (for PCI devices where multiple devices can share the same interrupt line/s) using level triggered interrupts so that the signal is continual and not a "miss-able one time trigger".
Upvotes: 0