Voi*_*tar 13 kernel driver interrupt interrupt-handling kmdf
在Windows上,我的平台是x86和x86-64.
中断优先级系统的要点是让最高优先级的中断超过其他中断.为了强制执行此操作,我猜测Windows将完全禁用所有较低级别的中断,直到更高级别中断的ISR完成为止.
但如果CPU没有收听中断,会发生什么？他们只是默默地消失了吗？或者他们是否在硬件中排队,等待中断再次启用？如果存放,在哪里？有多少人可以排队？如果有太多中断没有被处理,会发生什么？如果存在中断处理积压的罕见情况,检测问题的工具是什么？
一些背景
来自外设的中断不是由CPU直接处理,而是由称为"可编程中断控制器"的硬件处理.早期的系统使用PIC - (Intel 8259),但由于缺乏对SMP系统的支持,现在使用了Adavnced PIC-APIC(Intel 82093).APIC有两个组件,IO APIC(主板的一部分)将这些中断请求转发到本地APIC(CPU的一部分).
但是这些硬件只是将消息传递给CPU,实际处理由特定设备的设备驱动程序完成.
现在回答你的问题
但如果CPU没有收听中断,会发生什么？他们只是默默地消失了吗？或者他们是否在硬件中排队,等待中断再次启用？
该文章谈到两类,这取决于它们是如何快速执行中断处理程序:
1,快速:进一步中断运行禁用,
慢速2:在与中断使能.
但是现在两者之间的区别已经过时了,因为tasklets /工作队列(上半部分和下半部分 - 响铃？)使得处理程序的执行时间变得非常少,因此现在中断处理程序在启用中断的情况下运行.对于像I2C这样的较慢设备,我们已经采用了一种名为Threaded Interrupt Handler的新技术,它比上/下半部分方法更好.如果某些设备如果上述技术不起作用,则处理程序在禁用中断的情况下执行,并且在这种情况下是,您继续丢失中断,但我找不到发生此类事件的任何实例.
如果存放,在哪里？有多少人可以排队？如果有太多中断没有被处理,会发生什么？
不,它们没有排队,如果中断需要被禁用,那么这是一个糟糕的中断处理程序设计.
如果存在中断处理积压的罕见情况,检测问题的工具是什么？
如果中断被禁用,那么你无法做任何事情,但如果它们被启用并且你不断获得更多中断,那么它会导致中断嵌套,直到系统崩溃为止.然后可以使用核心转储来检测原因.