Linux中斷子系統

Linux kernel的中斷子系統之（一）
一、前言

一個合格的linux驅動工程師需要對kernel中的中斷子系統有深刻的理解，只有這樣，在寫具體driver的時候才能：

1、正確的使用linux kernel提供的的API，例如最著名的request_threaded_irq（request_irq）介面

2、正確使用同步機制保護驅動程式碼中的臨界區

3、正確的使用kernel提供的softirq、tasklet、workqueue等機制來完成具體的中斷處理

基於上面的原因，我希望能夠通過一系列的文件來描述清楚linux kernel中的中斷子系統方方面面的知識。一方面是整理自己的思緒，另外一方面，希望能夠對其他的驅動工程師（或者想從事linux驅動工作的工程師）有所幫助。

二、中斷系統相關硬體描述

中斷硬體系統主要有三種器件參與，各個外設、中斷控制器和CPU。各個外設提供irq request line，在發生中斷事件的時候，通過irq request line上的電氣訊號向CPU系統請求處理。外設的irq request line太多，CPU需要一個小夥伴幫他，這就是Interrupt controller。Interrupt Controller是連線外設中斷系統和CPU系統的橋樑。根據外設irq request line的多少，Interrupt Controller可以級聯。CPU的主要功能是運算，因此CPU並不處理中斷優先順序，那是Interrupt controller的事情。對於CPU而言，一般有兩種中斷請求，例如：對於ARM，是IRQ和FIQ訊號線，分別讓ARM進入IRQ mode和FIQ mode。對於X86，有可遮蔽中斷和不可遮蔽中斷。

本章節不是描述具體的硬體，而是使用了HW block這樣的概念。例如CPU HW block是隻ARM core或者X86這樣的實際硬體block的一個邏輯描述，實際中，可能是任何可能的CPU block。

1、HW中斷系統的邏輯block圖

我對HW中斷系統之邏輯block diagram的理解如下圖所示：

系統中有若干個CPU block用來接收中斷事件並進行處理，若干個Interrupt controller形成樹狀的結構，彙集系統中所有外設的irq request line，並將中斷事件分發給某一個CPU block進行處理。從介面層面看，主要有兩類介面，一種是中斷介面。有的實現中，具體中斷介面的形態就是一個硬體的訊號線，通過電平訊號傳遞中斷事件（ARM以及GIC組成的中斷系統就是這麼設計的）。有些系統採用了其他的方法來傳遞中斷事件，比如x86＋APIC（Advanced Programmable Interrupt Controller）組成的系統，每個x86的核有一個Local APIC，這些Local APIC們通過ICC（Interrupt Controller Communication）bus連線到IO APIC上。IO APIC收集各個外設的中斷，並翻譯成匯流排上的message，傳遞給某個CPU上的Local APIC。因此，上面的紅色線條也是邏輯層面的中斷訊號，可能是實際的PCB上的銅線（或者SOC內部的銅線），也可能是一個message而已。除了中斷介面，CPU和Interrupt Controller之間還需要有控制資訊的交流。Interrupt Controller會開放一些暫存器讓CPU訪問、控制。

2、多個Interrupt controller和多個cpu之間的拓撲結構

Interrupt controller有的是支援多個CPU core的（例如GIC、APIC等），有的不支援（例如S3C2410的中斷控制器，X86平臺的PIC等）。如果硬體平臺中只有一個GIC的話，那麼通過控制該GIC的暫存器可以將所有的外設中斷，分發給連線在該interrupt controller上的CPU。如果有多個GIC呢（或者級聯的interrupt controller都支援multi cpu core）？假設我們要設計一個非常複雜的系統，系統中有8個CPU，有2000個外設中斷要處理，這時候你如何設計系統中的interrupt controller？如果使用GIC的話，我們需要兩個GIC（一個GIC最多支援1024箇中斷源），一個是root GIC，另外一個是secondary GIC。這時候，你有兩種方案：

（1）把8個cpu都連線到root GIC上，secondary GIC不接CPU。這時候原本掛接在secondary GIC的外設中斷會輸出到某個cpu，現在，只能是（通過某個cpu interface的irq signal）輸到root GIC的某個SPI上。對於軟體而言，這是一個比較簡單的設計，secondary GIC的cpu interface的設定是固定不變的，永遠是從一個固定的CPU interface輸出到root GIC。這種方案的壞處是：這時候secondary GIC的PPI和SGI都是沒有用的了。此外，在這種設定下，所有連線在secondary GIC上的外設中斷要送達的target CPU是統一處理的，要麼送去cpu0，要麼cpu 5，不能單獨控制。

