演進：從PLIC到AIA的APLIC與IMSIC遷移實踐)
RISC-V 的生態(tài)這兩年確實熱鬧但中斷控制器這塊很多人還停留在 PLIC 時代。我最近把一顆自研核的中斷路徑從傳統(tǒng) PLIC 整體切到了 AIA 規(guī)范下的 APLIC 加 IMSIC過程挺折騰踩了不少坑也把整個架構(gòu)吃透了不少。這篇就把遷移中的設(shè)計思考、寄存器層面的細(xì)節(jié)、軟件適配的難點以及調(diào)試中遇到的一些詭異問題整理出來給正在做 RISC-V 中斷方案選型或者準(zhǔn)備遷移的朋友一個參考。1. 為什么要從 PLIC 遷到 AIA老架構(gòu)的四個天花板先說結(jié)論如果只是做個簡單的 MCU 或者單核、低中斷數(shù)量的場景PLIC 完全夠用沒必要折騰 AIA。但如果你在做多核應(yīng)用處理器、邊緣計算芯片或者要給虛擬化方案做鋪墊PLIC 的短板會越來越明顯。1.1 多核中斷負(fù)載均衡的缺失PLIC 的設(shè)計模式是典型的全局中斷分發(fā)器。它維護了一張中斷源到目標(biāo) hart 的映射表通過priority、enable、threshold、claim/complete這一套機制來分發(fā)中斷。問題是這個分發(fā)邏輯是集中式的所有核的中斷請求都匯聚到一個 PLIC 實例上由軟件通過配置寄存器決定由哪個 hart 來處理。而且老 PLIC 的仲裁粒度很粗。它只能在“把某個中斷源固定分配給某個 hart”這個層面做靜態(tài)路由做不到像 ARM GIC 那樣按優(yōu)先級動態(tài)把中斷負(fù)載分?jǐn)偟蕉鄠€核上。多核跑 Linux 的時候如果大量外設(shè)中斷都路由到 CPU0CPU0 的軟中斷處理壓力會非常大其他核卻閑著。1.2 虛擬化支持先天不足PLIC 本身就是為裸機或簡單 RTOS 設(shè)計的它只知道物理中斷源不理解虛擬中斷的概念。虛擬化場景下虛擬機里的驅(qū)動直接操作 PLIC 寄存器會產(chǎn)生語義沖突Guest 認(rèn)為自己在 claim 中斷實際上 claim 的是物理中斷這會直接導(dǎo)致中斷狀態(tài)機錯亂。要支持虛擬化就得在 Hypervisor 層面做大量 Trap-and-Emulate 的軟件補丁性能損耗極大。AIA 架構(gòu)里專門針對虛擬化做了設(shè)計IMSIC 支持按照vgeinvirtual guest external interrupt number來區(qū)分不同虛擬機的 MSI 中斷。硬件幫你把中斷按虛擬機隔離好Hypervisor 只需要做輕量級的轉(zhuǎn)發(fā)。1.3 中斷編號空間與可擴展性限制PLIC 支持的中斷源數(shù)量是有限的一般幾十到一百多個而且每個中斷源的上下文context有限。當(dāng) SoC 里集成的外設(shè)越來越多比如多個 PCIe 控制器、GPU、AI 加速器每個都有大量 MSI/MSI-X 中斷需求時PLIC 的中斷源數(shù)量會成為硬瓶頸。AIA 用對 MSI 的可編程路由天然解決這個問題每個設(shè)備可以分配獨立的 MSI 向量中斷數(shù)量上限非常高。IMSIC 每個 hart 有獨立的msi address空間基于index的尋址方式讓中斷號可以做到非常大比如 2048 個 per-hart而且可以按需擴展。1.4 中斷延遲和上下文開銷PLIC 的 claim/complete 流程需要訪問兩個不同的寄存器組期間有鎖的開銷而且不支持硬件自動屏蔽同源中斷需要軟件主動處理。在 Linux 這類 OS 里PLIC 驅(qū)動通常會啟用標(biāo)準(zhǔn)的 IRQ chip 回調(diào)配合handle_cascade_irq做軟件重分發(fā)而這同樣會引入額外的延遲。IMSIC 的 MSI 投遞路徑更直接外設(shè)寫一個 MSI 地址IMSIC 直接把中斷掛到目標(biāo) hart 的中斷 pending 隊列上。沒有集中式仲裁的往返時間也不需要軟件查表決定給哪個核延遲表現(xiàn)會比 PLIC 好一截。當(dāng)然這個延遲差異在小系統(tǒng)里不明顯高負(fù)載下才體現(xiàn)得出來。2. AIA 架構(gòu)核心概念A(yù)PLIC 與 IMSIC 的分工邏輯AIA 架構(gòu)把傳統(tǒng) PLIC 的活拆成了兩部分APLIC 管“線控中斷”IMSIC 管“消息中斷”。這兩個組件通過一組新增的 CSR 和異常碼與操作系統(tǒng)交互理解它們的分工是后面做遷移的基礎(chǔ)。2.1 APLIC承上啟下的線控中斷控制器APLICAdvanced Platform Level Interrupt Controller可以理解為 PLIC 的增強版但在架構(gòu)上做了大改。它的定位是處理“基于電平/脈沖的線控中斷源”包括GPIO、UART、I2C、SPI 等外設(shè)的中斷請求線。APLIC 支持兩種中斷投遞模式Direct mode直通模式APLIC 直接把線控中斷轉(zhuǎn)成中斷信號發(fā)給目標(biāo) hart。這和傳統(tǒng) PLIC 比較像但格式和中斷號映射規(guī)則變了。MSI mode消息中斷模式APLIC 收到線控中斷后由硬件根據(jù)配置好的目標(biāo)地址產(chǎn)生一個 MSI 寫操作發(fā)送到對應(yīng)的 IMSIC 或者外部 MSI 控制器。這個模式下APLIC 本質(zhì)上是把一個電平信號“翻譯”成一個 MSI 報文。這里要注意APLIC 和 PLIC 一個關(guān)鍵區(qū)別在于中斷號的分配。傳統(tǒng) PLIC 用全局中斷源 ID比如interrupt id 33對應(yīng)某個外設(shè)軟件直接按這個 ID 操作寄存器。AIA 中進入 IMSIC 的是一組基于域的index線控中斷經(jīng)過 APLIC 的處理后在 MSI mode 下會被賦予一個 IMSIC 域中的中斷號這個號由軟件在初始化時通過配置 APLIC 的 sourcecfg 寄存器來設(shè)定。2.2 IMSIC每核獨立的消息中斷控制器IMSICIncoming MSI Controller是 AIA 引入的重頭戲。每個 hart 都有一個自己的 IMSIC 實例它只負(fù)責(zé)接收發(fā)送給自己的 MSI 中斷并維護一個本地的待處理中斷隊列。IMSIC 有幾個關(guān)鍵特點第一每個中斷使用guest index和virtual index兩個維度來區(qū)分。物理中斷使用index來標(biāo)識虛擬中斷額外加上guest index。這樣多個虛擬機可以共享同一個物理 IMSIC但各自維護自己的虛擬中斷表。這個設(shè)計直擊虛擬化痛點。第二IMSIC 的中斷使能和優(yōu)先級的維護方式完全不同。PLIC 里的每個中斷源有獨立的 enable bit 和 priority 寄存器IMSIC 則是通過一組setipnum、setie_num寄存器來觸發(fā)或屏蔽中斷。中斷的優(yōu)先級由軟件寫入中斷文件interrupt file對應(yīng)索引位置的優(yōu)先級值來決定。第三中斷的 claim/complete 流程改成了基于getipnum寄存器。軟件讀取getipnum會同時獲得最高優(yōu)先級待處理中斷的編號并自動將其標(biāo)記為 in-service軟件寫入getipnum則完成中斷處理。這個流程比 PLIC 的 claim/complete 兩次寄存器訪問更高效。2.3 AIA 新增的 CSR 和異常碼遷移中繞不開的是新增的 CSR。AIA 在原有CSR 0xbc0mstatus中的MIE等已有位之外定義了0x7c0mintstatusMachine Interrupt Translation Status0x7c1mintthreshMachine Interrupt Translation Threshold0x7c2mintvecMachine Interrupt Translation Vector0xbc0擴展了mstatus的MPIE、MPP等原有字段之外還新增了MPV等用于虛擬化的位。異常碼方面AIA 定義了一個新的 trap 原因碼外部中斷Guest External Interrupt在mcause中編碼為 13之前 PLIC 使用的是 Supervisor External Interrupt 11。同時為虛擬化增加了vsinterrupt對應(yīng)的原因碼。這要求在異常向量表里新增對應(yīng)的處理入口。注意老的 PLIC 驅(qū)動里cause 16的判斷邏輯要小心處理AIA 下中斷原因碼從 12 開始就出現(xiàn)了新的含義直接用 mask 判斷會踩坑。3. 遷移實戰(zhàn)硬件側(cè)寄存器配置和中斷路由初始化這一節(jié)是全文的核心干貨。我按照實際項目的遷移順序從硬件初始化、中斷路由配置到驅(qū)動適配逐步展開。3.1 初始化 APLIC 的寄存器序列APLIC 初始化時首先要根據(jù) SoC 的中斷源布局規(guī)劃好中斷號。在 AIA 規(guī)范中APLIC 的寄存器布局和 PLIC 完全不同它使用了一套基于偏移的sourcecfg、domaincfg、target寄存器。以我的項目為例SoC 里有 64 個線控中斷源系統(tǒng)有 4 個 hart。在這里我接一個典型的初始化配置過程#define APLIC_BASE_ADDR 0x0C000000 #define APLIC_SOURCECFG_BASE 0x0000 #define APLIC_DOMAINCFG 0x0004 #define APLIC_TARGET_BASE 0x1000 void aplic_init(void) { uint32_t i; uint32_t base APLIC_BASE_ADDR; // 1. 配置全局域使能 APLIC writel(0x1, base APLIC_DOMAINCFG); // 2. 對每個中斷源設(shè)置目標(biāo) hart 和優(yōu)先級 for (i 0; i 64; i) { // 將中斷源 i 路由到 hart 0使用中斷號 i1 // 高 16 位寫入 target hart低 16 位寫入 interrupt id index writel((0x0 16) | (i 1), base APLIC_TARGET_BASE (i * 4)); } // 3. 每個中斷源使能 for (i 0; i 64; i) { writel(0x1, base APLIC_SOURCECFG_BASE (i * 4)); } }這里和 PLIC 最大的區(qū)別是target寄存器的設(shè)置。PLIC 時代你需要在enable寄存器矩陣中把對應(yīng) hart 的 bit 置 1而且中斷源的 ID 是固定的。AIA 里每個中斷源通過獨立的 target 寄存器指定目標(biāo) hart域內(nèi)和該中斷源在此 hart 上對應(yīng)的index靈活度高了很多。每個中斷源的使能也在sourcecfg寄存器中完成而不是在獨立的 enable 寄存器中。所以初始化時要注意sourcecfg是“先配置、后使能”的順序如果先把所有中斷源都使能了再改 target可能導(dǎo)致中斷亂飛。3.2 IMSIC 地址翻譯與路由配置IMSIC 的配置核心是建立一個從 MSI 地址到具體中斷索引的映射關(guān)系。AIA 規(guī)定IMSIC 的 MMIO 地址空間按guest index和hart index分頁。每個 hart 的 IMSIC 區(qū)域可以看到2 * (num_guest_index 1)個 4KB 頁面物理和虛擬中斷各自有獨立的 4KB 窗口。我的項目中IMSIC 基址為0x24000000每個 hart 的 IMSIC 占 4096 字節(jié)中斷索引范圍是 0 到 2047。#define IMSIC_BASE_ADDR 0x24000000 #define IMSIC_HART0_OFFSET 0x0 #define IMSIC_SETIPNUM_OFF 0x0 #define IMSIC_GETIPNUM_OFF 0x0 #define IMSIC_SETIE_NUM_OFF 0x10 #define IMSIC_MAX_INDEX 2047 void imsic_init(void) { uint32_t base IMSIC_BASE_ADDR IMSIC_HART0_OFFSET; int i; // 1. 讀取 IMSIC 的版本和特性確認(rèn)支持的最大 index uint32_t ver readl(base 0xFFC); // 按需校驗中斷數(shù)量 // 2. 設(shè)置中斷文件的閾值對應(yīng)每個索引的優(yōu)先級 // 這里通過 setie_num 寄存器逐一配置 for (i 0; i IMSIC_MAX_INDEX; i) { // 配置優(yōu)先級為默認(rèn)值 0x42345678 (avg) writel(0x42345678, base IMSIC_SETIE_NUM_OFF (i * 4)); } }這里要注意一個細(xì)節(jié)setie_num寄存器不只是設(shè)置使能它實際上是把一個 32 位的interrupt file entry寫入到指定索引的文件條目中其中高 16 位是優(yōu)先級低 16 位是控制位。這個設(shè)計和 PLIC 單獨設(shè)置 priority 寄存器的方式完全不同容易弄混。3.3 從 PLIC 到 AIA 的中斷向量表和入口改寫中斷向量表的改動可能是遷移中最需要小心的部分。PLIC 時代mtvec或stvec指向一個統(tǒng)一入口在 trap handler 里通過讀取mcause判斷中斷類型如果是外部中斷再去讀 PLIC claim 寄存器獲取中斷號。AIA 的改動點第一trap 原因碼變了。在 AIA 之前外部中斷的mcause值如下機器模式外部中斷是 11監(jiān)督模式外部中斷是 9虛擬化場景外部中斷是 13。實際上 AIA 規(guī)范中引入了新的 trap 原因Guest External Interrupt編碼為 13。在mcause判斷時不能再用傳統(tǒng)的cause 0x1F簡單區(qū)分了。第二AIA 模式下正常的機器模式外部中斷的mcause仍然是 11但如果有虛擬化Guest 的外部中斷會走 13。如果 Hypervisor 不特殊處理Guest 的中斷會直接泄漏到 Host。所以異常向量表里11 和 13 的入口都要單獨處理。我實際修改的中斷入口部分邏輯如下void trap_handler(uint64_t mcause, uint64_t mepc, uint64_t mtval) { uint64_t cause mcause 0x1F; uint64_t is_interrupt (mcause 63) 0x1; if (is_interrupt) { switch (cause) { case 11: // Machine External Interrupt handle_machine_external(); break; case 13: // Guest External Interrupt虛擬化場景 handle_guest_external(); break; default: handle_other_interrupt(cause); } } else { // 異常處理 do_exception(cause, mepc, mtval); } }這里有個容易踩的坑在 AIA 規(guī)范下mcause的最高位63 位代表中斷/異常標(biāo)志但標(biāo)準(zhǔn) RISC-V 中mcause是一個 XLEN 位的 CSR處理時最好把第 63 位拿出來判斷不要直接和0x800000000000000B這類常量比較否則 32 位和 64 位模式下容易出錯。3.4 AIA 中斷的軟件處理和平臺設(shè)備的中斷映射硬件寄存器配好后軟件邏輯也要跟著變。PLIC 時代的中斷處理函數(shù)長這樣irq plic_claim(); // 讀 claim 寄存器 handle_irq(irq); // 處理中斷 plic_complete(irq); // 寫 complete 寄存器AIA 下IMSIC 的處理流程是irq imsic_get(); // 讀 getipnum 寄存器返回最高優(yōu)先級待處理中斷的 index handle_irq(irq); // 處理 // 寫 getipnum 時寫入要完成的中斷編號或者讀一次也會觸發(fā)完成其實這里要比 PLIC 方便因為getipnum的讀操作本身就會返回一個中斷 ID 并自動完成硬件級別的中斷屏蔽而寫getipnum則完成中斷嵌套的優(yōu)先級恢復(fù)。Linux 內(nèi)核的 IRQ 子系統(tǒng)適配中要重點修改irq_chip的回調(diào)static struct irq_chip imsic_irq_chip { .name IMSIC, .irq_mask imsic_mask, .irq_unmask imsic_unmask, .irq_eoi imsic_eoi, .irq_set_affinity imsic_set_affinity, };imsic_eoi回調(diào)里需要讀取getipnum或者寫getipnum來告知控制器中斷處理完成。但要注意getipnum是個“讀即清”的寄存器在 EOI 里千萬別先讀一次用于調(diào)試再寫一次否則第一次讀就把中斷清了第二次寫反而會觸發(fā)一個未處理中斷。4. 驅(qū)動遷移過程中的常見問題與排查技巧這一部分記錄的是我在實際遷移中遇到的幾個坑按概率排序最后一個問題排查了整整兩天。4.1 中斷號映射錯亂APLIC 和 IMSIC 的 index 對齊這是遷移中最容易遇到的問題。在 PLIC 里傳統(tǒng)做法是直接把中斷源 ID 作為 Linux IRQ number簡單粗暴。在 ABI 中APLIC 的線控中斷源經(jīng)過翻譯后會得到一個 index這個 index 在 IMSIC 域內(nèi)是一個稀疏分布的值不一定從 0 開始連續(xù)排列。如果板級設(shè)備樹里寫的中斷號和設(shè)備驅(qū)動里注冊時使用的中斷號不一致要么中斷觸發(fā)后軟件 Acknowledge 了錯誤的中斷要么中斷永遠(yuǎn) no one care設(shè)備一直 busy poll。我們的項目里APLIC 的target寄存器就設(shè)定了 index 和好如果兩個設(shè)備配置成相同的 index后配的那個會把先配的覆蓋掉。解決辦法每個中斷源在設(shè)備樹里聲明時需要開辟獨立的interrupts屬性并且確保 APLIC target 寄存器里寫入的就是這個中斷號不能復(fù)用。4.2 非 MSI 外設(shè)中斷在虛擬化下丟失在虛擬化場景如果虛擬機的設(shè)備是直通的它發(fā)送的是真正的 MSI沒問題。但傳統(tǒng)線控中斷APLIC 翻譯成 MSI 后送到哪個 IMSIC 的哪個 guest index需要軟件提前配置好guest index和 pending 文件。我遇到的一次 Bug 是虛擬機里的 UART 中斷Host 能收到但 Guest 永遠(yuǎn)收不到。排查后發(fā)現(xiàn)IMSIC 的 guest 中斷需要單獨開啟對應(yīng) guest index 的中斷文件使能位而且要在mintstatus里使能對應(yīng)的 guest 外部中斷轉(zhuǎn)發(fā)通道。等到把 guest index 對應(yīng)的一組寄存器全配好中斷才能正常注入。4.3 IMSIC 的 EOI 時機導(dǎo)致中斷風(fēng)暴在一個網(wǎng)絡(luò)驅(qū)動的壓力測試中出現(xiàn)了持續(xù)不斷的中斷風(fēng)暴CPU 占用率直接被打滿。后來發(fā)現(xiàn)原因是外設(shè)中斷觸發(fā)后IMSIC 的getipnum會自動 pending 當(dāng)前最高優(yōu)先級中斷但如果軟件在 EOI 之前就重新使能了該中斷源外設(shè)狀態(tài)沒有真正清掉就會立刻再次觸發(fā)中斷形成風(fēng)暴。解決辦法是在中斷處理函數(shù)的最后才寫 EOI而且要先屏蔽中斷源等外設(shè)狀態(tài)清理完畢再解除屏蔽。這個順序不能反反了就會丟中斷或者風(fēng)暴。4.4mret時機與mstatus.MPIE的交互這個問題比較隱蔽。在 PLIC 時代mret之后中斷是否重新可以觸發(fā)取決于mstatus.MPIE置位情況。AIA 引入了mintstatus之后多了一層翻譯狀態(tài)。如果mintstatus中的某個位沒有正確清除mret之后新中斷沒有辦法被響應(yīng)表現(xiàn)就是“中斷只進來一次之后就再也進不來了”。排查方式在 trap 返回之前打印mintstatus的值對比正常和異常兩種情況能很快定位到是不是因為 missing EOI 或者MINTSTATUS_MI位卡住了。4.5 排查工具建議遷移和調(diào)試過程中我發(fā)現(xiàn)純靠打印效率太低。推薦幾個輔助手段OpenSBI 的 DT 掃描OpenSBI 已經(jīng)支持 APLIC/IMSIC 的初始化用它先驗證硬件寄存器讀寫是否正確。JTAG 直接讀 IMSIC 寄存器如果 SoC 的 JTAG 能看到 IMSIC 映射的 4KB 窗口直接讀getipnum看中斷是否有 pending。/perf 中斷事件Linux 下用perf stat -e irq:irq_handler_entry看中斷頻率如果中斷風(fēng)暴這里數(shù)字會非常嚇人。邏輯分析儀抓外設(shè) IRQ 線確認(rèn) APLIC 的輸入側(cè)信號確實翻轉(zhuǎn)排除外設(shè)側(cè)的問題。5. 我對這次遷移的一些總結(jié)和想法整個遷移過程下來我的一個直接感受是AIA 不是 PLIC 的簡單升級版它是一套為虛擬化和大規(guī)模多核設(shè)計的中斷分發(fā)體系。PLIC 的設(shè)計哲學(xué)是“集中管理分散響應(yīng)”所有中斷源匯聚到一個控制器再分發(fā)到各個 hart。AIA 的設(shè)計哲學(xué)是“源頭翻譯本地處理”線控中斷在 APLIC 做一次翻譯變成 MSI 后直接投遞到目標(biāo) IMSIC由目標(biāo)核本地處理中間少了集中仲裁的開銷。 這也意味著驅(qū)動開發(fā)者的思維方式需要跟著變從“操作一堆全局寄存器”轉(zhuǎn)向“配置好翻譯路徑然后按文件和索引操作”。從性能角度講IMSIC 的直投模式延遲確實比 PLIC 低特別是在開啟了 MSI 的內(nèi)核里UART、網(wǎng)卡這些中斷源的響應(yīng)時間都有可感知的下降。不過如果要拿數(shù)值吹牛需要在相同主頻、相同外設(shè)負(fù)載下做 A/B 對比單純從架構(gòu)推導(dǎo)延遲低多少并不嚴(yán)謹(jǐn)。從可維護性看AIA 的配置項比 PLIC 多對軟件初始化代碼的編寫要求更高。但一旦配好中斷路由的靈活性遠(yuǎn)超 PLIC。特別是做多核負(fù)載均衡時可以在運行時動態(tài)調(diào)整 APLIC 的 target 寄存器把不同外設(shè)中斷按負(fù)載重新路由到不同的核這在 PLIC 時代是做不到的。如果讓我給正在評估遷移的朋友一句話建議如果只是單核裸機跑外設(shè)PLIC 別動如果已經(jīng)在做或者準(zhǔn)備做雙核以上 Linux或者有虛擬化規(guī)劃那從 IP 選型階段就把 APLIC IMSIC 方案納入省得后續(xù)從 PLIC 遷移過來重寫驅(qū)動。最后再分享一個小技巧調(diào)試 APLIC 時利用它的domaincfg寄存器里的BIGEND字節(jié)序位可以切換寄存器的字節(jié)序在大小端混合的 SoC 里核對寄存器讀寫邏輯很管用。這個在規(guī)格書里很容易被忽略但排查硬件描述和軟件訪問字節(jié)序不一致時能省下至少半天時間。 RISC-V中斷架構(gòu)演進：從PLIC到AIA的APLIC與IMSIC遷移實踐
RISC-V 的生態(tài)這兩年確實熱鬧但中斷控制器這塊很多人還停留在 PLIC 時代。我最近把一顆自研核的中斷路徑從傳統(tǒng) PLIC 整體切到了 AIA 規(guī)范下的 APLIC 加 IMSIC過程挺折騰踩了不少坑也把整個架構(gòu)吃透了不少。這篇就把遷移中的設(shè)計思考、寄存器層面的細(xì)節(jié)、軟件適配的難點以及調(diào)試中遇到的一些詭異問題整理出來給正在做 RISC-V 中斷方案選型或者準(zhǔn)備遷移的朋友一個參考。1. 為什么要從 PLIC 遷到 AIA老架構(gòu)的四個天花板先說結(jié)論如果只是做個簡單的 MCU 或者單核、低中斷數(shù)量的場景PLIC 完全夠用沒必要折騰 AIA。但如果你在做多核應(yīng)用處理器、邊緣計算芯片或者要給虛擬化方案做鋪墊PLIC 的短板會越來越明顯。1.1 多核中斷負(fù)載均衡的缺失PLIC 的設(shè)計模式是典型的全局中斷分發(fā)器。它維護了一張中斷源到目標(biāo) hart 的映射表通過priority、enable、threshold、claim/complete這一套機制來分發(fā)中斷。問題是這個分發(fā)邏輯是集中式的所有核的中斷請求都匯聚到一個 PLIC 實例上由軟件通過配置寄存器決定由哪個 hart 來處理。而且老 PLIC 的仲裁粒度很粗。它只能在“把某個中斷源固定分配給某個 hart”這個層面做靜態(tài)路由做不到像 ARM GIC 那樣按優(yōu)先級動態(tài)把中斷負(fù)載分?jǐn)偟蕉鄠€核上。多核跑 Linux 的時候如果大量外設(shè)中斷都路由到 CPU0CPU0 的軟中斷處理壓力會非常大其他核卻閑著。1.2 虛擬化支持先天不足PLIC 本身就是為裸機或簡單 RTOS 設(shè)計的它只知道物理中斷源不理解虛擬中斷的概念。虛擬化場景下虛擬機里的驅(qū)動直接操作 PLIC 寄存器會產(chǎn)生語義沖突Guest 認(rèn)為自己在 claim 中斷實際上 claim 的是物理中斷這會直接導(dǎo)致中斷狀態(tài)機錯亂。要支持虛擬化就得在 Hypervisor 層面做大量 Trap-and-Emulate 的軟件補丁性能損耗極大。AIA 架構(gòu)里專門針對虛擬化做了設(shè)計IMSIC 支持按照vgeinvirtual guest external interrupt number來區(qū)分不同虛擬機的 MSI 中斷。硬件幫你把中斷按虛擬機隔離好Hypervisor 只需要做輕量級的轉(zhuǎn)發(fā)。1.3 中斷編號空間與可擴展性限制PLIC 支持的中斷源數(shù)量是有限的一般幾十到一百多個而且每個中斷源的上下文context有限。當(dāng) SoC 里集成的外設(shè)越來越多比如多個 PCIe 控制器、GPU、AI 加速器每個都有大量 MSI/MSI-X 中斷需求時PLIC 的中斷源數(shù)量會成為硬瓶頸。AIA 用對 MSI 的可編程路由天然解決這個問題每個設(shè)備可以分配獨立的 MSI 向量中斷數(shù)量上限非常高。IMSIC 每個 hart 有獨立的msi address空間基于index的尋址方式讓中斷號可以做到非常大比如 2048 個 per-hart而且可以按需擴展。1.4 中斷延遲和上下文開銷PLIC 的 claim/complete 流程需要訪問兩個不同的寄存器組期間有鎖的開銷而且不支持硬件自動屏蔽同源中斷需要軟件主動處理。在 Linux 這類 OS 里PLIC 驅(qū)動通常會啟用標(biāo)準(zhǔn)的 IRQ chip 回調(diào)配合handle_cascade_irq做軟件重分發(fā)而這同樣會引入額外的延遲。IMSIC 的 MSI 投遞路徑更直接外設(shè)寫一個 MSI 地址IMSIC 直接把中斷掛到目標(biāo) hart 的中斷 pending 隊列上。沒有集中式仲裁的往返時間也不需要軟件查表決定給哪個核延遲表現(xiàn)會比 PLIC 好一截。當(dāng)然這個延遲差異在小系統(tǒng)里不明顯高負(fù)載下才體現(xiàn)得出來。2. AIA 架構(gòu)核心概念A(yù)PLIC 與 IMSIC 的分工邏輯AIA 架構(gòu)把傳統(tǒng) PLIC 的活拆成了兩部分APLIC 管“線控中斷”IMSIC 管“消息中斷”。這兩個組件通過一組新增的 CSR 和異常碼與操作系統(tǒng)交互理解它們的分工是后面做遷移的基礎(chǔ)。2.1 APLIC承上啟下的線控中斷控制器APLICAdvanced Platform Level Interrupt Controller可以理解為 PLIC 的增強版但在架構(gòu)上做了大改。它的定位是處理“基于電平/脈沖的線控中斷源”包括GPIO、UART、I2C、SPI 等外設(shè)的中斷請求線。APLIC 支持兩種中斷投遞模式Direct mode直通模式APLIC 直接把線控中斷轉(zhuǎn)成中斷信號發(fā)給目標(biāo) hart。這和傳統(tǒng) PLIC 比較像但格式和中斷號映射規(guī)則變了。MSI mode消息中斷模式APLIC 收到線控中斷后由硬件根據(jù)配置好的目標(biāo)地址產(chǎn)生一個 MSI 寫操作發(fā)送到對應(yīng)的 IMSIC 或者外部 MSI 控制器。這個模式下APLIC 本質(zhì)上是把一個電平信號“翻譯”成一個 MSI 報文。這里要注意APLIC 和 PLIC 一個關(guān)鍵區(qū)別在于中斷號的分配。傳統(tǒng) PLIC 用全局中斷源 ID比如interrupt id 33對應(yīng)某個外設(shè)軟件直接按這個 ID 操作寄存器。AIA 中進入 IMSIC 的是一組基于域的index線控中斷經(jīng)過 APLIC 的處理后在 MSI mode 下會被賦予一個 IMSIC 域中的中斷號這個號由軟件在初始化時通過配置 APLIC 的 sourcecfg 寄存器來設(shè)定。2.2 IMSIC每核獨立的消息中斷控制器IMSICIncoming MSI Controller是 AIA 引入的重頭戲。每個 hart 都有一個自己的 IMSIC 實例它只負(fù)責(zé)接收發(fā)送給自己的 MSI 中斷并維護一個本地的待處理中斷隊列。IMSIC 有幾個關(guān)鍵特點第一每個中斷使用guest index和virtual index兩個維度來區(qū)分。物理中斷使用index來標(biāo)識虛擬中斷額外加上guest index。這樣多個虛擬機可以共享同一個物理 IMSIC但各自維護自己的虛擬中斷表。這個設(shè)計直擊虛擬化痛點。第二IMSIC 的中斷使能和優(yōu)先級的維護方式完全不同。PLIC 里的每個中斷源有獨立的 enable bit 和 priority 寄存器IMSIC 則是通過一組setipnum、setie_num寄存器來觸發(fā)或屏蔽中斷。中斷的優(yōu)先級由軟件寫入中斷文件interrupt file對應(yīng)索引位置的優(yōu)先級值來決定。第三中斷的 claim/complete 流程改成了基于getipnum寄存器。軟件讀取getipnum會同時獲得最高優(yōu)先級待處理中斷的編號并自動將其標(biāo)記為 in-service軟件寫入getipnum則完成中斷處理。這個流程比 PLIC 的 claim/complete 兩次寄存器訪問更高效。2.3 AIA 新增的 CSR 和異常碼遷移中繞不開的是新增的 CSR。AIA 在原有CSR 0xbc0mstatus中的MIE等已有位之外定義了0x7c0mintstatusMachine Interrupt Translation Status0x7c1mintthreshMachine Interrupt Translation Threshold0x7c2mintvecMachine Interrupt Translation Vector0xbc0擴展了mstatus的MPIE、MPP等原有字段之外還新增了MPV等用于虛擬化的位。異常碼方面AIA 定義了一個新的 trap 原因碼外部中斷Guest External Interrupt在mcause中編碼為 13之前 PLIC 使用的是 Supervisor External Interrupt 11。同時為虛擬化增加了vsinterrupt對應(yīng)的原因碼。這要求在異常向量表里新增對應(yīng)的處理入口。注意老的 PLIC 驅(qū)動里cause 16的判斷邏輯要小心處理AIA 下中斷原因碼從 12 開始就出現(xiàn)了新的含義直接用 mask 判斷會踩坑。3. 遷移實戰(zhàn)硬件側(cè)寄存器配置和中斷路由初始化這一節(jié)是全文的核心干貨。我按照實際項目的遷移順序從硬件初始化、中斷路由配置到驅(qū)動適配逐步展開。3.1 初始化 APLIC 的寄存器序列APLIC 初始化時首先要根據(jù) SoC 的中斷源布局規(guī)劃好中斷號。在 AIA 規(guī)范中APLIC 的寄存器布局和 PLIC 完全不同它使用了一套基于偏移的sourcecfg、domaincfg、target寄存器。以我的項目為例SoC 里有 64 個線控中斷源系統(tǒng)有 4 個 hart。在這里我接一個典型的初始化配置過程#define APLIC_BASE_ADDR 0x0C000000 #define APLIC_SOURCECFG_BASE 0x0000 #define APLIC_DOMAINCFG 0x0004 #define APLIC_TARGET_BASE 0x1000 void aplic_init(void) { uint32_t i; uint32_t base APLIC_BASE_ADDR; // 1. 配置全局域使能 APLIC writel(0x1, base APLIC_DOMAINCFG); // 2. 對每個中斷源設(shè)置目標(biāo) hart 和優(yōu)先級 for (i 0; i 64; i) { // 將中斷源 i 路由到 hart 0使用中斷號 i1 // 高 16 位寫入 target hart低 16 位寫入 interrupt id index writel((0x0 16) | (i 1), base APLIC_TARGET_BASE (i * 4)); } // 3. 每個中斷源使能 for (i 0; i 64; i) { writel(0x1, base APLIC_SOURCECFG_BASE (i * 4)); } }這里和 PLIC 最大的區(qū)別是target寄存器的設(shè)置。PLIC 時代你需要在enable寄存器矩陣中把對應(yīng) hart 的 bit 置 1而且中斷源的 ID 是固定的。AIA 里每個中斷源通過獨立的 target 寄存器指定目標(biāo) hart域內(nèi)和該中斷源在此 hart 上對應(yīng)的index靈活度高了很多。每個中斷源的使能也在sourcecfg寄存器中完成而不是在獨立的 enable 寄存器中。所以初始化時要注意sourcecfg是“先配置、后使能”的順序如果先把所有中斷源都使能了再改 target可能導(dǎo)致中斷亂飛。3.2 IMSIC 地址翻譯與路由配置IMSIC 的配置核心是建立一個從 MSI 地址到具體中斷索引的映射關(guān)系。AIA 規(guī)定IMSIC 的 MMIO 地址空間按guest index和hart index分頁。每個 hart 的 IMSIC 區(qū)域可以看到2 * (num_guest_index 1)個 4KB 頁面物理和虛擬中斷各自有獨立的 4KB 窗口。我的項目中IMSIC 基址為0x24000000每個 hart 的 IMSIC 占 4096 字節(jié)中斷索引范圍是 0 到 2047。#define IMSIC_BASE_ADDR 0x24000000 #define IMSIC_HART0_OFFSET 0x0 #define IMSIC_SETIPNUM_OFF 0x0 #define IMSIC_GETIPNUM_OFF 0x0 #define IMSIC_SETIE_NUM_OFF 0x10 #define IMSIC_MAX_INDEX 2047 void imsic_init(void) { uint32_t base IMSIC_BASE_ADDR IMSIC_HART0_OFFSET; int i; // 1. 讀取 IMSIC 的版本和特性確認(rèn)支持的最大 index uint32_t ver readl(base 0xFFC); // 按需校驗中斷數(shù)量 // 2. 設(shè)置中斷文件的閾值對應(yīng)每個索引的優(yōu)先級 // 這里通過 setie_num 寄存器逐一配置 for (i 0; i IMSIC_MAX_INDEX; i) { // 配置優(yōu)先級為默認(rèn)值 0x42345678 (avg) writel(0x42345678, base IMSIC_SETIE_NUM_OFF (i * 4)); } }這里要注意一個細(xì)節(jié)setie_num寄存器不只是設(shè)置使能它實際上是把一個 32 位的interrupt file entry寫入到指定索引的文件條目中其中高 16 位是優(yōu)先級低 16 位是控制位。這個設(shè)計和 PLIC 單獨設(shè)置 priority 寄存器的方式完全不同容易弄混。3.3 從 PLIC 到 AIA 的中斷向量表和入口改寫中斷向量表的改動可能是遷移中最需要小心的部分。PLIC 時代mtvec或stvec指向一個統(tǒng)一入口在 trap handler 里通過讀取mcause判斷中斷類型如果是外部中斷再去讀 PLIC claim 寄存器獲取中斷號。AIA 的改動點第一trap 原因碼變了。在 AIA 之前外部中斷的mcause值如下機器模式外部中斷是 11監(jiān)督模式外部中斷是 9虛擬化場景外部中斷是 13。實際上 AIA 規(guī)范中引入了新的 trap 原因Guest External Interrupt編碼為 13。在mcause判斷時不能再用傳統(tǒng)的cause 0x1F簡單區(qū)分了。第二AIA 模式下正常的機器模式外部中斷的mcause仍然是 11但如果有虛擬化Guest 的外部中斷會走 13。如果 Hypervisor 不特殊處理Guest 的中斷會直接泄漏到 Host。所以異常向量表里11 和 13 的入口都要單獨處理。我實際修改的中斷入口部分邏輯如下void trap_handler(uint64_t mcause, uint64_t mepc, uint64_t mtval) { uint64_t cause mcause 0x1F; uint64_t is_interrupt (mcause 63) 0x1; if (is_interrupt) { switch (cause) { case 11: // Machine External Interrupt handle_machine_external(); break; case 13: // Guest External Interrupt虛擬化場景 handle_guest_external(); break; default: handle_other_interrupt(cause); } } else { // 異常處理 do_exception(cause, mepc, mtval); } }這里有個容易踩的坑在 AIA 規(guī)范下mcause的最高位63 位代表中斷/異常標(biāo)志但標(biāo)準(zhǔn) RISC-V 中mcause是一個 XLEN 位的 CSR處理時最好把第 63 位拿出來判斷不要直接和0x800000000000000B這類常量比較否則 32 位和 64 位模式下容易出錯。3.4 AIA 中斷的軟件處理和平臺設(shè)備的中斷映射硬件寄存器配好后軟件邏輯也要跟著變。PLIC 時代的中斷處理函數(shù)長這樣irq plic_claim(); // 讀 claim 寄存器 handle_irq(irq); // 處理中斷 plic_complete(irq); // 寫 complete 寄存器AIA 下IMSIC 的處理流程是irq imsic_get(); // 讀 getipnum 寄存器返回最高優(yōu)先級待處理中斷的 index handle_irq(irq); // 處理 // 寫 getipnum 時寫入要完成的中斷編號或者讀一次也會觸發(fā)完成其實這里要比 PLIC 方便因為getipnum的讀操作本身就會返回一個中斷 ID 并自動完成硬件級別的中斷屏蔽而寫getipnum則完成中斷嵌套的優(yōu)先級恢復(fù)。Linux 內(nèi)核的 IRQ 子系統(tǒng)適配中要重點修改irq_chip的回調(diào)static struct irq_chip imsic_irq_chip { .name IMSIC, .irq_mask imsic_mask, .irq_unmask imsic_unmask, .irq_eoi imsic_eoi, .irq_set_affinity imsic_set_affinity, };imsic_eoi回調(diào)里需要讀取getipnum或者寫getipnum來告知控制器中斷處理完成。但要注意getipnum是個“讀即清”的寄存器在 EOI 里千萬別先讀一次用于調(diào)試再寫一次否則第一次讀就把中斷清了第二次寫反而會觸發(fā)一個未處理中斷。4. 驅(qū)動遷移過程中的常見問題與排查技巧這一部分記錄的是我在實際遷移中遇到的幾個坑按概率排序最后一個問題排查了整整兩天。4.1 中斷號映射錯亂APLIC 和 IMSIC 的 index 對齊這是遷移中最容易遇到的問題。在 PLIC 里傳統(tǒng)做法是直接把中斷源 ID 作為 Linux IRQ number簡單粗暴。在 ABI 中APLIC 的線控中斷源經(jīng)過翻譯后會得到一個 index這個 index 在 IMSIC 域內(nèi)是一個稀疏分布的值不一定從 0 開始連續(xù)排列。如果板級設(shè)備樹里寫的中斷號和設(shè)備驅(qū)動里注冊時使用的中斷號不一致要么中斷觸發(fā)后軟件 Acknowledge 了錯誤的中斷要么中斷永遠(yuǎn) no one care設(shè)備一直 busy poll。我們的項目里APLIC 的target寄存器就設(shè)定了 index 和好如果兩個設(shè)備配置成相同的 index后配的那個會把先配的覆蓋掉。解決辦法每個中斷源在設(shè)備樹里聲明時需要開辟獨立的interrupts屬性并且確保 APLIC target 寄存器里寫入的就是這個中斷號不能復(fù)用。4.2 非 MSI 外設(shè)中斷在虛擬化下丟失在虛擬化場景如果虛擬機的設(shè)備是直通的它發(fā)送的是真正的 MSI沒問題。但傳統(tǒng)線控中斷APLIC 翻譯成 MSI 后送到哪個 IMSIC 的哪個 guest index需要軟件提前配置好guest index和 pending 文件。我遇到的一次 Bug 是虛擬機里的 UART 中斷Host 能收到但 Guest 永遠(yuǎn)收不到。排查后發(fā)現(xiàn)IMSIC 的 guest 中斷需要單獨開啟對應(yīng) guest index 的中斷文件使能位而且要在mintstatus里使能對應(yīng)的 guest 外部中斷轉(zhuǎn)發(fā)通道。等到把 guest index 對應(yīng)的一組寄存器全配好中斷才能正常注入。4.3 IMSIC 的 EOI 時機導(dǎo)致中斷風(fēng)暴在一個網(wǎng)絡(luò)驅(qū)動的壓力測試中出現(xiàn)了持續(xù)不斷的中斷風(fēng)暴CPU 占用率直接被打滿。后來發(fā)現(xiàn)原因是外設(shè)中斷觸發(fā)后IMSIC 的getipnum會自動 pending 當(dāng)前最高優(yōu)先級中斷但如果軟件在 EOI 之前就重新使能了該中斷源外設(shè)狀態(tài)沒有真正清掉就會立刻再次觸發(fā)中斷形成風(fēng)暴。解決辦法是在中斷處理函數(shù)的最后才寫 EOI而且要先屏蔽中斷源等外設(shè)狀態(tài)清理完畢再解除屏蔽。這個順序不能反反了就會丟中斷或者風(fēng)暴。4.4mret時機與mstatus.MPIE的交互這個問題比較隱蔽。在 PLIC 時代mret之后中斷是否重新可以觸發(fā)取決于mstatus.MPIE置位情況。AIA 引入了mintstatus之后多了一層翻譯狀態(tài)。如果mintstatus中的某個位沒有正確清除mret之后新中斷沒有辦法被響應(yīng)表現(xiàn)就是“中斷只進來一次之后就再也進不來了”。排查方式在 trap 返回之前打印mintstatus的值對比正常和異常兩種情況能很快定位到是不是因為 missing EOI 或者MINTSTATUS_MI位卡住了。4.5 排查工具建議遷移和調(diào)試過程中我發(fā)現(xiàn)純靠打印效率太低。推薦幾個輔助手段OpenSBI 的 DT 掃描OpenSBI 已經(jīng)支持 APLIC/IMSIC 的初始化用它先驗證硬件寄存器讀寫是否正確。JTAG 直接讀 IMSIC 寄存器如果 SoC 的 JTAG 能看到 IMSIC 映射的 4KB 窗口直接讀getipnum看中斷是否有 pending。/perf 中斷事件Linux 下用perf stat -e irq:irq_handler_entry看中斷頻率如果中斷風(fēng)暴這里數(shù)字會非常嚇人。邏輯分析儀抓外設(shè) IRQ 線確認(rèn) APLIC 的輸入側(cè)信號確實翻轉(zhuǎn)排除外設(shè)側(cè)的問題。5. 我對這次遷移的一些總結(jié)和想法整個遷移過程下來我的一個直接感受是AIA 不是 PLIC 的簡單升級版它是一套為虛擬化和大規(guī)模多核設(shè)計的中斷分發(fā)體系。PLIC 的設(shè)計哲學(xué)是“集中管理分散響應(yīng)”所有中斷源匯聚到一個控制器再分發(fā)到各個 hart。AIA 的設(shè)計哲學(xué)是“源頭翻譯本地處理”線控中斷在 APLIC 做一次翻譯變成 MSI 后直接投遞到目標(biāo) IMSIC由目標(biāo)核本地處理中間少了集中仲裁的開銷。 這也意味著驅(qū)動開發(fā)者的思維方式需要跟著變從“操作一堆全局寄存器”轉(zhuǎn)向“配置好翻譯路徑然后按文件和索引操作”。從性能角度講IMSIC 的直投模式延遲確實比 PLIC 低特別是在開啟了 MSI 的內(nèi)核里UART、網(wǎng)卡這些中斷源的響應(yīng)時間都有可感知的下降。不過如果要拿數(shù)值吹牛需要在相同主頻、相同外設(shè)負(fù)載下做 A/B 對比單純從架構(gòu)推導(dǎo)延遲低多少并不嚴(yán)謹(jǐn)。從可維護性看AIA 的配置項比 PLIC 多對軟件初始化代碼的編寫要求更高。但一旦配好中斷路由的靈活性遠(yuǎn)超 PLIC。特別是做多核負(fù)載均衡時可以在運行時動態(tài)調(diào)整 APLIC 的 target 寄存器把不同外設(shè)中斷按負(fù)載重新路由到不同的核這在 PLIC 時代是做不到的。如果讓我給正在評估遷移的朋友一句話建議如果只是單核裸機跑外設(shè)PLIC 別動如果已經(jīng)在做或者準(zhǔn)備做雙核以上 Linux或者有虛擬化規(guī)劃那從 IP 選型階段就把 APLIC IMSIC 方案納入省得后續(xù)從 PLIC 遷移過來重寫驅(qū)動。最后再分享一個小技巧調(diào)試 APLIC 時利用它的domaincfg寄存器里的BIGEND字節(jié)序位可以切換寄存器的字節(jié)序在大小端混合的 SoC 里核對寄存器讀寫邏輯很管用。這個在規(guī)格書里很容易被忽略但排查硬件描述和軟件訪問字節(jié)序不一致時能省下至少半天時間。