问Win2000内核驱动高手们：可否硬性指定中断服务程序的IRQL值？

我在驱动程序中使用HalGetInterruptVector（）函数测试了从IRQ0到IRQ23的IRQL值，如下：
IRQ 0: IRQL is 5 (ISA)System timer
IRQ 1: IRQL is 10 (ISA)KeyBoard
IRQ 2: IRQL is 5 (ISA)No Used
IRQ 3: IRQL is 4 (ISA)No Used
IRQ 4: IRQL is 9 (ISA)COM1
IRQ 5: IRQL is 10 (ISA)No Used
IRQ 6: IRQL is 5 (ISA)Floppy disk controller
IRQ 7: IRQL is 8 (ISA)No Used
IRQ 8: IRQL is 9 (ISA)CMOS/real time clock
IRQ 9: IRQL is 10 (ISA)Microsoft ACPI-Compliant System
IRQ 10: IRQL is 6 (ISA)No Used
(PCI)Intel(R) 82801EB SMBus Controller - 24D3
IRQ 11: IRQL is 7 (ISA)No Used
IRQ 12: IRQL is 4 (ISA)PS/2 Compatible Mouse
IRQ 13: IRQL is 7 (ISA)Numeric data processor
IRQ 14: IRQL is 6 (ISA)Primary IDE Channel
IRQ 15: IRQL is 8 (ISA)Secondary IDE Channel
IRQ 16: IRQL is 8 (PCI)Intel(R) 82801EB USB Universal Host Controller
(PCI)Intel(R) 82801EB USB Universal Host Controller
IRQ 17: IRQL is 8 (PCI)Realtek AC\'97 Audio
IRQ 18: IRQL is 8 (PCI)Intel(R) 82801EB USB Universal Host Controller
IRQ 19: IRQL is 8 (PCI)Intel(R) 82801EB USB Universal Host Controller
IRQ 20: IRQL is 8 (PCI)No Used
IRQ 21: IRQL is 8 (PCI)No Used
IRQ 22: IRQL is 8 (PCI)No Used
IRQ 23: IRQL is 8 (PCI)Standard Enhanced PCI to USB Host Controller

其中各IRQ所对应的硬件是在Win2000的“系统”－>“硬件”－>“设备管理器”中查看的，从上面的测试可以看出：IRQ值与IRQL值并不一致，按理说IRQ0是所有ISA总线中中断级别最高的，但其对应的IRQL确只有5，比硬盘控制器的IRQL低，这样是否意味着当硬盘控制器中断正在执行时，系统时钟中断就必须等待？按我估计，当系统时钟中断正在执行时，尽管硬盘控制器的IRQL比较高，但是，由于其硬件IRQ的优先级比较低，因此8259将不会把其中断信号送到CPU中去，因此其应该不会打扰系统时钟中断的执行，但是反过来我就不知道会怎样了；还请高手们指点一二。
另外，IRQ所对应的IRQL值是Win2000内核分配的，能否人为改动呢？（我指的不是在中断服务程序中用Ke...()函数提高CPU的当前IRQL值），如果能的话就可以较容易的实现实时控制了，高手们多多指教。


[编辑 -  5/15/05 by  zhenlongyang]

希望能人早点看到此贴。

Interrupt Vector Table - When power is applied to a computer, the POST procedure creates a table of interrupt vectors that is 1024 bytes and contains a maximum of 256 interrupts. This table lists pointers to interrupt service routines. The interrupt vector table starts at memory location 0000:0000h and ends at 0000:03FCh. An interrupt vector is a 4-byte value of the form offset;segment, which represents the address of a routine to be called when the CPU receives an interrupt. The interrupt vector table is first initialized by the start up ROM but changes are made to it\'s contents as the first ROM Extensions and later the operating system files are loaded. The ability to update the contents of the interrupt vector table provides a means to easily expand operating system services.

hook 中断处理程序
你爱在哪个irql上执行 就可以在哪个irql上执行