（2）當然，你也可以讓每個GIC分別連線4個CPU core，root GIC連線CPU0~CPU3，secondary GIC連線CPU4~CPU7。這種狀態下，連線在root GIC的中斷可以由CPU0~CPU3分擔處理，連線在secondary GIC的中斷可以由CPU4~CPU7分擔處理。但這樣，在中斷處理方面看起來就體現不出8核的威力了。

注：上一節中的邏輯block示意圖採用的就是方案一。

3、Interrupt controller把中斷事件送給哪個CPU？

毫無疑問，只有支援multi cpu core的中斷控制器才有這種幸福的煩惱。一般而言，中斷控制器可以把中斷事件上報給一個CPU或者一組CPU（包括廣播到所有的CPU上去）。對於外設型別的中斷，當然是送到一個cpu上就OK了，我看不出來要把這樣的中斷送給多個CPU進行處理的必要性。如果送達了多個cpu，實際上，也應該只有一個handler實際和外設進行互動，另外一個cpu上的handler的動作應該是這樣的：發現該irq number對應的中斷已經被另外一個cpu處理了，直接退出handler，返回中斷現場。IPI的中斷不存在這個限制，IPI更像一個CPU之間通訊的機制，對這種中斷廣播應該是毫無壓力。

實際上，從使用者的角度看，其需求是相當複雜的，我們的目標可能包括：

（1）讓某個IRQ number的中斷由某個特定的CPU處理

（2）讓某個特定的中斷由幾個CPU輪流處理

……

當然，具體的需求可能更加複雜，但是如何區分軟體和硬體的分工呢？讓硬體處理那麼複雜的策略其實是不合理的，複雜的邏輯如果由硬體實現，那麼就意味著更多的電晶體，更多的功耗。因此，最普通的做法就是為Interrupt Controller支援的每一箇中斷設定一個target cpu的控制介面（當然應該是以暫存器形式出現，對於GIC，這個暫存器就是Interrupt processor target register）。系統有多個cpu，這個控制介面就有多少個bit，每個bit代表一個CPU。如果該bit設定為1，那麼該interrupt就上報給該CPU，如果為0，則不上報給該CPU。這樣的硬體邏輯比較簡單，剩餘的控制內容就交給軟體好了。例如如果系統有兩個cpu core，某中斷想輪流由兩個CPU處理。那麼當CPU0相應該中斷進入interrupt handler的時候，可以將Interrupt processor target register中本CPU對應的bit設定為0，另外一個CPU的bit設定為1。這樣，在下次中斷髮生的時候，interupt controller就把中斷送給了CPU1。對於CPU1而言，在執行該中斷的handler的時候，將Interrupt processor target register中CPU0的bit為設定為1，disable本CPU的位元位，這樣在下次中斷髮生的時候，interupt controller就把中斷送給了CPU0。這樣軟體控制的結果就是實現了特定中斷由2個CPU輪流處理的演算法。

4、更多的思考

面對這個HW中斷系統之邏輯block diagram，我們其實可以提出更多的問題：

（1）中斷控制器傳送給CPU的中斷是否可以收回？重新分發給另外一個CPU？

（2）系統中的中斷如何分發才能獲得更好的效能呢？

（3）中斷分發的策略需要考慮哪些因素呢？

……

很多問題其實我也沒有答案，慢慢思考，慢慢逼近真相吧。

二、中斷子系統相關的軟體框架

linux kernel的中斷子系統相關的軟體框架圖如下所示：

由上面的block圖，我們可知linux kernel的中斷子系統分成4個部分：

（1）硬體無關的程式碼，我們稱之Linux kernel通用中斷處理模組。無論是哪種CPU，哪種controller，其中斷處理的過程都有一些相同的內容，這些相同的內容被抽象出來，和HW無關。此外，各個外設的驅動程式碼中，也希望能用一個統一的介面實現irq相關的管理（不和具體的中斷硬體系統以及CPU體系結構相關）這些“通用”的程式碼組成了linux kernel interrupt subsystem的核心部分。

（2）CPU architecture相關的中斷處理。 和系統使用的具體的CPU architecture相關。

（3）Interrupt controller驅動程式碼 。和系統使用的Interrupt controller相關。

（4）普通外設的驅動。這些驅動將使用Linux kernel通用中斷處理模組的API來實現自己的驅動邏輯。

轉載請註明出處：
蝸窩科技：http://www.wowotech.net/linux_kenrel/interrupt_subsystem_architecture.html