My platform is x86 and x86-64, on Windows.
The point of the interrupt priority system is to have the highest priority interrupt beat out the others. To enforce this, I'm guessing that Windows will disable all interrupts of lower level completely, until the ISR for the higher-level interrupt is complete.
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again? If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed? What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
Some background
Interrupts from the peripherals are not directly handled by the CPU, instead by a hardware called "Programmable Interrupt Controller". Earlier systems used a PIC - (Intel 8259) but due to its lack of support for SMP systems, nowadays Adavnced PIC - APIC (Intel 82093) is used. APIC has two components, IO APIC (part of motherboard) forwards these interrupt requests to the local APIC (part of the CPU).
But these hardwares just pass the messages to the CPU, the actual handling is done by the device driver of the particular device.
Now to your questions
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again?
This article talks about two classes of interrupts handlers depending upon how fast they are executed:
1. Fast: Run with further interrupts disabled,
2. Slow: Run with interrupts enabled.
But now the distinction between the two has become obsolete since tasklets/work queues (top & bottom halfs - rings a bell?) have made the execution time of the handlers very less, hence nowadays interrupts handlers are run with interrupts enabled. For slower devices like I2C, we have moved to a new technique called Threaded Interrupt Handler, which is even better than the top/bottom half approach. In case for some device if the above techniques don't work, than the handler is executed with interrupts disabled and yes in that case, you keep losing the interrupts, but I can't find any instance where such a thing happens.
If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed?
No, they are not queued up, it is a bad interrupt handler design if the interrupts need to be disabled and that too for a longer time.
What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
If the interrupts are disabled then there nothing that you can do, but if they are enabled and you keep getting more interrupts then it leads to nesting of interrupts, to the extent that the system might crash. A core dump then can be used to detect the cause.
来源：https://stackoverflow.com/questions/22280281/on-x86-when-the-os-disables-interrupts-do-they-vanish-or-do-they-queue-and-w