windows中那个8259的硬中断优先编码 已失效了吧？
应该是每个中断都会到cpu 只是处理与不处理的问题

乱说一气  你打我吧

hook 中断处理程序
你爱在哪个irql上执行 就可以在哪个irql上执行

windows中那个8259的硬中断优先编码 已失效了吧？
应该是每个中断都会到cpu 只是处理与不处理的问题

乱说一气  你打我吧

Hook中断处理程序？如何Hook？另外，Windows中8259的硬中断优先编码失效了？不会吧？我试过通过直接控制8259使其不产生任何中断，键盘鼠标就全部没有了反应，Win2000就变得又聋又瞎了。

[编辑 -  5/16/05 by  zhenlongyang]

[quote]hook 中断处理程序
你爱在哪个irql上执行 就可以在哪个irql上执行

windows中那个8259的硬中断优先编码 已失效了吧？
应该是每个中断都会到cpu 只是处理与不处理的问题

乱说一气  你打我吧

Hook中断处理程序？如何Hook？另外，Windows中8259的硬中断优先编码失效了？不会吧？我试过通过直接控制8259使其不产生任何中断，键盘鼠标就全部没有了反应，Win2000就变得又聋又瞎了。

[编辑 -  5/16/05 by  zhenlongyang] [/quote]
现在PC不再用8259,改用APIC了,但还是兼容8259的控制命令的,新的APIC,高级可编程中断控制器,提供任何硬件中断到系统中断的映射.但是这方面资料我几乎没有,故不敢多言
至于hook中断处理,我的垃圾原创中演示了hook全部中断,也许在中断处理中可以调用KeRaiseIrql,人为改变吧,但我估计认为改变后,Windows 2k肯定会乱的,经常要panic

windows的irql 应该是用全局变量 保存的吧 你直接修改就可以了
我是这么理解的 windows 在中断处理程序中会判断当前 此中断
的irql 如果低于当前irql 则不会转到我们通过hal注册的中断处理程序，反之则转 所以当你hook中断向量时 你可以在代码中执行你想执行的程序，而不必管什么irql 当然在你执行完了以后再跳到原来的中断向量 它自然会在那判断此时的irql 和 中断的irql谁高谁低。

这完全是个人的理解，我觉得这样解释的通 ，哪位高人知道到底是怎么在整，请告诉一声 ，感激不尽！

应该不可以改，硬件irql与irq的对应关系是操作系统内部定义出来的，而且，而且多核心和单核心对应关系还不一样，人为改掉，肯定会有问题。

楼上有几位没有理解我的意思，我指的不是在中断服务程序中提高CPU的当前IRQL级别，那是很容易的，而是如何能令自己的中断服务程序中断别的中断服务程序，比如，为系统时钟中断（IRQ0，IRQL＝5）编的中断服务程序如何能中断正在执行的硬盘控制器中断（IRQ14，IRQL＝6）服务程序；至于人为更改IRQL会不会有问题，我认为应该不会，Windows是如何确定某个IRQ所对应的IRQL的呢？包括一些未被系统占用而留给用户硬件使用的IRQ，它们的IRQL值也不尽相同呀！另外，在Windows2000下，我曾经试过在我的时钟中断服务程序中加一个延时，然后先关闭我的驱动程序，运行Windows的文件复制功能复制一个很大的文件（个人认为硬盘控制器中断服务程序应该被执行），在文件拷贝期间启动我的时钟中断服务程序，一旦我的时钟中断执行便会中断硬盘控制器中断，这时文件拷贝立即停止，当时钟中断退出后文件拷贝便会继续，并未发现有何异常，但这也不能说明时钟中断的优先级比硬盘控制器中断的优先级高（事实上应该是低，否则不就与Windows声称的IRQL级别关系矛盾了么。），因为时钟中断可能是在某个硬盘控制器中断执行完毕时执行的，但可以断定在时钟中断正在执行时硬盘控制器中断是不会执行的。

