[導(dǎo)讀] 對于驅(qū)動開發(fā)而言，中斷機制是一個無法繞開的主題，翻看了很多資料書籍，讀來讀去總覺得沒明白，所以嘗試自底向上的分析一下Linux中斷子系統(tǒng)的內(nèi)在設(shè)計以及運行機制。將陸續(xù)分享相關(guān)的學(xué)習(xí)原創(chuàng)筆記，敬請關(guān)注期待。

代碼分析基于內(nèi)核5.4.31

如有興趣，不妨星標(biāo)一下小號，這樣后續(xù)筆記將及時置頂出現(xiàn)在你的面前。

啥是中斷/異常

處理器的典型任務(wù)是處理一系列預(yù)定的程序。為了通知處理器某些事件，有時需要中斷當(dāng)前正在處理的任務(wù)。中斷可以由程序觸發(fā)，也可以從外設(shè)異步觸發(fā)。如果發(fā)生中斷請求IRQ，則處理器將執(zhí)行預(yù)定的中斷服務(wù)程序ISR。CPU需要能處理軟件錯誤，例如除零或顯式中斷調(diào)用（例如syscalls）。硬件中斷由中斷控制器路由到指定的處理器（如x86系統(tǒng)的IO-APIC）。

操作系統(tǒng)的總體運行機制屬于事件驅(qū)動(event-driven)機制。

中斷：

• 由外部硬件生成的異步事件。
• 中斷控制器芯片將每個IRQ輸入映射到一個中斷向量，該中斷向量定位相應(yīng)的中斷服務(wù)程序

一個 IRQ 是來自某個設(shè)備的一個中斷請求?？赡艿闹袛嗾埱笤矗簛碜砸粋€硬件引腳，或來自一個數(shù)據(jù)包。多個設(shè)備可能連接到同一個硬件引腳，從而共享一個 IRQ。抽象成中斷請求事件，有哪些可能的事件呢：

• GPIO 中斷請求,包括邊沿、電平模式
• 外設(shè) I2C的start/stop事件
• USB枚舉，報文
• 網(wǎng)口......

異常(陷阱)：由軟件生成的同步事件，比如前面提到的除零，頁錯誤

ARM32/ARM64硬件架構(gòu)對比

ARM32

這里以ARMv7 為例進行描述，對于ARM32而言，CPU具有9大處理模式：

其中encoding是指的CPSR程序狀態(tài)寄存器中的M[4:0]，對于ARMv7而言，權(quán)限等級如下：

• PL0-適用于用戶應(yīng)用程序供應(yīng)商，例如從App Store下載的應(yīng)用程序。
• PL1-豐富的OS供應(yīng)商，例如Android使用的Linux內(nèi)核。
• PL2-虛擬機監(jiān)控程序供應(yīng)商。
• (Secure PL0)安全PL0-受信任的OS供應(yīng)商提供的受信任的OS應(yīng)用程序。
• (Secure PL1)安全PL1-受信任的操作系統(tǒng)。
• (Secure PL)安全PL1-提供安全固件的OEM。

ARMv7采用通用中斷控制器GIC V2進行中斷分發(fā)控制。

AArch64

自《Programmer’s Guide for ARMv8-A》,armv8 引入64位ARM架構(gòu)，向后兼容。

• Cortex-A53處理器是一個中檔、低功耗處理器，在單個集群中有一個到四個核，每個核都有一個L1緩存子系統(tǒng)、一個可選的集成GICv3/4（通用中斷控制器Generic Interrupt Controller）接口和一個可選的L2緩存控制器。
• Cortex-A57處理器針對移動和企業(yè)計算應(yīng)用，包括計算密集型64位應(yīng)用，如高端計算機、平板電腦和服務(wù)器產(chǎn)品。它可以與Cortex-A53處理器一起采用 big.LITTLE技術(shù)（有的也稱為異步多核架構(gòu)）成為一個處理器。

ARMv8-A體系結(jié)構(gòu)引入了許多更改，這些更改使得可以設(shè)計性能明顯更高的處理器實現(xiàn)：

