中斷請求級

 

中斷請求級

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

1. KIRQL定義了用於保存IRQL值的數據類型。我們需要一個變量來保存當前IRQL。
2. 這個ASSERT斷定了調用KeRaiseIrql的必要條件：新IRQL必須大於或等於當前IRQL。如果這個關係不成立，KeRaiseIrql將導致bug check。(即用死亡藍屏報告一個致命錯誤)
3. KeRaiseIrql把當前的IRQL提升到第一個參數指定的IRQL級上。它同時還把當前的IRQL值保存到第二個參數指定的變量中。在這個例子中，我們把IRQL提升到DISPATCH_LEVEL級，並把原來的IRQL級保存到oldirql變量中。
4. 執行完任何需要在提升的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驅動程序不應該使用該函數。