[quote
[编辑 -  5/16/05 by  zhenlongyang] [/quote]
现在PC不再用8259,改用APIC了,但还是兼容8259的控制命令的,新的APIC,高级可编程中断控制器,提供任何硬件中断到系统中断的映射.但是这方面资料我几乎没有,故不敢多言
至于hook中断处理,我的垃圾原创中演示了hook全部中断,也许在中断处理中可以调用KeRaiseIrql,人为改变吧,但我估计认为改变后,Windows 2k肯定会乱的,经常要panic [/quote]
bmyyyud先生的说法或许可行，我会尽量试试看。

[编辑 -  5/17/05 by  zhenlongyang]

有的资料讲，中断分为硬件中断，和异常（故障、陷阱、中止）等软件中断，硬中断又分为可屏蔽和不可屏蔽的。中断优先级为：软中断〉nmi中断〉intr中断。且IDT表中0-255均分配给软中断，那么硬件中断的处理程序是如何挂接的呢？irql又指的是什么？

现在进入os是apic在管理中断。
apic当然也有其自己的中断优先级。

[返回] [上一页] [下一页]

中断请求级

--------------------------------------------------------------------------------

Windows NT为每个硬件中断和少数软件事件赋予了一个优先级，即中断请求级(interrupt request level - IRQL)。IRQL为单CPU上的活动提供了同步方法，它基于下面规则：

一旦某CPU执行在高于PASSIVE_LEVEL的IRQL上时，该CPU上的活动仅能被拥有更高IRQL的活动抢先。

图4-1显示了x86平台上的IRQL值范围。(通常，这个IRQL数值要取决于你所面对的平台) 用户模式程序执行在PASSIVE_LEVEL上，可以被任何执行在高于该IRQL上的活动抢先。许多设备驱动程序例程也执行在PASSIVE_LEVEL上。第二章中讨论的DriverEntry和AddDevice例程就属于这类，大部分IRP派遣例程也属于这类。

某些公共驱动程序例程执行在DISPATCH_LEVEL上，而DISPATCH_LEVEL级要比PASSIVE_LEVEL级高。这些公共例程包括StartIo例程，DPC(推迟过程调用)例程，和其它一些例程。这些例程的共同特点是，它们都需要访问设备对象和设备扩展中的某些域，它们都不受派遣例程的干扰或互相干扰。当任何一个这样的例程运行时，上面陈述的规则可以保证它们不被任何驱动程序的派遣例程抢先，因为派遣例程本身执行在更低级的IRQL上。另外，它们也不会被同类例程抢先，因为那些例程运行的IRQL与它们自己的相同。只有拥有更高IRQL的活动才能抢先它们。

注意
--------------------------------------------------------------------------------
派遣例程(Dispatch routine)和DISPATCH_LEVEL级名称类似。之所以称做派遣例程是因为I/O管理器向这些函数派遣I/O请求。而存在派遣级(DISPATCH_LEVEL)这个名称是因为内核线程派遣器运行在这个IRQL上，它决定下一次该执行哪个线程。(现在，线程调度程序通常运行在SYNCH_LEVEL级上)


图4-1. 中断请求级

在DISPATCH_LEVEL级和PROFILE_LEVEL级之间是各种硬件中断级。通常，每个有中断能力的设备都有一个IRQL，它定义了该设备的中断优先级别。WDM驱动程序只有在收到一个副功能码为IRP_MN_START_DEVICE的IRP_MJ_PNP请求后，才能确定其设备的IRQL。设备的配置信息作为参数传递给该请求，而设备的IRQL就包含在这个配置信息中。我们通常把设备的中断级称为设备IRQL，或DIRQL。

其它IRQL级的含义有时需要依靠具体的CPU结构。这些IRQL通常仅被Windows NT内核内部使用，因此它们的含义与设备驱动程序的编写不是特别密切相关。例如，我将要在本章后面详细讨论的APC_LEVEL，当系统在该级上为某线程调度APC(异步过程调用)例程时不会被同一CPU上的其它线程所干扰。在HIGH_LEVEL级上系统可以执行一些特殊操作，如系统休眠前的内存快照、处理bug check、处理假中断，等等。

IRQL的变化
为了演示IRQL的重要性，参见图4-2，该图显示了发生在单CPU上的一系列事件。在时间序列的开始处，CPU执行在PASSIVE_LEVEL级上。在t1时刻，一个中断到达，它的服务例程执行在DIRQL1上，该级是在DISPATCH_LEVEL和PROFILE_LEVEL之间的某个DIRQL。在t2时刻，另一个中断到达，它的服务例程执行在DIRQL2上，比DIRQL1低一级。我们讨论过抢先规则，所以CPU将继续服务于第一个中断。当第一个中断服务例程在t3时刻完成时，该中断服务程序可能会请求一个DPC。而DPC例程是执行在DISPATCH_LEVEL上。所以当前存在的未执行的最高优先级的活动就是第二个中断的服务例程，所以系统接着执行第二个中断的服务例程。这个例程在t4时刻结束，假设这之后再没有其它中断发生，CPU将降到DISPATCH_LEVEL级上执行第一个中断的DPC例程。当DPC例程在t5时刻完成后，IRQL又落回到原来的PASSIVE_LEVEL级。



图4-2. 变化中的中断优先级

基本同步规则
遵循下面规则，你可以利用IRQL的同步效果：

所有对共享数据的访问都应该在同一(提升的)IRQL上进行。

换句话说，不论何时何地，如果你的代码访问的数据对象被其它代码共享，那么你应该使你的代码执行在高于PASSIVE_LEVEL的级上。一旦越过PASSIVE_LEVEL级，操作系统将不允许同IRQL的活动相互抢先，从而防止了潜在的冲突。然而这个规则不足以保护多处理器机器上的数据，在多处理器机器中你还需要另外的防护措施――自旋锁(spin lock)。如果你仅关心单CPU上的操作，那么使用IRQL就可以解决所有同步问题。但事实上，所有WDM驱动程序都必须设计成能够运行在多处理器的系统上。

IRQL与线程优先级
线程优先级是与IRQL非常不同的概念。线程优先级控制着线程调度器的调度动作，决定何时抢先运行线程以及下一次运行什么线程。然而，当IRQL级高于或等于DISPATCH_LEVEL级时线程切换停止，无论当前活动的是什么线程都将保持活动状态直到IRQL降到DISPATCH_LEVEL级之下。而此时的“优先级”仅指IRQL本身，由它控制到底哪个活动该执行，而不是该切换到哪个线程的上下文。

IRQL和分页
执行在提升的IRQL级上的一个后果是，系统将不能处理页故障(系统在APC级处理页故障)。这意味着：

执行在高于或等于DISPATCH_LEVEL级上的代码绝对不能造成页故障。

这也意味着执行在高于或等于DISPATCH_LEVEL级上的代码必须存在于非分页内存中。此外，所有这些代码要访问的数据也必须存在于非分页内存中。最后，随着IRQL的提升，你能使用的内核模式支持例程将会越来越少。

DDK文档中明确指出支持例程的IRQL限定。例如，KeWaitForSingleObject例程有两个限定：

调用者必须运行在低于或等于DISPATCH_LEVEL级上。
如果调用中指定了非0的超时，那么调用者必须严格地运行在低于DISPATCH_LEVEL的IRQL上。
上面这两行想要说明的是：如果KeWaitForSingleObject真的被阻塞了指定长的时间(你指定的非0超时)，那么你必定运行在低于DISPATCH_LEVEL的IRQL上，因为只有在这样的IRQL上线程阻塞才是允许的。如果你所做的一切就是为了检测事件是否进入信号态，则可以执行在DISPATCH_LEVEL级上。但你不能在ISR或其它运行在高于DISPATCH_LEVEL级上的例程中调用KeWaitForSingleObject例程。

IRQL的隐含控制
在大部分时间里，系统都是在正确的IRQL上调用驱动程序中的例程。虽然我们还没有详细地讨论过这些例程，但我希望举一个例子来表达这句话的含义。你首先遇到的I/O请求就是I/O管理器调用你的某个派遣例程来处理一个IRP。这个调用发生在PASSIVE_LEVEL级上，因为你需要阻塞调用者线程，还需要调用其它支持例程。当然，你不能在更高的IRQL级上阻塞一个线程，而PASSIVE_LEVEL也是唯一能让你无限制地调用任何支持例程的IRQL级。

如果你的派遣例程通过调用IoStartPacket来排队IRP，那么你第一个遇到的请求将发生在I/O管理器调用你的StartIo例程时。这个调用发生在DISPATCH_LEVEL级，因为系统需要在没有其它例程(这些例程能在队列中插入或删除IRP)干扰的情况下访问I/O队列。回想一下前面提到的规则：所有对共享数据的访问都应该在同一(提升的)IRQL级上进行。因为每个能访问IRP队列的例程都执行在DISPATCH_LEVEL级上，所以任何例程在操作队列期间都不可能被打断(仅指在单CPU系统)。

之后，设备可能生成一个中断，而该中断的服务例程(ISR)将在DIRQL级上被调用。设备上的某些寄存器也许不能被安全地共享。但是，如果你仅在DIRQL上访问那些寄存器，可以保证在单CPU计算机上没人能妨碍你的ISR执行。如果驱动程序的其它代码需要访问这些关键的硬件寄存器，你应该让这些代码仅执行在DIRQL级上。KeSynchronizeExecution服务函数可以帮助你强制执行这个规则，我将在第七章的“与中断处理连接”段中讨论这个函数。

再往后，你应该安排一个DPC调用。DPC例程执行在DISPATCH_LEVEL级上，它们需要访问你的IRP队列，并取出队列中的下一个请求，然后把这个请求发送给StartIo例程。你可以调用IoStartNextPacket服务函数从队列中提取下一个请求，但必须在DISPATCH_LEVEL级上调用。该函数在返回前将调用你的StartIo例程。注意，这里的IRQL吻合得相当巧妙：队列访问，调用IoStartNextPacket，和调用StartIo都需要发生在DISPATCH_LEVEL级上，并且系统也是在这个IRQL级上调用DPC例程的。

尽管明确地控制IRQL也是可能的，但几乎没有理由这样做，因为你需要的IRQL和系统调用你时使用的IRQL总是相应的。所以不必不时地提高IRQL，例程希望的IRQL和系统使用的IRQL几乎总是正确对应的。

IRQL的明确控制
如果必要，你还可以在当前处理器上临时提升IRQL，然后再降回到原来的IRQL，使用KeRaiseIrql和KeLowerIrql函数。下面代码运行在PASSIVE_LEVEL级上：

KIRQL oldirql; <--1
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL); <--2
KeRaiseIrql(DISPATCH_LEVEL, &oldirql); <--3
...
KeLowerIrql(oldirql); <--4
 