• 更大的物理地址尋址能力：處理器可以訪問超過4GB的物理內(nèi)存。
• 64位虛擬尋址：這樣可以使虛擬內(nèi)存超過4GB的限制。這對于使用內(nèi)存映射文件I / O或稀疏尋址的現(xiàn)代臺式機和服務(wù)器軟件很重要。
• 自動事件信號：利于實現(xiàn)低功耗、高性能的自旋鎖。
• 更大寄存器文件：31個64位通用寄存器可提高性能并減少棧開銷。
• 高效的64位立即數(shù)生成：較少對文字池的依賴。
• 更大的PC指針相對尋址空間：+/- 4GB尋址范圍，可在共享庫和與位置無關(guān)的可執(zhí)行文件中進行有效的數(shù)據(jù)尋址。
• 額外的16KB和64KB翻譯顆粒：這樣可以減少轉(zhuǎn)換后備緩沖區(qū)（TLB）的丟失率和頁面遍歷的深度。
• 新的異常模型: 降低了操作系統(tǒng)和管理程序軟件的復(fù)雜性。
• 高效的緩存管理: 用戶空間緩存操作提高了動態(tài)代碼生成效率。使用數(shù)據(jù)高速緩存零指令快速清除數(shù)據(jù)高速緩存。
• 硬件加速密碼器：提高3倍至10倍較好的軟件加密性能。這對于小顆粒的解密和太小而無法有效地卸載到硬件加速器上的加密非常有用，例如https。
• Load-Acquire, Store-Release指令：針對C++11，C11，Java內(nèi)存模型而設(shè)計。它們通過消除顯式的內(nèi)存屏障指令來提高線程安全代碼的性能。
• NEON雙精度浮點高級SIMD：這使SIMD矢量化可以應(yīng)用于更廣泛的算法集，例如科學(xué)計算，高性能計算（HPC）和超級計算機。

上面談到了新的異常模型，這里來看一下具體是指什么：

在ARMv8中，程序運行總是處于四個異常級別之一。在AArch64中，異常級別確定特權(quán)級別，類似于ARMv7中定義的特權(quán)級別。異常級別確定特權(quán)級別，因此在ELn程序?qū)?yīng)于特權(quán)PLn。類似地，n值大于另一個值的異常級別處于較高的異常級別。數(shù)量比另一個少的異常級別被描述為處于較低的異常級別。

異常級別提供了適用于ARMv8架構(gòu)所有運行狀態(tài)的軟件執(zhí)行特權(quán)的邏輯隔離。它類似于計算機科學(xué)中常見的分層保護域概念。

• EL0：普通用戶應(yīng)用程序。
• EL1：操作系統(tǒng)內(nèi)核通常描述為特權(quán)。
• EL2：管理程序(Hypervisor)。
• EL3：底層固件，包括安全監(jiān)視器。

通常，一個軟件（例如應(yīng)用程序，操作系統(tǒng)的內(nèi)核或系統(tǒng)管理程序）占據(jù)一個異常級別。該規(guī)則的一個例外是內(nèi)核內(nèi)虛擬機管理程序，例如KVM，它們在EL2和EL1上都可運行。

可運行在AArch32以及AArch64模式下：

由圖可見：在AArch32模式下，EL0相對于usr 模式，而EL1則相當(dāng)于Svc、Abt、Und、FIQ、IRQ、Sys模式，而EL2則相當(dāng)于Hyp模式。

ARMv8-A提供兩種安全狀態(tài)，即安全和非安全。非安全狀態(tài)也稱為正常模式(normal world)。這使操作系統(tǒng)（OS）與受信任的OS在同一硬件上并行運行，并提供了針對某些軟件攻擊和硬件攻擊的保護。ARM TrustZone技術(shù)使系統(tǒng)可以在普通和安全環(huán)境之間進行分區(qū)。與ARMv7-A架構(gòu)一樣，安全監(jiān)視器充當(dāng)在普通和安全環(huán)境之間移動的網(wǎng)關(guān)。

ARMv8-A 在正常模式下還提供了對虛擬化的支持。從而虛擬機監(jiān)控程序或虛擬機管理器(VMM)代碼可以在系統(tǒng)上運行，并承載多個客戶操作系統(tǒng)。每個客戶操作系統(tǒng)本質(zhì)上都運行在一個虛擬機上。每個操作系統(tǒng)就不會意識到它正在與其他客戶操作系統(tǒng)共享CPU。

ARMv8-A采用通用中斷控制器GIC V3進行中斷分發(fā)控制。

在AArch64中，異常可以是（synchronous exception）同步的，也可以是（ asynchronous exception）異步的。

