kernel - 在 x86 上，当操作系统禁用中断时，它们会消失，还是会排队并 'wait' 以便中断重新启动？

Question

我的平台是 Windows 上的 x86 和 x86-64。

中断优先级系统的要点是让最高优先级的中断击败其他中断。为了强制执行此操作，我猜测 Windows 将完全禁用所有较低级别的中断，直到较高级别中断的 ISR 完成。

但是如果 CPU 没有监听中断，会发生什么呢？他们就这样悄无声息地消失了吗？或者它们是否在硬件中排队，等待中断再次启用？如果它们存储在哪里？排队人数有限制吗？如果太多中断未处理会发生什么？存在哪些仪器可以检测问题，以防在极少数情况下中断处理积压？

Answer 1

一些背景

来自外设的中断不是由 CPU 直接处理，而是由称为“可编程中断 Controller ”的硬件处理。早期的系统使用 PIC - (Intel 8259 )，但由于缺乏对 SMP 系统的支持，现在使用高级 PIC - APIC (Intel 82093 )。 APIC有两个组件，IO APIC(主板的一部分)将这些中断请求转发到本地APIC(CPU的一部分)。
消息被传递到CPU，但实际处理是由特定设备的设备驱动程序完成的。

现在回答你的问题

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文章讨论了两类中断处理程序，具体取决于它们的执行速度:

1. 快速:在禁用进一步中断的情况下运行，
2. 慢:在启用中断的情况下运行。
   但现在两者之间的区别已经过时了，因为微线程/工作队列(上半部和下半部 - 敲响了警钟？)使处理程序的执行时间变得非常少，因此现在中断处理程序是在启用中断的情况下运行的。对于 I2C 等速度较慢的设备，我们已转向一种名为 Threaded Interrupt Handler 的新技术。 ，这甚至比上/下半部分方法更好。对于某些设备，如果上述技术不起作用，则处理程序会在禁用中断的情况下执行，是的，在这种情况下，您会不断丢失中断，但我找不到任何发生这种情况的实例。<

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?

如果中断被禁用，那么您无能为力，但如果它们被启用并且您不断收到更多中断，那么它会导致中断嵌套，甚至可能导致系统崩溃。然后可以使用核心转储来检测原因。