KIRQL定义了用于保存IRQL值的数据类型。我们需要一个变量来保存当前IRQL。
这个ASSERT断定了调用KeRaiseIrql的必要条件：新IRQL必须大于或等于当前IRQL。如果这个关系不成立，KeRaiseIrql将导致bug check。(即用死亡蓝屏报告一个致命错误)
KeRaiseIrql把当前的IRQL提升到第一个参数指定的IRQL级上。它同时还把当前的IRQL值保存到第二个参数指定的变量中。在这个例子中，我们把IRQL提升到DISPATCH_LEVEL级，并把原来的IRQL级保存到oldirql变量中。
执行完任何需要在提升的IRQL上执行的代码后，我们调用KeLowerIrql把IRQL降低到调用KeRaiseIrql时的级别。
DDK文档中提到，你必须用与你最近的KeRaiseIrql调用所返回的值调用KeLowerIrql。这在大的方面是对的，因为你提升了IRQL就必须再降低它。然而，由于你调用的代码或者调用你的代码所做的各种假设会使后面的决定变得不正确。所以，文档中的这句话从严格意义上讲是不正确的。应用到KeLowerIrql函数的唯一的规则就是新IRQL必须低于或等于当前IRQL。

当系统调用你的驱动程序例程时，你降低了IRQL(系统调用你的例程时使用的IRQL，或你的例程希望执行的IRQL)，这是一个错误，而且是严重错误，尽管你在例程返回前又提升了IRQL。这种打破同步的结果是，某些活动可以抢先你的例程，并能访问你的调用者认为不能被共享的数据对象。

