做嵌入式或者底层系统开发的，大概率都会被三种主流架构的中断机制搞得脑壳疼：ARM 的中断控制器叫 GIC，x86 那边是 APIC 加 IDT，RISC-V 又搞出一套 PLIC 和 CLINT，看起来完全是不相关的三套东西。但如果你真的把三条流程摊开对比着看，会发现它们在底层逻辑上惊人的一致。
这篇文章我想用一条主线把三种架构的中断流程串起来讲。主线就是：中断请求从源头产生，经过中断控制器仲裁，然后给处理器发信号，处理器响应后保存现场，找到处理函数，执行完再恢复现场继续干活。只要把这条主线上的五个环节逐个拆开，你会看到 ARM、x86、RISC-V 不过是分别用了不同的“零件”来完成同一套动作。无论你是刚学体系结构的学生，还是做内核移植、驱动开发、BSP bringup 的工程师，这套主线理解法都能帮你快速上手任何一款新处理器。
1. 中断的本质：为什么三种架构都逃不过“请求-仲裁-响应-处理-恢复”
先把视角拉到最底层。处理器本质上是一台“按步执行指令”的机器，CPU 从内存取指令、解码、执行、写回，如此循环。但这种串行执行有一个致命问题：外部设备（网卡、硬盘、定时器）什么时候需要 CPU 处理是随机事件，CPU 不可能一直轮询等待。轮询会白白烧掉 CPU 的算力，而中断恰恰是为了打破这种同步执行模型而生的。
中断的完整链路可以用一个生活场景来类比。想象你是程序员正在工位上专注写代码，这是 CPU 在执行主程序；公司前台接到一通电话说有访客找你，这是中断请求（IRQ）；前台先看一眼你的日程表，判断优先级高不高，这是中断仲裁；然后前台走到你工位告诉你“有访客”，你停下来把当前打开的文档保存好、记住自己写到哪一行，这是保存现场；你去接待访客，这是执行中断处理程序；聊完回来打开文档继续写，这是恢复现场。
这个类比几乎完美对应三种架构中断流程的全部环节。你会发现，无论是 ARM 的 GIC（Generic Interrupt Controller）、x86 的 APIC（Advanced Programmable Interrupt Controller），还是 RISC-V 的 PLIC（Platform-Level Interrupt Controller）加 CLINT（Core Local Interruptor），它们在做的事情都是：收集中断源，按优先级仲裁，把最高优先级的中断送给 CPU。而 CPU 收到中断后的动作更是高度一致——跳到一个固定的入口地址，保存 CPU 状态，跳到中断处理函数，处理完返回到被中断的指令继续执行。
区别只在于这几个问题的答案：
- 中断源怎么编号？是固定编号还是软件可配置？
- 中断控制器跟 CPU 怎么连接？通过专用信号线还是内存映射的寄存器？
- CPU 现场（寄存器、状态位）保存在哪里？压栈还是写专用寄存器？
- 中断处理入口地址是固定地址还是可配置？
把这三个问题的答案吃透，等于同时看懂了三大架构的中断体系。接下来，我按主线逐个展开三种架构的具体实现，并且在每个环节都标注它对应主线中的哪个位置，你可以跟我上面列的五环节一一对应着看。
2. ARM 中断流程拆解：GIC 是绝对的调度核心
ARM 架构的中断体系在移动设备和嵌入式领域统治了很多年。跟 x86 的“处理器拍板”不同，ARM 把中断管理的重心放在了外部中断控制器 GIC 上。目前主流平台用的是 GICv2 和 GICv3，两者在分发逻辑上大同小异，我以 GICv2 为主线讲解。
2.1 GIC 的结构与中断源的三种类型
GIC 分为两个主要功能模块：分发器（Distributor）和CPU 接口（CPU Interface）。分发器负责汇总所有中断源，按优先级仲裁，然后发给 CPU 接口；CPU 接口负责跟具体的一个 CPU 核打交道。
GIC 认识的中断源分三类：
- SGI（Software Generated Interrupt）：软件触发的中断，编号 0-15，通常用于多核 CPU 之间的核间通信（IPI）。在 Linux 内核里，重调度、函数调用等场景都依赖 SGI。
- PPI（Private Peripheral Interrupt）：私有外设中断，编号 16-31，只能发给特定的某一个核。典型例子是每个核自己的本地定时器中断。
- SPI（Shared Peripheral Interrupt）：共享外设中断，编号 32 以上。任何核都能收到，具体发给哪个核由 GIC 分发器配置。网卡、USB 控制器等外设中断基本都是 SPI。
2.2 中断状态机与优先级仲裁
GIC 给每个中断源维护了一个状态机，四个状态：inactive（未激活）、pending（等待处理）、active（正在处理）、active and pending（处理中又有新请求）。整个状态迁移逻辑是这样的：
- 外设拉高中断请求线，对应中断源的状态从 inactive 变成 pending。
- GIC 分发器在所有 pending 状态的中断里，选出优先级最高的那个，发给 CPU 接口。
- CPU 接口把这个中断送给 CPU 核，同时 GIC 把该中断状态置为 active。
- CPU 核进入中断处理函数，处理完成写 GICC_EOIR（End of Interrupt Register）寄存器，告知 GIC“这个中断我处理完了”，状态回到 inactive。
优先级仲裁发生在分发器内部，每个中断源都有一个可配置的优先级寄存器，数值越小优先级越高。多核环境下，分发器还会考虑当前哪个核的中断屏蔽状态、亲和性设置，决定发给哪个核。
2.3 CPU 侧响应与现场保存
ARM CPU 收到 GIC 发来的中断信号后，硬件自动完成这几件事：
- 拷贝 CPSR（当前程序状态寄存器）到 SPSR_irq，保存中断发生时的处理器状态。
- 将返回地址存入 LR_irq 寄存器。注意，这个返回地址是被中断指令的下一条指令地址加 4，因为 ARM 流水线的缘故，需要手动修正。
- 切换处理器模式到 IRQ 模式，并跳转到异常向量表中 IRQ 对应的入口地址。
这里有一个新手很容易踩的坑：ARM 的异常向量表有两个，低地址向量表（0x00000000）和高地址向量表（0xFFFF0000），通过 CP15 协处理器的 SCTLR 寄存器的 V 位选择。现代系统基本都用高地址向量表，入口地址是 0xFFFF0000 加上对应异常类型的偏移。
2.4 处理完成后的返回路径
中断处理函数结束后，需要执行异常返回指令把现场捞回来。在 ARM32 里这条指令是SUBS PC, LR_irq, #4，为什么减 4？因为 LR_irq 保存的是被中断指令下一条地址加 4，减 4 后又乘上 ARM 状态的对齐要求，才能准确回到被中断的指令。ARM64 就要简单一些，直接用eret指令，从 ELR_el1 寄存器恢复 PC，从 SPSR_el1 恢复 PSTATE。
我早期刚接触 ARM 时，一度以为中断返回就是把 LR 弹回去就行，结果调试时发现中断处理完程序跑飞，查了半天才发现是 ARM 模式切换和返回地址修正的问题。后来养成了一个习惯：看 ARM 手册的时候，先把“LR 对每种异常类型保存的是什么内容”这页表格贴到工位上，比死记硬背强太多。
3. x86 中断流程拆解：从 PIC 到 APIC，向量号驱动的分发体系
x86 的历史包袱最重，它的中断体系经过了从 Intel 8259A PIC 到 APIC 的演进，但核心思想一脉相承：所有中断源都映射到一个 0-255 的中断向量号，中断描述符表（IDT）记录每个向量号对应的处理函数入口。看懂 x86 中断流程，关键就看懂 IDT 和中断门描述符。
3.1 中断来源分类：硬件中断、异常与软中断
x86 的中断来源不止外设，还有 CPU 内部异常和软件主动触发的中断指令。三者在 IDT 里共用 0-255 的向量号空间：
- 异常（Exception）：CPU 执行指令过程中发现错误，比如缺页（#PF，向量号 14）、除零（#DE，向量号 0）、通用保护故障（#GP，向量号 13）。这类中断是同步的——它们由当前正在执行的指令触发，处理完成后要么修正问题重新执行这条指令，要么终止当前程序。
- 硬件中断：外部设备通过 PIC/APIC 发给 CPU 的异步中断，比如定时器、键盘、网卡。传统 PIC 模式下，IRQ0-IRQ7 映射到向量号 0x08-0x0F；APIC 模式下，系统软件可以在 0x20-0xFF 之间自由分配。
- 软中断（INT n 指令）：软件主动执行
INT n触发指定向量号的中断，主要用于系统调用。
硬件中断和异常虽然在硬件层都叫“中断”，但处理路径有一个关键区别：异常发生时，CPU 会把产生异常的指令地址压栈，因为异常处理完成后可能需要重新执行这条指令；而硬件中断压栈的是被中断指令的下一条指令地址，处理完直接返回继续往下执行。Linux 内核代码里把这两种情况分得清清楚楚，exception handler和interrupt handler是完全不同的两套注册路径。
3.2 IDT：一张描述中断处理入口的大表
IDT 就是一张最多 256 项的表，每一项是一个门描述符（Gate Descriptor），占 8 字节。门描述符分三种：任务门、中断门、陷阱门。现代操作系统基本只用中断门和陷阱门，区别在于中断门会通过硬件自动将 IF 标志位清零（屏蔽可屏蔽中断），而陷阱门不修改 IF。
关键在于：硬件中断使用中断门，基本不会嵌套触发。为什么这么说？因为 CPU 收到中断门触发的中断后，硬件自动把 IF 清零，后续可屏蔽中断进不来了，直到 IRET 指令恢复现场时才把 IF 恢复。这天然防止了中断处理程序里又发生中断导致的递归风暴。RISC-V 和 ARM 都没有这个“自动屏蔽中断”的机制，需要软件手动处理，这点后面讲 RISC-V 时你会有更深体会。
IDT 表的基地址存放在 IDTR 寄存器里，用LIDT指令加载。表项里最关键的信息是目标代码段选择子和偏移量，也就是中断处理函数的入口地址。CPU 收到中断向量号 n 后，会用 n 乘以 8 加上 IDTR 基地址，找到对应的门描述符，然后跳转到描述符里指定的地址。
这里有个跟 ARM 截然不同的设计哲学：x86 的向量号 = 中断源 ID，ARM 没有向量号概念，只有中断源 ID。x86 把外设中断映射成向量号后，内核可以直接通过向量号定位 IDT 表项拿到处理函数入口；ARM 则需要软件读 GICC_IAR 寄存器问“当前哪个中断在 pending”，再自己根据中断号去查函数指针数组。前者是硬件代劳查表，后者是软件手动查表，逻辑上是等价的，但窝藏的调试难点不一样。
3.3 中断现场自动压栈与错误码
x86 的现场保护由 CPU 自动完成，但动作是“压栈”而不是写到专用寄存器。硬件会自动把以下内容依次压入当前特权级的内核栈：
- SS（栈段）、RSP 或 ESP（旧栈指针）
- RFLAGS（标志寄存器）
- CS（代码段）、RIP 或 EIP（返回地址）
部分异常还会额外压入一个错误码，比如缺页异常会把产生缺页的线性地址信息通过 CR2 寄存器暴露给处理函数，同时栈上多一个 error code，告诉处理函数异常的具体原因。
处理完中断后，执行IRET（或IRETQ）指令时，CPU 会从栈上依次弹出 RIP、CS、RFLAGS，再弹出 RSP、SS，恢复到中断发生前的状态。这里注意：如果异常带了错误码，软件必须自己先清掉栈上的 error code，然后再执行 IRET，否则栈不平衡，返回地址全乱套。
3.4 APIC：现代 x86 的中枢仲裁
传统 PC 用两片 8259A PIC 级联管理 15 个中断输入，设计简单但扩展性差，多核下中断分发能力更是捉襟见肘。现代 x86 平台全面转向 APIC 体系。
APIC 分两部分：**LAPIC（Local APIC）**集成在 CPU 内部，每个核一个，负责接收外部中断并通过 IDT 向量号触发 CPU 中断；I/O APIC负责汇总外设中断，按系统的中断路由表分发给指定的一个或多个 LAPIC。
I/O APIC 通过 **Interrupt Redirection Table（中断重定向表）**把外设中断源映射到向量号并指定目标核。这张表的每一项对应一个 IRQ 输入引脚，可以配置：中断向量号、目标 LAPIC 的 ID 列表、触发模式（边沿/电平）、中断屏蔽等。操作系统启动时初始化这张表，相当于给每个外设中断号配好了“去哪处理”的路线图。
我调试 x86 PCIe 设备中断路由问题时，最常查的两个地方就是：/proc/interrupts查看每个中断号分配到了哪个 CPU 核，以及dmesg输出里的IO-APIC路由信息。掌握了 Redirection Table 的逻辑，看这些信息就能直接判断出中断是不是被路由到了错误的核上，是不是跟亲和性设置冲突了。
4. RISC-V 中断流程拆解：精简指令集最极致的中断哲学
RISC-V 是三种架构里最年轻的，但它的中断设计反而最能体现 RISC-V 的哲学——什么都留给软件决定，硬件只提供最纯粹、最少的机制。如果你已经看懂上面 ARM 和 x86 的流程，RISC-V 的内容会显得尤其清爽：CSR 寄存器管状态、mtvec/stvec 管入口、mret/sret 管返回，外部中断控制器 PLIC 负责外设中断的仲裁。
4.1 中断与异常的模型：CSR 寄存器家族
RISC-V 把“中断”和“异常”明确区分开，但对 CPU 来说动作是统一的——都是跳转到一个入口地址、保存必要的状态、处理完成后返回。所有关键状态都存放在一组 **控制状态寄存器（Control and Status Registers，CSR）**里。
机器模式（Machine Mode）下最核心的四件套：
mstatus：全局中断使能位。其中MIE位控制机器模式中断是否开启，还有一个重要特征是MPIE，它保存着进入中断前的MIE状态，为返回时恢复做准备。MPP字段记录进入中断前的特权级。mepc：中断返回地址。硬件会将被中断指令的地址写入mepc，mret指令返回时就是跳到mepc指向的地址。mcause：中断/异常原因。最高位区分是中断还是异常，低位记录编号，比如外部中断是 11，时钟中断是 7，非法指令异常是 2。mtvec：中断向量表基地址。就是中断处理入口所在位置。
处理流程非常简单：收到中断信号且 mstatus.MIE 置位时，硬件将当前 mstatus 保存到 mstatus.MPIE，将当前特权级保存到 mstatus.MPP，把 MIE 清零（自动屏蔽中断），把 mcause 填入原因，把 mepc 写入返回地址，然后跳转到 mtvec 指向的地址。恢复现场更简单——执行mret，硬件自动把 MPIE 写回 MIE，恢复 MPP 对应的特权级，跳转到 mepc。
有没有觉得这跟 x86 把 RFLAGS 压栈的思路很相似？是的，x86 是把状态压到内存栈上，RISC-V 是把状态存到专用 CSR 寄存器里。RISC-V 的做法让状态访问变得可预测、可并发访问，但也意味着嵌套中断时必须在进入处理程序后第一时间保存这些 CSR 到内存栈，否则新中断一来就把它们覆盖了。
4.2 三种特权级与中断的委托
RISC-V 的复杂性集中在“机器模式（M-mode）、监管者模式（S-mode）、用户模式（U-mode）”三者之间的切换上。机器模式是最高特权级，相当于 ARM 的 EL3 或 x86 的负特权级，固件和 M-mode 运行时环境（如 OpenSBI）在这里执行；操作系统内核跑在 S-mode；用户程序跑在 U-mode。
中断默认只发给当前特权级对应的处理入口。比如定时器中断默认触发 M-mode 的mtvec，但如果操作系统希望 S-mode 直接接管定时器中断（Linux 就是这么干的），就需要通过 **中断委托（Interrupt Delegation）**把对应中断委托给 S-mode。
委托机制由两个 CSR 控制：
mideleg（Machine Interrupt Delegation）：一个位图，哪个位置 1 就把对应编号的 M-mode 中断委托给 S-mode。medeleg（Machine Exception Delegation）：负责委托异常。
还有一个关键 CSRsie（Supervisor Interrupt Enable）和sstatus.SIE，分别对应 S-mode 的中断使能和全局开关。委托之后，S-mode 的入口地址由stvec决定，返回指令换成sret，现场状态存sepc，原因存scause。
这种分层设计在实现安全隔离时极其灵活。比如 ARM 上要跑 TrustZone 需要一大堆安全扩展，RISC-V 通过 M-mode 天然提供了一个最小的安全边界：M-mode 固件可以拦截所有中断，先做安全检查再决定是否转发给 S-mode。
4.3 PLIC 与 CLINT：外部中断和定时器中断的仲裁
RISC-V 规定中断的“行为”，但外部中断到底怎么收集、怎么仲裁，指令集规范明确说“平台自行决定”。目前事实标准就是 SiFive 提出的PLIC（Platform-Level Interrupt Controller）和CLINT（Core Local Interruptor）。
PLIC 负责管理所有外部设备中断源，功能等价于 ARM GIC 的分发器加 CPU 接口、也等价于 x86 的 I/O APIC 加 LAPIC。它支持最多 1023 个外部中断源，每个中断源有独立的 pending 位和使能位，支持优先级配置和中断目标核选择。
外部中断的完整流程是：
- 外设发起中断请求，PLIC 将该中断源的 pending 位置 1。
- PLIC 在所有 pending 且使能的中断里，选择优先级最高的那一个。
- 如果目标核已通过 PLIC 的 threshold 寄存器设置允许接收这个优先级，PLIC 向目标核发送一个中断信号。
- 目标核收到中断后，跳转到
stvec指向的入口（S-mode 外部中断 handler），软件通过读取 PLIC 的claim寄存器“认领”这个中断，顺便获得中断源编号。 - 处理完成后，软件写
complete寄存器通知 PLIC 可以处理下一个中断。
CLINT 则负责两类“本地中断”：定时器中断和软件中断。它给每个核提供一个可编程的mtime比较寄存器，配合实时计数器mtime实现定时器功能；软件中断则用于核间通信（IPI），功能对应 ARM 的 SGI 和 x86 的 LAPIC 发送 IPI。
PLIC 的设计有一个跟 GIC 显著不同的点：中断编号不是硬件固定绑定到向量号上，而是软件动态 claim 得到的。处理函数执行到一半，如果有更高优先级中断到来，PLIC 会再次向 CPU 发信号，但因为 RISC-V 没有硬件自动保存 CSR 状态的能力，能不能嵌套、怎么嵌套，完全取决于软件。Linux 的 RISC-V 内核实现里默认不在外部中断处理里开嵌套，用简单的local_irq_enable/local_irq_disable策略保证一致性。这对刚上手的人来说是个重要的心理预期：RISC-V 的裸机中断处理比 ARM 更“裸”，很多“自动完成”的活要自己写代码。
5. 三张典型流程图与差异总表：把主线各环节落实到具体硬件
我上面分别拆了三种架构，可能有朋友已经有点晕了。这部分我把同一段主线并排摆出来，直接用对照表把“每个环节分别由谁完成”讲清楚。
5.1 完成了哪些本应自动执行的工作
| 主线环节 | ARM | x86 | RISC-V |
|---|---|---|---|
| 中断源收集 | GIC Distributor | I/O APIC | PLIC |
| 优先级仲裁 | GIC Distributor（每个中断配置优先级） | I/O APIC Redirection Table + LAPIC 仲裁 | PLIC（每个中断配置优先级 + threshold） |
| 向 CPU 发送信号 | 专用中断线（IRQ） | LAPIC 接收中断消息 | PLIC 拉高外部中断线（machine external 或 supervisor external） |
| 中断入口查找 | 异常向量表 + 固定偏移（或 VBAR + 偏移） | IDTR 基址 + 向量号 × 8 查 IDT | mtvec/stvec 单入口地址（可配置 direct 或 vector 模式） |
| CPU 状态保存 | 关键寄存器存入 SPSR/LR（ARM32）或 ELR/SPSR（ARM64） | 自动压栈 SS/RSP/RFLAGS/CS/RIP + 错误码 | mstatus/mepc/mcause 自动写入 CSR，剩余寄存器软件保存 |
| 屏蔽嵌套中断 | 硬件置位 PSTATE.I（ARM64）或自动切模式（ARM32） | 中断门自动清 IF | 硬件清 MIE/SIE 位，但 CSR 覆盖风险需软件处理 |
| 中断原因标识 | CPU 不直接获得原因，软件读 GICC_IAR | 向量号即原因，IDT 索引直接定位 | mcause/scause 字段保存原因 |
| 返回到被中断代码 | ARM32: SUBS PC, LR_irx, #4；ARM64: eret | IRET / IRETQ | mret / sret |
这张表对照着看，三种架构的“同构性”就非常明显了。无论架构怎么变，要解决的问题永远是：谁管中断源、谁仲裁、怎么通知 CPU、怎么进处理函数、怎么保存现场、怎么返回。理解了这个主线逻辑，哪怕以后出现新的处理器架构，你也能用同一把尺子去量它。
5.2 中断处理流程的时间序细节
不少朋友喜欢直接看时序图，我用文本方式把这个过程展开描述，方便你在脑子里把流程跑起来。以 S-mode 外部中断为例，跑通一遍 RISC-V 的完整时序：
- 网卡产生中断断言，PLIC 将中断源 33 的 pending 置位。（请求）
- PLIC 看中断源 33 的优先级是 7，高于当前 target 核的 threshold 5，于是向 CPU 发出外部中断请求信号。（仲裁）
- CPU 检查
sstatus.SIE已置位且sie.SEIE已置位，接受这个中断。（响应） - 硬件记录当前
sstatus到sstatus.SPIE，记录特权级到sstatus.SPP，清除SIE，将sepc写入被中断指令地址，scause写入外部中断编号，跳转到stvec指定的 S-mode 中断入口。（保存现场，入口跳转） - 入口处的汇编代码先保存通用寄存器到栈上，保护现场完整性，然后读取 PLIC 的
claim寄存器获得中断源编号，调用对应的 C 函数中断处理例程。（处理） - 处理完毕，写 PLIC 的
complete寄存器，表示完成。恢复通用寄存器，执行sret，硬件将SIE恢复为SPIE之前的值，特权级恢复为SPP中的值，跳转到sepc指向的地址继续执行原代码。（恢复现场）
ARM 和 x86 的流程你完全可以用这个模板带一遍，只不过把 PLIC 换成 GIC 或 I/O APIC，把入口查找方式换成向量表或 IDT。有趣的是，即便换了具体实现，下面这几句话是不变的：中断源必须被收集，处理函数必须知道是谁发的中断，返回地址必须被保存，处理完必须能回到原来的执行流。
6. 中断嵌套、延迟与优先级：三种架构的真实战场
聊到这里，中断的基本流程已经通了。但真正让系统工程师头疼的从来不是“走通流程”，而是嵌套、延迟和优先级管理。这部分是三种架构差别最大的地方，也是实战中坑最多的地方。
6.1 x86 的硬件级防重入与 IF 位管理
x86 的中断门描述符在 CPU 硬件层面自动完成了一件非常重要的事：进入中断门时清 IF 位，禁止后续可屏蔽中断。这意味着默认情况下 x86 中断不能嵌套，除非处理程序显式执行STI开启中断。这种设计让 x86 的中断处理程序编写门槛很低——你不用担心中断处理一半突然又进另一个更高优先级的中断把栈搞乱，也不用担心通用寄存器被冲掉，因为新中断根本进不来。
代价就是：如果高端设备的中断迟迟得不到响应，延迟不可控。x86 的实时性表现一直不如 ARM 和 RISC-V 的一个结构性原因就在这里。Linux x86 内核通过local_irq_enable/local_irq_disable细分了临界区中断屏蔽粒度，但再细分也无法把硬件自动清 IF 的“全局中断关断”语义去掉。
6.2 ARM 的硬件嵌套与 GIC 的优先级抢占
ARM 的 GIC 设计要灵活很多。GIC 支持通过优先级配置实现硬件级嵌套抢占：如果高优先级中断 pending 时的抢占阈值低于当前正在处理的中断优先级，GIC 会直接向 CPU 发送新中断信号，CPU 会中断当前的中断处理函数，进入新的中断处理。
ARM64 上实现这一套靠的是 PSTATE 的 I 位控制“物理中断是否被路由到 EL1”，处理程序可以通过local_irq_enable在中断上下文主动让出嵌套空间，让 GIC 能抢占。这个能力对实时性要求高的场景（比如汽车 ECU、工业控制）至关重要——你可以让一个高优先级的定时器中断随时打断耗时长的低优先级中断处理。
代价是软件复杂度变高。我调过一块 ARM SoC 的中断嵌套问题，一个驱动在中断处理函数里开了抢占，结果自己写的中断处理函数里有共享资源没有加锁，高优先级中断打进来直接把数据写坏了。ARM 平台开中断嵌套是顺手的事，但开之前先想清楚共享资源保护。
6.3 RISC-V 的“软件自理”与 PLIC 抢占限制
RISC-V 的嵌套控制跟 ARM 类似，也需要软件主动开启。但 PLIC 有自己的一个设计特性：PLIC 只有在 CPU claim 中断之后才会把后续更高优先级的中断作为新中断请求发给 CPU。也就是说，如果你在第一层中断处理程序里重新打开SIE，PLIC 可以再次向 CPU 发信号，但是这个信号仍然是“你还没 complete 前一个中断，现在有更高优先级的中断来了”。
Linux RISC-V 里面处理这个场景的方式是：在处理外部中断时，先读取claim，然后如果开启了中断嵌套，软件需要自己维护一个正在处理中断的优先级栈。这样新中断进来时，通过比较中断源优先级决定是否处理。如果处理，则需要把前一个中断的上下文完整保存在栈上，处理完再逐级恢复。
RISC-V 这种模式的优点是极度干净——所有策略都在软件里，硬件一个非分之想都没有。缺点就是新手容易踩到“响应了高优先级中断，但忘了保存低优先级中断的上下文”的坑。我自己写 RISC-V 中断 handler 的时候，第一步永远是先保存所有通用寄存器到栈上，再操作 CSR，绝不偷懒。
7. 裸机代码视角：RISC-V 中断处理实现的最小示例
读完所有概念之后，最有用的练习是直接写一段裸机中断处理的汇编入口，把 RISC-V 的 CSR 操作串起来。这不是玩具代码，内核的arch/riscv/kernel/entry.S干的就是类似的事，只是加了更多上下文保存和硬件相关的逻辑。
# RISC-V S-mode 外部中断的最小入口，使用 C 函数 handle_irq 处理 .text .align 4 .globl trap_vector trap_vector: # 保存通用寄存器到栈上 addi sp, sp, -256 sd x1, 0(sp) sd x2, 8(sp) sd x3, 16(sp) # ... x4 到 x30 同样操作，这里省略 sd x31, 248(sp) # 读取 scause 区分异常和中断 csrr t0, scause blt t0, zero, handle_interrupt # scause 最高位为 1 表示中断 # 异常处理路径 jal ra, handle_exception j restore handle_interrupt: # 判读是不是外部中断：scause 去掉最高位后等于 9 是 S-mode 外部中断 slli t0, t0, 1 srli t0, t0, 1 li t1, 9 bne t0, t1, handle_other # 外部中断：读 PLIC claim li t0, PLIC_BASE lw a0, 0(t0) # a0 = 中断源编号 call handle_irq # 写 PLIC complete li t0, PLIC_BASE sw a0, 0(t0) handle_other: # 其他中断处理 ... restore: # 恢复通用寄存器 ld x1, 0(sp) # ... 省略 addi sp, sp, 256 sret这段代码透露了几个关键信息：
scause的最高位区分中断与异常，低位数是具体编号。- 外部中断第一步是读
claim，得到中断源编号，这是后续必须传给处理函数的关键信息。 - 处理完毕写
complete，参数就是之前读到中断号。 - 用
sret返回，硬件自动恢复 SIE 和特权级。
对比 ARM64 的相同逻辑，你会发现 ARM64 读GICC_IAR得到中断号、写GICC_EOIR结束中断，流程完全一样。如果你之前写过 ARM 的中断 handler，第一次看 RISC-V 的代码会有一种“回到舒适区”的感觉。
8. 调试建议与经验心得：中断问题应该从哪里下手
写了这些年底层代码，调试三种架构中断问题的路径其实高度相似。整理几条我个人屡试不爽的经验，给正在调试中断的朋友参考。
第一条：先确认中断源有没有到达中断控制器。这是最基础也最容易被忽略的一步。ARM 看GICD_ISPENDRn寄存器有没有对应 pending 位；x86 看 I/O APIC Redirection Table 的 mask 位和/proc/interrupts的计数；RISC-V 看 PLIC 的 pending 寄存器。如果 pending 位都没置位，说明外设根本没有发出正确的中断请求，而不是 CPU 侧的问题。我遇到过无数次“中断不触发”的假象，最后发现是外设的中断 mask 寄存器没打开，数据手册翻到最后一页才发现。
第二条：中断入口点有没有执行到，用打点法验证。不管什么架构，在中断处理函数入口加一个计数器自增的语句，然后在主程序里把它打印出来，是最快的验证手段。RISC-V 上可以先在mtvec/stvec的入口代码里直接写死跳转一个测试函数，排除 CSR 配置问题；ARM 上可以直接调试 GICD_ISENABLER 寄存器；x86 上可以用int 0x20这类软中断模拟硬件中断路径，验证 IDT 配置是否正确。
第三条：中断丢失大概率是没写 EOI，或者中间被 mask 了。三个架构都有“告知中断控制器处理完了”这个动作。ARM 写GICC_EOIR，x86 对 PIC 模式写OCW2，RISC-V 写 PLICcomplete。漏了这一步，中断控制器会认为中断还没处理完，永远不再发下一个中断请求。这几乎算得上中断调试第一大坑。
第四条：用 GDB 直接看硬件寄存器状态，比日志靠谱得多。QEMU 模拟器特别适合中断流程的学习和调试。以 RISC-V 为例，QEMU 的info registers可以看到所有 CSR 的状态，包括mstatus、mepc、mcause，配合 GDB 在stvec入口下断点，中断一跳进去就能拿到完整的硬件现场快照。这套方法放到 ARM 和 x86 的 QEMU 上也成立，只换寄存器名字而已。
第五条：内核代码是最好的学习教程。如果你想看真实的中断处理框架，别急着读芯片手册，先看 Linux 内核的这几处代码：ARM 的arch/arm/kernel/irq.c里handle_arch_irq指针的注册过程；x86 的arch/x86/kernel/idt.c里idt_setup_apic_and_irq_gates；RISC-V 的arch/riscv/kernel/irq.c里irq_work异处理。三处一对比，主线逻辑跃然纸上。
9. 一条主线的最终收束与我的实际体会
回到这篇博文开头的问题：三种架构的中断流程到底有什么区别？我的答案是，底层逻辑毫无区别，区别只在于分工方式。
- ARM 把中断管理的重头戏放在 GIC 里，硬件自动保存一部分状态，中断处理函数入口固定由向量表决定。
- x86 把状态保存全部交给 CPU 自动压栈，用 IDT 的向量号直接定位处理函数，同时硬件自动屏蔽嵌套。
- RISC-V 把控制权全部交给软件，CSR 寄存器负责保存最核心的状态，PLIC 只管收集中断源和仲裁，其他一切自理。
对我个人来说，最深的体会是：真正把中断流程吃透的标志，不是背得住 GIC 的寄存器名字、不是记得住 IDT 表项布局，而是能在一张白纸上把那条主线完整画出来，然后能在任何一个架构里把线上每个环节对应的硬件或软件机制标注出来。做到了这一步，认识新架构时，你不需要再从头学一遍“中断”，而是要做的事是“把新架构的零件往主线里装一遍，看哪些环节换了新玩法”。
最后给还在啃中断的读者一个建议：动手写一个最简单的裸机中断示例，从定时器中断开始，就三条腿走路——配置中断源、写处理函数、验证响应，比我看十篇博客都管用。三种架构各跑一遍之后，你就真的把这套主线变成自己的东西了。
