關注、星標嵌入式客棧，乾貨及時送達
[導讀] 對於驅動開發而言，中斷機制是一個無法繞開的主題，翻看了很多資料書籍，讀來讀去總覺得沒明白，所以嘗試自底向上的分析一下Linux中斷子系統的內在設計以及運行機制。將陸續分享相關的學習原創筆記，敬請關注期待。
代碼分析基於內核5.4.31
如有興趣，不妨星標一下小號，這樣後續筆記將及時置頂出現在你的面前。
啥是中斷/異常
處理器的典型任務是處理一系列預定的程序。爲了通知處理器某些事件，有時需要中斷當前正在處理的任務。中斷可以由程序觸發，也可以從外設異步觸發。如果發生中斷請求IRQ，則處理器將執行預定的中斷服務程序ISR。CPU需要能處理軟件錯誤，例如除零或顯式中斷調用（例如syscalls）。硬件中斷由中斷控制器路由到指定的處理器（如x86系統的IO-APIC）。
操作系統的總體運行機制屬於事件驅動(event-driven)機制。
中斷：
由外部硬件生成的異步事件。
中斷控制器芯片將每個IRQ輸入映射到一箇中斷向量，該中斷向量定位相應的中斷服務程序
一個 IRQ 是來自某個設備的一箇中斷請求。可能的中斷請求源：來自一個硬件引腳，或來自一個數據包。多個設備可能連接到同一個硬件引腳，從而共享一個 IRQ。抽象成中斷請求事件，有哪些可能的事件呢：
GPIO 中斷請求,包括邊沿、電平模式
外設 I2C的start/stop事件
USB枚舉，報文
網口......
異常(陷阱)：由軟件生成的同步事件，比如前面提到的除零，頁錯誤
ARM32/ARM64硬件架構對比
ARM32
這裏以ARMv7 爲例進行描述，對於ARM32而言，CPU具有9大處理模式：
其中encoding是指的CPSR程序狀態寄存器中的M[4:0]，對於ARMv7而言，權限等級如下：
PL0-適用於用戶應用程序供應商，例如從App Store下載的應用程序。
PL1-豐富的OS供應商，例如Android使用的Linux內核。
PL2-虛擬機監控程序供應商。
(Secure PL0)安全PL0-受信任的OS供應商提供的受信任的OS應用程序。
(Secure PL1)安全PL1-受信任的操作系統。
(Secure PL)安全PL1-提供安全固件的OEM。
ARMv7採用通用中斷控制器GIC V2進行中斷分發控制。
AArch64
自《Programmer’s Guide for ARMv8-A》,armv8 引入64位ARM架構，向後兼容。
Cortex-A53處理器是一箇中檔、低功耗處理器，在單個集羣中有一個到四個核，每個核都有一個L1緩存子系統、一個可選的集成GICv3/4（通用中斷控制器Generic Interrupt Controller）接口和一個可選的L2緩存控制器。
Cortex-A57處理器針對移動和企業計算應用，包括計算密集型64位應用，如高端計算機、平板電腦和服務器產品。它可以與Cortex-A53處理器一起採用big.LITTLE技術（有的也稱爲異步多核架構）成爲一個處理器。
ARMv8-A體系結構引入了許多更改，這些更改使得可以設計性能明顯更高的處理器實現：
更大的物理地址尋址能力：處理器可以訪問超過4GB的物理內存。
64位虛擬尋址：這樣可以使虛擬內存超過4GB的限制。這對於使用內存映射文件I / O或稀疏尋址的現代臺式機和服務器軟件很重要。
自動事件信號：利於實現低功耗、高性能的自旋鎖。
更大寄存器文件：31個64位通用寄存器可提高性能並減少棧開銷。
高效的64位立即數生成：較少對文字池的依賴。
更大的PC指針相對尋址空間：+/- 4GB尋址範圍，可在共享庫和與位置無關的可執行文件中進行有效的數據尋址。
額外的16KB和64KB翻譯顆粒：這樣可以減少轉換後備緩衝區（TLB）的丟失率和頁面遍歷的深度。
新的異常模型: 降低了操作系統和管理程序軟件的複雜性。
高效的緩存管理: 用戶空間緩存操作提高了動態代碼生成效率。使用數據高速緩存零指令快速清除數據高速緩存。
硬件加速密碼器：提高3倍至10倍較好的軟件加密性能。這對於小顆粒的解密和太小而無法有效地卸載到硬件加速器上的加密非常有用，例如https。
Load-Acquire, Store-Release指令：針對C++11，C11，Java內存模型而設計。它們通過消除顯式的內存屏障指令來提高線程安全代碼的性能。
NEON雙精度浮點高級SIMD：這使SIMD矢量化可以應用於更廣泛的算法集，例如科學計算，高性能計算（HPC）和超級計算機。
上面談到了新的異常模型，這裏來看一下具體是指什麼：
在ARMv8中，程序運行總是處於四個異常級別之一。在AArch64中，異常級別確定特權級別，類似於ARMv7中定義的特權級別。異常級別確定特權級別，因此在ELn程序對應於特權PLn。類似地，n值大於另一個值的異常級別處於較高的異常級別。數量比另一個少的異常級別被描述爲處於較低的異常級別。
異常級別提供了適用於ARMv8架構所有運行狀態的軟件執行特權的邏輯隔離。它類似於計算機科學中常見的分層保護域概念。
EL0：普通用戶應用程序。
EL1：操作系統內核通常描述爲特權。
EL2：管理程序(Hypervisor)。
EL3：底層固件，包括安全監視器。
通常，一個軟件（例如應用程序，操作系統的內核或系統管理程序）佔據一個異常級別。該規則的一個例外是內核內虛擬機管理程序，例如KVM，它們在EL2和EL1上都可運行。
可運行在AArch32以及AArch64模式下：
由圖可見：在AArch32模式下，EL0相對於usr 模式，而EL1則相當於Svc、Abt、Und、FIQ、IRQ、Sys模式，而EL2則相當於Hyp模式。
ARMv8-A提供兩種安全狀態，即安全和非安全。非安全狀態也稱爲正常模式(normal world)。這使操作系統（OS）與受信任的OS在同一硬件上並行運行，並提供了針對某些軟件攻擊和硬件攻擊的保護。ARM TrustZone技術使系統可以在普通和安全環境之間進行分區。與ARMv7-A架構一樣，安全監視器充當在普通和安全環境之間移動的網關。
ARMv8-A 在正常模式下還提供了對虛擬化的支持。從而虛擬機監控程序或虛擬機管理器(VMM)代碼可以在系統上運行，並承載多個客戶操作系統。每個客戶操作系統本質上都運行在一個虛擬機上。每個操作系統就不會意識到它正在與其他客戶操作系統共享CPU。
ARMv8-A採用通用中斷控制器GIC V3進行中斷分發控制。
在AArch64中，異常可以是（synchronous exception）同步的，也可以是（ asynchronous exception）異步的。
同步異常：如果異常是在執行或試圖執行指令流時產生，並且返回地址提供導致該異常指令的詳細信息，則將其描述爲同步異常。
異步異常：異步異常不是由執行指令生成的，而返回地址可能並不總是提供導致異常的細節。異步異常的來源是IRQ(正常優先級中斷)，FIQ(快速中斷)或SError(系統錯誤)。系統錯誤有許多可能的原因，最常見的是異步數據中止(例如，由將髒數據從緩存線寫到外部內存而觸發的中止)。
啥是GIC？
GIC是一種先進的微控制器總線架構(AMBA)和ARM架構兼容的系統片上(SoC)外設。它是一種高性能的、區域優化的中斷控制器，具有芯片上的AMBA總線接口，根據配置，它符合AMBA高級可擴展接口(AXI)協議或AMBA AHB-Lite協議。
這裏僅僅參考ARM官方文檔將其中一部分從概念上加以介紹，過多細節比較枯燥就不做介紹了，個人認爲僅需要從概念上去理解一下大致原理即可，沒有必要去進行更深層的挖掘。除非你需要去修改這一層次的代碼。
具體一點來看，GIC的總體框架如下：
處理單元Processing element (PE)，也即是核
中斷翻譯服務組件Interrupt Translation Service components (ITS)
中斷路由基礎設施Interrupt Routing Infrastructure (IRI)
比如一個SPI的中斷分發路由機制如下：
分發器 Distributor：分發服務器執行中斷優先級排序，並將spi和SGIs分發到連接到系統中PEs，從而進入CPU處理。如果我們將這些都看成黑盒子，可以簡化理解一下：
對於GICv2與GICv3的主要顯著區別是GICv3可以支持更多核，GICv3可支持超過8核的處理器。
異常/中斷來了咋辦？
對於ARM處理器而言，異常/中斷到來後，處理器對應進入不同的處理器模式(FIQ/IRQ/UND/ABT).
對於ARM64處理器而言，因爲處理器已經沒有處理器模式機制了，因此對應變成進入何種異常級別(exception level)。處理器復位時默認進入最高級別的exception level，例如如果處理器最高支持的EL是EL2，復位後系統將處於EL2。對於那些正常通過system call產生的異常，處理器會切換到哪一個exception level這個問題也很好回答，SVC、HVC和SMC將進入處理器設定的異常級別。
然而對於異常/中斷的處理，說到底還是需要進入相應的異常/中斷句柄(process handler)進行處理，那麼怎麼進入的呢？這裏自然就引入了異常向量表了，這裏來看看異常向量表在哪裏實現的。這裏個人認爲理解一下大致概念也就可以了。
ARM
對於ARMv7-M而言,，位於./arch/arm/kernel/entry-v7m.s
ENTRY(vector_table)
.long 0 @ 0 - Reset stack pointer
.long __invalid_entry @ 1 - Reset
.long __invalid_entry @ 2 - NMI
.long __invalid_entry @ 3 - HardFault
.long __invalid_entry @ 4 - MemManage
.long __invalid_entry @ 5 - BusFault
.long __invalid_entry @ 6 - UsageFault
.long __invalid_entry @ 7 - Reserved
.long __invalid_entry @ 8 - Reserved
.long __invalid_entry @ 9 - Reserved
.long __invalid_entry @ 10 - Reserved
.long vector_swi @ 11 - SVCall
.long __invalid_entry @ 12 - Debug Monitor
.long __invalid_entry @ 13 - Reserved
.long __pendsv_entry @ 14 - PendSV
.long __invalid_entry @ 15 - SysTick
.rept CONFIG_CPU_V7M_NUM_IRQ
.long __irq_entry @ External Interrupts
.endr
.align 2
.globl exc_ret
exc_ret:
.space 4
對於其他的ARM架構而言，位於./arch/arm/kernel/entry-armv.S，貼上部分代碼
*
* Interrupt dispatcher
*/
vector_stub irq, IRQ_MODE, 4
.long __irq_usr @ 0 (USR_26 / USR_32)
.long __irq_invalid @ 1 (FIQ_26 / FIQ_32)
.long __irq_invalid @ 2 (IRQ_26 / IRQ_32)
.long __irq_svc @ 3 (SVC_26 / SVC_32)
.long __irq_invalid @ 4
.long __irq_invalid @ 5
.long __irq_invalid @ 6
.long __irq_invalid @ 7
.long __irq_invalid @ 8
.long __irq_invalid @ 9
.long __irq_invalid @ a
.long __irq_invalid @ b
.long __irq_invalid @ c
.long __irq_invalid @ d
.long __irq_invalid @ e
.long __irq_invalid @ f
/*
* Data abort dispatcher
* Enter in ABT mode, spsr = USR CPSR, lr = USR PC
*/
vector_stub dabt, ABT_MODE, 8
.long __dabt_usr @ 0 (USR_26 / USR_32)
.long __dabt_invalid @ 1 (FIQ_26 / FIQ_32)
.long __dabt_invalid @ 2 (IRQ_26 / IRQ_32)
.long __dabt_svc @ 3 (SVC_26 / SVC_32)
.long __dabt_invalid @ 4
.long __dabt_invalid @ 5
.long __dabt_invalid @ 6
.long __dabt_invalid @ 7
.long __dabt_invalid @ 8
.long __dabt_invalid @ 9
.long __dabt_invalid @ a
.long __dabt_invalid @ b
.long __dabt_invalid @ c
.long __dabt_invalid @ d
.long __dabt_invalid @ e
.long __dabt_invalid @ f
/*
* Prefetch abort dispatcher
* Enter in ABT mode, spsr = USR CPSR, lr = USR PC
*/
vector_stub pabt, ABT_MODE, 4
.long __pabt_usr @ 0 (USR_26 / USR_32)
.long __pabt_invalid @ 1 (FIQ_26 / FIQ_32)
.long __pabt_invalid @ 2 (IRQ_26 / IRQ_32)
.long __pabt_svc @ 3 (SVC_26 / SVC_32)
.long __pabt_invalid @ 4
.long __pabt_invalid @ 5
.long __pabt_invalid @ 6
.long __pabt_invalid @ 7
.long __pabt_invalid @ 8
.long __pabt_invalid @ 9
.long __pabt_invalid @ a
.long __pabt_invalid @ b
.long __pabt_invalid @ c
.long __pabt_invalid @ d
.long __pabt_invalid @ e
.long __pabt_invalid @ f
/*
* Undef instr entry dispatcher
* Enter in UND mode, spsr = SVC/USR CPSR, lr = SVC/USR PC
*/
vector_stub und, UND_MODE
.long __und_usr @ 0 (USR_26 / USR_32)
.long __und_invalid @ 1 (FIQ_26 / FIQ_32)
.long __und_invalid @ 2 (IRQ_26 / IRQ_32)
.long __und_svc @ 3 (SVC_26 / SVC_32)
.long __und_invalid @ 4
.long __und_invalid @ 5
.long __und_invalid @ 6
.long __und_invalid @ 7
.long __und_invalid @ 8
.long __und_invalid @ 9
.long __und_invalid @ a
.long __und_invalid @ b
.long __und_invalid @ c
.long __und_invalid @ d
.long __und_invalid @ e
.long __und_invalid @ f
.align 5
.....................
/*=============================================================================
* FIQ "NMI" handler
*-----------------------------------------------------------------------------
*/
vector_stub fiq, FIQ_MODE, 4
.long __fiq_usr @ 0 (USR_26 / USR_32)
.long __fiq_svc @ 1 (FIQ_26 / FIQ_32)
.long __fiq_svc @ 2 (IRQ_26 / IRQ_32)
.long __fiq_svc @ 3 (SVC_26 / SVC_32)
.long __fiq_svc @ 4
.long __fiq_svc @ 5
.long __fiq_svc @ 6
.long __fiq_abt @ 7
.long __fiq_svc @ 8
.long __fiq_svc @ 9
.long __fiq_svc @ a
.long __fiq_svc @ b
.long __fiq_svc @ c
.long __fiq_svc @ d
.long __fiq_svc @ e
.long __fiq_svc @ f
.globl vector_fiq
.p .vectors, "ax", %progbits
.L__vectors_start:
W(b) vector_rst
W(b) vector_und
W(ldr) pc, .L__vectors_start + 0x1000
W(b) vector_pabt
W(b) vector_dabt
W(b) vector_addrexcptn
W(b) vector_irq
W(b) vector_fiq
.data
.align 2
.globl cr_alignment
cr_alignment:
.space 4
ARM64
位於./arch/arm64/kernel/entry.S，貼上部分代碼
.pushp ".entry.text", "ax"
.align 11
ENTRY(vectors)
kernel_ventry 1, sync_invalid // Synchronous EL1t
kernel_ventry 1, irq_invalid // IRQ EL1t
kernel_ventry 1, fiq_invalid // FIQ EL1t
kernel_ventry 1, error_invalid // Error EL1t
kernel_ventry 1, sync // Synchronous EL1h
kernel_ventry 1, irq // IRQ EL1h
kernel_ventry 1, fiq_invalid // FIQ EL1h
kernel_ventry 1, error // Error EL1h
kernel_ventry 0, sync // Synchronous 64-bit EL0
kernel_ventry 0, irq // IRQ 64-bit EL0
kernel_ventry 0, fiq_invalid // FIQ 64-bit EL0
kernel_ventry 0, error // Error 64-bit EL0
#ifdef CONFIG_COMPAT
kernel_ventry 0, sync_compat, 32 // Synchronous 32-bit EL0
kernel_ventry 0, irq_compat, 32 // IRQ 32-bit EL0
kernel_ventry 0, fiq_invalid_compat, 32 // FIQ 32-bit EL0
kernel_ventry 0, error_compat, 32 // Error 32-bit EL0
#else
kernel_ventry 0, sync_invalid, 32 // Synchronous 32-bit EL0
kernel_ventry 0, irq_invalid, 32 // IRQ 32-bit EL0
kernel_ventry 0, fiq_invalid, 32 // FIQ 32-bit EL0
kernel_ventry 0, error_invalid, 32 // Error 32-bit EL0
#endif
END(vectors)
總結一下
對於做嵌入式開發，尤其需要做底層驅動開發的小夥伴們，較深入的理解一下更爲底層異常/中斷運行的機制，對於具體驅動開發而言是非常有幫助的。本文參考內核代碼，以及ARM官方規格書大致梳理了Linux中斷子系統的基礎概念，以及異常/中斷如何進入到CPU，以及相應的入口在哪裏實現定義的。後續爲逐步深入分析中斷底層如何建模抽象的，採用自底向上的分析策略進而分析用戶空間的調用接口，敬請關注期待。
本文辛苦原創分享，水平所限，文中估計也有蠻多錯誤，希望看到的同學幫忙指正，如果覺得有價值也請幫忙點贊轉發支持，不勝感激！
—END—
往期精彩推薦，點擊即可閱讀