有一个函数专用于把IRQL提升到DISPATCH_LEVEL级：

KIRQL oldirql = KeRaiseIrqlToDpcLevel();
...
KeLowerIrql(oldirql)
 

注意：该函数仅在NTDDK.H中声明，WDM.H中并没有声明该函数，因此WDM驱动程序不应该使用该函数。
 

相信来这里的每一位都读过这本书，应该知道啊。。。
hoho所以平时还是多读点书先。。。。。

楼上有几位没有理解我的意思，我指的不是在中断服务程序中提高CPU的当前IRQL级别，那是很容易的，而是如何能令自己的中断服务程序中断别的中断服务程序，比如，为系统时钟中断（IRQ0，IRQL＝5）编的中断服务程序如何能中断正在执行的硬盘控制器中断（IRQ14，IRQL＝6）服务程序；至于人为更改IRQL会不会有问题，我认为应该不会，Windows是如何确定某个IRQ所对应的IRQL的呢？包括一些未被系统占用而留给用户硬件使用的IRQ，它们的IRQL值也不尽相同呀！另外，在Windows2000下，我曾经试过在我的时钟中断服务程序中加一个延时，然后先关闭我的驱动程序，运行Windows的文件复制功能复制一个很大的文件（个人认为硬盘控制器中断服务程序应该被执行），在文件拷贝期间启动我的时钟中断服务程序，一旦我的时钟中断执行便会中断硬盘控制器中断，这时文件拷贝立即停止，当时钟中断退出后文件拷贝便会继续，并未发现有何异常，但这也不能说明时钟中断的优先级比硬盘控制器中断的优先级高（事实上应该是低，否则不就与Windows声称的IRQL级别关系矛盾了么。），因为时钟中断可能是在某个硬盘控制器中断执行完毕时执行的，但可以断定在时钟中断正在执行时硬盘控制器中断是不会执行的。