同步異常：如果異常是在執(zhí)行或試圖執(zhí)行指令流時產(chǎn)生，并且返回地址提供導(dǎo)致該異常指令的詳細(xì)信息，則將其描述為同步異常。

異步異常：異步異常不是由執(zhí)行指令生成的，而返回地址可能并不總是提供導(dǎo)致異常的細(xì)節(jié)。異步異常的來源是IRQ(正常優(yōu)先級中斷)，F(xiàn)IQ(快速中斷)或SError(系統(tǒng)錯誤)。系統(tǒng)錯誤有許多可能的原因，最常見的是異步數(shù)據(jù)中止(例如，由將臟數(shù)據(jù)從緩存線寫到外部內(nèi)存而觸發(fā)的中止)。

啥是GIC？

GIC是一種先進的微控制器總線架構(gòu)(AMBA)和ARM架構(gòu)兼容的系統(tǒng)片上(SoC)外設(shè)。它是一種高性能的、區(qū)域優(yōu)化的中斷控制器，具有芯片上的AMBA總線接口，根據(jù)配置，它符合AMBA高級可擴展接口(AXI)協(xié)議或AMBA AHB-Lite協(xié)議。

這里僅僅參考ARM官方文檔將其中一部分從概念上加以介紹，過多細(xì)節(jié)比較枯燥就不做介紹了，個人認(rèn)為僅需要從概念上去理解一下大致原理即可，沒有必要去進行更深層的挖掘。除非你需要去修改這一層次的代碼。

具體一點來看，GIC的總體框架如下：

• 處理單元Processing element (PE)，也即是核
• 中斷翻譯服務(wù)組件Interrupt Translation Service components (ITS)
• 中斷路由基礎(chǔ)設(shè)施Interrupt Routing Infrastructure (IRI)

比如一個SPI的中斷分發(fā)路由機制如下：

分發(fā)器 Distributor：分發(fā)服務(wù)器執(zhí)行中斷優(yōu)先級排序，并將spi和SGIs分發(fā)到連接到系統(tǒng)中PEs，從而進入CPU處理。如果我們將這些都看成黑盒子，可以簡化理解一下：

對于GICv2與GICv3的主要顯著區(qū)別是GICv3可以支持更多核，GICv3可支持超過8核的處理器。

異常/中斷來了咋辦？

• 對于ARM處理器而言，異常/中斷到來后，處理器對應(yīng)進入不同的處理器模式(FIQ/IRQ/UND/ABT).
• 對于ARM64處理器而言，因為處理器已經(jīng)沒有處理器模式機制了，因此對應(yīng)變成進入何種異常級別(exception level)。處理器復(fù)位時默認(rèn)進入最高級別的exception level，例如如果處理器最高支持的EL是EL2，復(fù)位后系統(tǒng)將處于EL2。對于那些正常通過system call產(chǎn)生的異常，處理器會切換到哪一個exception level這個問題也很好回答，SVC、HVC和SMC將進入處理器設(shè)定的異常級別。

然而對于異常/中斷的處理，說到底還是需要進入相應(yīng)的異常/中斷句柄(process handler)進行處理，那么怎么進入的呢？這里自然就引入了異常向量表了，這里來看看異常向量表在哪里實現(xiàn)的。這里個人認(rèn)為理解一下大致概念也就可以了。

ARM

對于ARMv7而言，位于./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架構(gòu)而言，位于./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

 .section .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，貼上部分代碼

 .pushsection ".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)

總結(jié)一下

對于做嵌入式開發(fā)，尤其需要做底層驅(qū)動開發(fā)的小伙伴們，較深入的理解一下更為底層異常/中斷運行的機制，對于具體驅(qū)動開發(fā)而言是非常有幫助的。本文參考內(nèi)核代碼，以及ARM官方規(guī)格書大致梳理了Linux中斷子系統(tǒng)的基礎(chǔ)概念，以及異常/中斷如何進入到CPU，以及相應(yīng)的入口在哪里實現(xiàn)定義的。后續(xù)為逐步深入分析中斷底層如何建模抽象的，采用自底向上的分析策略進而分析用戶空間的調(diào)用接口，敬請關(guān)注期待。

本文辛苦原創(chuàng)分享，水平所限，文中估計也有蠻多錯誤，希望看到的同學(xué)幫忙指正，如果覺得有價值也請幫忙點贊轉(zhuǎn)發(fā)支持，不勝感激！