你也没理解我的意思 ，我是说让你不要用 hal 导出的函数注册中断处理程序，我是让你直接去改中断向量表。跳到你的处理程序里去。这样你的中断就可以中断任何irql执行的程序了。 但是你也需要改irql不然你的中断处理程序又会被其他的中断

另外，你说irql低的时钟中断当然不可能会中断所谓高irql的硬盘中断处理程序，确切的说 是irql低的时钟中断 去中断了在DPC上执行的真正的硬盘中断处理程序。

相信来这里的每一位都读过这本书，应该知道啊。。。
hoho所以平时还是多读点书先。。。。。

我没读过 不过感觉写得不错
书名是什么

[/quote]你也没理解我的意思 ，我是说让你不要用 hal 导出的函数注册中断处理程序，我是让你直接去改中断向量表。跳到你的处理程序里去。这样你的中断就可以中断任何irql执行的程序了。 但是你也需要改irql不然你的中断处理程序又会被其他的中断

另外，你说irql低的时钟中断当然不可能会中断所谓高irql的硬盘中断处理程序，确切的说 是irql低的时钟中断 去中断了在DPC上执行的真正的硬盘中断处理程序。 [/quote]

这个底层的方法不知道合不合你：
读一下ich的spec，就知道apic控制寄存器map到physic mem ：APICPhysicmem(不同平台不一样）.包括24个irq的控制寄存器，应该可以改到中断优先级的。访问方式：
APICPhysicmem           32bit index
APICPhysicmem+（10-13） 32bit data
不过象smi，nmi这些中断呢，就别想了，他们是最高的。
其实你可以临时提高你当前的irq中断优先级，不过中断过后要变回来。