企业官网建设流程全解析

1. 三种架构中断流程的共同主线：先有框架，再谈差异

1.1 中断到底是什么：从一次按键说起

先讲一个我自己的经历。几年前我第一次在一颗 RISC-V 芯片上调按键中断，调了两天没反应。后来翻架构手册才发现，问题根本不在我的按键逻辑，而是我对 RISC-V 的中断响应路径完全没有建立直觉。反倒是那次之后，我把 ARM Cortex-A 和 x86 的中断流程也重新撸了一遍，才终于意识到一件事：所谓三种架构，其实共享同一条中断处理主线，只是每个环节的实现方式各不相同。

中断这个概念，说白了就是 CPU 正在执行指令流的时候，被一个突发事件打断，暂时放下手头的活，去处理这个事件，处理完之后再回到原来的指令流继续执行。这个机制是所有现代处理器都绕不开的基础设施。没有中断，CPU 就得不停轮询外设状态，效率低到没法看；有了中断，CPU 才能在等待外设的间隙去干别的事，操作系统才能真正实现多任务、实时响应和输入输出并发。

你按键、网卡收包、定时器到期、硬盘 DMA 完成，这些事件都是通过中断通知 CPU 的。可以说，中断流程的效率和可靠性，直接决定了整个系统的实时性和稳定性。理解了中断，你才算真正理解了处理器架构的内核。

1.2 共同主线：六步链路打通三种架构

三种架构表面上差异很大，x86 用 IDT 和 TSS，ARM 用 GIC 和异常向量表，RISC-V 用一组 CSR 加 PLIC。但如果把一路流程摊开看，你会发现它们都在做同一套动作，用一条主线就能全部串起来：

• 第一步：中断源产生事件。无论是外部硬件信号、定时器超时，还是 CPU 内部执行指令时触发的异常，都属于中断源。
• 第二步：中断控制器仲裁路由。多个中断源同时申请时，由控制器按优先级仲裁，把选中路由到 CPU。x86 是 APIC，ARM 是 GIC，RISC-V 是 PLIC 加 CLINT。
• 第三步：CPU 响应中断。CPU 收到请求后，保存当前进度，至少要记录“现在执行到哪了”和“中断是什么原因”，再跳转到中断处理入口。
• 第四步：查找向量表定位处理函数。处理器根据中断号，去内存里找到对应处理函数的入口地址。x86 查 IDT 里的门描述符，ARM 查异常向量表里对应偏移的跳转指令，RISC-V 查 mtvec/stvec 指向的入口或跳转表。
• 第五步：执行中断服务程序 ISR。这里要区分“怎么保存现场”和“怎么恢复现场”，三种架构差别最大，也是最容易踩坑的地方。
• 第六步：恢复现场并返回。处理完中断后，把之前保存的 CPU 状态恢复，让被中断的程序无缝继续执行。

我强烈建议读者把这条主线先刻在脑子里，之后再去对照每一种架构，你就不容易迷路。后面几章我会按这条主线，一条一条把 x86、ARM、RISC-V 的细节填进去。

1.3 为什么值得把三种架构放在一起看

很多人会问：我又不是做编译器的，干嘛要搞清楚三种架构的中断流程？我的回答是：你只要写过底层驱动、BSP、RTOS 移植、虚拟化、或者哪怕只是在 QEMU 里调试过一个启动异常，中断流程就是你必须跨过的门槛。

更重要的是，三种架构相互映照，能帮你建立真正的体系结构直觉。比如你理解了 x86 为什么用 IDT 存门描述符、为什么要做栈切换，再去看 ARM 为什么把现场保存丢给软件、再去看 RISC-V 为什么把硬件路径砍到最简，你就会明白：每一种设计都是对前一种的一种“再思考”。这一套对照下来，对你选型、排错、做底层优化都有直接帮助。

2. 前置基础：中断向量、中断控制器和上下文切换

2.1 中断向量：一张"事件电话簿"

中断向量这个概念，所有架构都有，但形态差别很大。简单说，它就是一张表，系统里每个中断源都有一个编号，这个编号对应着表里的一个入口，告诉你这个中断来了应该跳到哪里去处理。

x86 的中断向量是 0 到 255 的整数。0 到 31 是 CPU 内部异常，比如除零错误、缺页、通用保护故障；32 到 255 一般是外部硬件中断和软中断。这张表就是 IDT（Interrupt Descriptor Table），存在内存里，由 idtr 寄存器指向。每个表项是一个 16 字节的门描述符，里面保存着处理函数的段选择子和偏移，还带着类型属性、特权级信息。

ARM 和 RISC-V 的向量表更像一张“跳板”。ARM 的异常向量表通常是一组跳转指令，每个异常类型占一行，比如 4 字节的 B 指令跳到对应处理函数；RISC-V 更直接，如果 mtvec 配置成 Vectored 模式，每个中断号对应一个固定偏移的跳转指令，Direct 模式下则只有一个统一入口，由软件去读 mcause 再做分发。

我觉得用电话簿来类比特别合适：事件来了，你总得知道打哪个分机。x86 的 IDT 是一本按门描述符组织的详细通讯录，ARM 的向量表是一块块跳板，RISC-V 则是一张极简的“可直接跳转也支持软件分发”的目录。你在调试中断不跳转的时候，第一件事永远都是查：向量表有没有配好、地址对不对、模式选没选对。

2.2 中断控制器：CPU 的"前台秘书"

多个中断同时来了，CPU 不可能同时处理，这时候就需要中断控制器。它负责做两件事：一是按优先级仲裁，决定哪个中断先上报；二是把选中中断路由到正确的 CPU，并告诉 CPU 中断号。

x86 的 PIC 和 APIC 这套体系已经非常成熟。传统 PC 上有两个 8259A 级联，后来统一到本地 APIC 加 I/O APIC。I/O APIC 负责收集外设的中断请求，通过总线送到 CPU 的本地 APIC，再由本地 APIC 决定打断哪个 CPU 核心。

ARM 的 GIC 在移动设备和服务器里几乎无处不在。GIC 分为 Distributor 和 CPU Interface 两部分：Distributor 管理所有中断源的使能、优先级、目标 CPU；CPU Interface 负责把中断信号送到具体 CPU 核，并维护中断状态机。到了 GIC v3/v4，还引入了亲和性路由，支持把中断精确投递给特定集群里的某个核心。

RISC-V 这边比较特殊：架构规范里并没有规定统一的“RISC-V 中断控制器”，而是交给平台去实现。通用做法是 PLIC 管外部设备中断，CLINT 管定时器和软件中断。PLIC 负责多级仲裁和路由，CLINT 提供 mtime 定时器并产生定时器中断到指定特权模式。这种分层设计的好处是架构规范保持精简，但代价是平台差异大，你写驱动时不能假设所有 RISC-V 芯片的寄存器地址都一样。

2.3 上下文切换：保存现场是中断处理的命门

“现场”这个词听着玄，其实就是一组寄存器值。CPU 正在跑一个应用，寄存器里存着它的局部变量、栈指针、返回地址。中断来了，你总不能让中断处理程序把应用的数据给踩了，所以必须先把现场保存下来，处理完再恢复回去。

三种架构对“现场”的处理方式差异巨大。x86 自动压栈压得最多：中断门触发时，CPU 会自动把 SS、RSP、RFLAGS、CS、RIP 压到栈里；如果发生特权级切换，还先要从 TSS 里取新的栈指针。ARM 的 Cortex-A 只自动保存很少的信息，比如把当前 PC 存到 ELR、把状态存到 SPSR，其余通用寄存器得靠软件压栈；而 Cortex-M 则搞了一套完整的硬件自动压栈，一口气压 8 个寄存器。RISC-V 和 Cortex-A 很像，硬件只更新几个 CSR，米EPC、MCAUSE、MSTATUS，其余寄存器全部由软件决定怎么保存。

我见过不少人在中断处理里写汇编时，把某个寄存器漏保存了，结果中断一返回，应用就莫名其妙崩溃。这个坑在 x86 上相对少见，因为硬件帮你压了很多，但在 ARM 和 RISC-V 上特别常见。你越早养成“入口保存所有会被破坏的寄存器、出口对称恢复”的习惯，后面调试越省心。

3. x86 中断流程解析：从 IDT 到 APIC 的经典范式

3.1 向量号从哪来：异常、外部中断和软中断

x86 的整个中断体系，先要区分三种来源。第一类是 CPU 内部异常，由指令执行直接触发，比如除零、非法指令、缺页。第二类是外部硬件中断，由 I/O 设备通过 APIC 请求产生。第三类是软中断，也就是程序主动执行 INT n 指令，常见的是系统调用入口，在 Linux 里早期版本用 INT 0x80。

其中 CPU 异常是同步的，意思是它和当前指令严格绑定在一起，你同样一条指令执行一百次，每次都会在同一点触发；而外部硬件中断是异步的，它跟当前执行的指令没有必然关系。x86 里这两类事件共用一套中断向量编号和 IDT 机制，所以误差也共用一套表。

这里有一个值得注意的点：x86 对每个向量号能配置 0 到 255，但 0 到 31 是 Intel 和 AMD 各自保留的异常号，你不能随便改写。比如缺页是 14（#PF），通用保护故障是 13（#GP），每来一次异常，CPU 还会往栈里压一个错误码，告诉软件出错的具体类型，最后由软件从栈里读取。

3.2 IDT 门描述符与特权级检查

x86 的中断处理入口是通过 IDT 表项定位的。IDT 中的每一项是 16 字节的门描述符，包括中断门、陷阱门、任务门三种。其中中断门会自动清零 IF 标志位，也就是在入口处自动屏蔽可屏蔽中断，防止处理过程中被新的中断打断；陷阱门则保留 IF 标志，适合某些需要嵌套的场景。

门描述符里还包含 DPL（描述符特权级）。当触发向量号的事件发生时，CPU 会比较当前特权级 CPL 和门描述符的 DPL，决定是否允许触发。这个机制在用户态通过 INT 3 调试断点和系统调用时非常关键，防止用户程序随便触发内核内部中断向量。

调试 x86 中断的时候，我最常做的就是打印 IDTR、然后手工解析 IDT 表项，看门描述符的段选择子和 offset 对不对。很多时候中断不跳转，不是 CPU 没收到请求，而是 IDT 表项根本没填对，或者门类型配错，导致触发时直接被拒之门外。

3.3 TSS 与栈切换机制

x86 的这个栈切换是比较有特色的一环。如果你在内核态运行，中断来时栈不变，只是往当前栈里压入 SS、RSP、RFLAGS、CS、RIP 一套现场，然后跳进 handler 处理完再用 IRET 弹出来。

但用户态程序触发中断进入内核态时，就不能再用用户栈了，因为用户栈既不可信，也可能不够用，如果内核的异常处理还要用用户栈，一旦栈故障就连累内核崩溃。所以 x86 将采用 TSS（任务状态段）里保留的 RSP0 到 RSP2 这几个特权级栈指针，根据目标特权级选择对应栈。同时，CPU 还会把新的 SS、RSP 也压入内核栈，IRET 返回时再恢复用户栈指针。

这里我踩过一个很经典的坑：在 64 位长模式下 TSS 里的 RSP0 如果没初始化，用户态一触发中断，系统立即会 double fault，然后重启。很多人解不到是因为忽略了 TSS 栈指针，以为只配好 IDT 就够了。记住，x86 的中断流程里，栈切换和 IDT 表项一样重要。

3.4 现代 x86 的 APIC 路由

传统 PC 时代用两个 8259A 芯片，级联支持 15 个中断源，为每个中断分配固定向量号。后来多核普及，8259A 已经不能满足路由到任意 CPU 的需求，于是退位到 APIC。现在的 x86 平台有本地 APIC 和 I/O APIC 两级。

I/O APIC 上的每个输入引脚或 PCI/MSI 消息，都可以编程指定中断向量号和投递目标 CPU。投递方式可以是固定目标、最低优先级、轮询等等。本地 APIC 收到消息后，会按照 LVT（本地向量表）的配置去决定是否允许注入、走哪个向量号。你也可以用本地 APIC 的定时器和产生自中断 IPI 来测试整套流程，既不需要硬件外设，也方便验证逻辑。

调试 APIC 路由时，我习惯先在 Linux 下读 /proc/interrupts，看某个外设中断是不是被均匀地分到各 CPU。如果发现全部中断都挤在 CPU0 上，就去查 irqbalance 是否开启，或者查驱动是不是设置了 CPU 亲和性。APIC 这套体系本身不复杂，复杂的是它和 ACPI、PCIe MSI 表纠缠在一起，容易让人分不清中断到底是走 pin 还是走 MSI 消息。

3.5 iret 返回与错误码处理

x86 的中断处理程序最终用 IRETQ 指令返回。CPU 从这里把栈上保存的 RIP、CS、RFLAGS 弹回去，恢复之前中断点的执行。如果发生特权级切换，还要把 SS、RSP 也弹出来，恢复用户栈。

需要特别留意的是队伍里还有一个错误码。IDT 对应的异常比如 #PF、#GP，CPU 在压入 RIP 之前先压入错误码，因此中断处理里在栈上看到的“返回地址”会被错误码隔开。返回之前，处理程序必须先从栈里清理错误码，否则 IRET 会把错误码当成 RIP 弹回去，程序立刻跑飞。常见做法是在入口处把错误码从栈里弹到某个寄存器，或者用 ADD RSP 调整栈指针。

我的建议是，x86 中断入口尽量用一个统一的汇编宏，把“压寄存器、处理错误码、切换寄存器”的逻辑模板化，避免每个 handler 裸写。零散编写虽然灵活，却很容易漏掉某个步骤，比如忘了压 R15 或者忘了清错误码，这类 bug 极为隐蔽。

4. ARM 中断流程解析：异常级别、GIC 与软件现场保存

4.1 异常级别与向量表布局

ARM 的异常模型和 x86 差异很大。以 AArch64 为例，系统分成 EL0 到 EL3 四个异常级别，EL0 一般是用户态，EL1 是内核态，EL2 是虚拟化，EL3 是安全固件。每次进入更高异常级别，就相当于一次中断响应。

每个异常级别都独立维护向量表和状态寄存器。VBAR_EL1 指向 EL1 的异常向量表基址，表里按异常类型分四大块：同步异常、IRQ、FIQ、SError；每块又按来源区分是 SP 用的还是某个 EL 用的，总共 16 个入口，每个入口占 128 字节。调试 ARM 中断时，第一步就是确认你当前在哪个异常级别，再看对应 VBAR 配没配好。

相比 x86 的连续表项，ARM 的向量表是“固定偏移的跳板”。中断来时，硬件直接把 PC 跳到向量表对应入口，入口处放一条跳转指令，转到完整 handler 代码。这么做省掉了查表和解门的开销，代价是每个入口空间有限，不能直接把大段 handler 堆在入口里，否则会踩到下一个入口。

4.2 GIC 中断控制器：分发与 CPU 接口

ARM 的中断没有跟 x86 那样混合进一张统一的硬件位置，而是交给独立的 GIC 芯片（或集成模块）去管理。GIC 分布在两个大块：Distributor 负责总开关、优先级、目标 CPU 路由；CPU Interface 负责跟具体 CPU 核通信，把仲裁结果通过 IRQ/FIQ 信号送到核上。

中断编号从 0 开始，有 SPI（共享外设中断）、PPI（私有外设中断）、SGI（软件生成中断）等类型。每一类在 Distributor 里的配置方式不同，SPI 可以指定任意 CPU 接收，PPI 每个 CPU 独立一份，SGI 用于核间通信。GIC 还要求软件“确认”和“结束”两步握手：中断来临时，CPU 要从 GICC_IAR 寄存器读出中断号；处理完后再往 GICC_EOIR 写入同一个中断号，表示“我处理完了，可以放下了”。

我实际调 GIC 时踩过最典型的坑，就是确认和结束没配对。如果你读完 IAR 之后忘了写 EOIR，这次中断就不会被 GIC“关闭”，会一直认为你还在处理，导致同源中断被卡死或者反复触发。写 GIC 驱动时，一定要把“读 IAR、执行、写 EOIR”这三件事当成一组不可拆散的原子流程对待。

4.3 AArch64 下的中断入口：硬件保存了什么，软件要做什么

AArch64 的中断来临时，硬件自动保存的信息非常少：把当前 PC 存入 ELR_ELx，把当前 PSTATE 存入 SPSR_ELx，然后根据“是否是同异常级别的 SP”决定用哪个栈指针，接着跳转到向量表对应入口。其余的 x0 到 x30 寄存器、SP、以及某些系统寄存器，全部需要软件自己保存。

这就意味着，无论你是写 Linux 内核的 irqchip 还是写一个裸机 RTOS，中断入口的汇编里必须有“保存所有会改动寄存器”的代码。最常规的做法是：先把通用寄存器压栈，需要时把 spsr 和 elr 也压栈，最后再调用 C 函数处理中断。返回时逆序恢复，再用 ERET 指令跳回 ELR_ELx 指向的地址。

很多人第一次写 AArch64 中断 handler 时都觉得“怎么这么麻烦”，不习惯这种半自动。但反过来想想，这正是 ARM 的优势：现场保存策略完全由软件控制，内核不需要被硬件绑定死一套压栈顺序。比如快速中断场景下，你可以只保存少数几个会被用到的寄存器，节省保存和恢复的开销。

4.4 Cortex-M 与 Cortex-A 的巨大差异：硬件压栈与 NVIC

一定要强调一下：同样是 ARM，Cortex-A 和 Cortex-M 的中断流程完全是两个世界。Cortex-M 这种微控制器使用的内核，里面集成了 NVIC（嵌套向量中断控制器），它非常“保姆”。

Cortex-M 响应中断时，硬件自动把 xPSR、PC、LR、R12、R3、R2、R1、R0 这 8 个寄存器压栈，共 32 字节。因为 PC 已经压栈，向量表里放的不再是跳转指令，而是直接放 ISR 函数的地址。处理器从向量表读取入口直接跳转。返回时用 EXC_RETURN 这个特殊值表示返回模式，硬件会根据 EXC_RETURN 的值恢复对应栈指针，并自动从栈上弹出刚才压入的寄存器。

此外，Cortex-M 还支持尾链（Tail-Chaining）和晚到（Late-Arriving）硬件优化。这两个技术能大幅降低连续中断的切换开销。如果你做的是嵌入式实时控制，选 Cortex-M 系列通常比 Cortex-A 省心得多，因为硬件替你承担了大量现场管理工作。

4.5 ARM 返回路径：eret 与 EXC_RETURN

AArch64 的返回指令是 ERET。它会从 SPSR_ELx 恢复 PSTATE，从 ELR_ELx 恢复 PC，并且会自动切换回之前的异常级别。值得注意的是，ERET 并不会像 IRET 那样帮你比较特权级或做栈切换，它只是纯粹地恢复之前保存的两个寄存器值。所以在 ARM 侧，“返回”这件事的关键往往不在 ERET 本身，而在你入栈时有没有正确保存 spsr 和 elr。

Cortex-M 的返回则完全不同。ISR 最后压入的 LR 是一个特殊的 EXC_RETURN 值，比如 0xFFFFFFF9 表示返回线程模式并使用 MSP，0xFFFFFFFD 表示返回线程模式并使用 PSP。硬件看到 EXC_RETURN 这个值，就会知道要进行异常返回，根据值的语义选择对应栈并自动弹出前面压入的 8 个寄存器。有意思的是，如果你在异常处理里不小心把 LR 覆盖掉了，返回就崩了。很多裸机新手在 Cortex-M 里做任务切换，利用的就是手动构造 EXC_RETURN 触发异常返回来实现上下文切换。

5. RISC-V 中断流程解析：极简 CSR 与 PLIC/CLINT 的分工

5.1 特权模式与中断相关的 CSR

RISC-V 作为后起之秀，在设计上走的是“极简、可扩展”的路线。中断流程没有 x86 那样庞大的描述符表，也没有 ARM 那么多异常级别下的对应寄存器，它只依靠一组小而关键的 CSR 完成底层硬件行为。

最常用的是这几个：mtvec/stvec 保存中断入口基址，mepc/sepc 保存中断返回地址，mcause/scause 记录中断原因，mstatus/sstatus 里存有全局中断使能位（MIE/SIE），mip/sip 表示挂起的中断，mie/sie 表示各中断源是否使能。M 模式和 S 模式各有一份，物理上完全是不同寄存器，切换时互不干扰。

如果你要从零写一个 RISC-V 的中断 handler，唯一必须做的就是：先读 mcause 搞清楚是啥事件，再读 mepc 记下断点，保存现场，处理完恢复现场后执行 mret。硬件不会为你压栈，也不会有任何自动现场保护，全得靠你写汇编。这既是自由，也是负担。

5.2 从触发到入口：RISC-V 的最小化硬件路径

一次典型的中断触发，硬件路径非常短：当中断信号有效、全局中断使能（MIE=1）并且对应中断使能位（mie 里的某一位）有效，CPU 就会做下面这几件事：把当前 PC 写入 mepc；把 mstatus.MIE 保存到 mstatus.MPIE，然后把 mstatus.MIE 清零，这样在当前中断处理未完成前，不会再被新的外部中断打断；把发生的中断编号和类型写入 mcause；跳转到 mtvec 指向的地址。

mtvec 有两种模式。Direct 模式下，所有中断都跳到同一个入口，用软件去 mcause 进分发；Vectored 模式下，硬件根据中断号直接跳到基础地址加偏移处，那里通常放着一组跳转指令。Vectored 模式可以省掉一次软件分发，但如果跳转表布局控制不好，很容易产生对齐问题导致段错误。

我一度很奇怪，为什么 RISC-V 不把向量表和门描述符做全。后来想想，这恰恰符合 RISC-V 的设计哲学：把硬件做薄，把策略交给软件。不同的操作系统、RTOS、裸机程序各有各的现场保存策略，硬件完全没有必要替软件规定死。代价是，各家的中断入口代码写法五花八门，你移植 RTOS 时通常要重写这一层。

5.3 外部中断的 PLIC 与定时器/软件中断的 CLINT

RISC-V 规范没有规定中断控制器必须长什么样。最常见的是两层：PLIC 管外部设备中断，CLINT 管定时器和软件中断。

PLIC 负责任务大致如下：收集多个外部中断源，按优先级仲裁，把最高优先级的路由到选定的 CPU 核。软件要处理一个外部中断时，通常先读 PLIC 的 claim 寄存器获取中断号，这相当于“确认”；处理完后写 complete 寄存器清除这个中断，以便 PLIC 可以把下一个中断提上来。整个过程和 ARM GIC 的 IAR/EOIR 很像，但寄存器地址完全由平台手册定义，没有统一标准。

CLINT 则提供 mtime 定时器，并负责在 mtime 大于 mtimecmp 时产生定时器中断。它还支持软件中断，供核间通信使用。S 模式和 M 模式的定时器中断配置略有不同，S 模式下需要额外通过 SBI 或代理机制获取时间，这块在裸机开发里经常让人头晕。

我建议你在看任何一块 RISC-V 芯片的中断代码前，先去芯片手册捞两块内容：一是 PLIC 的寄存器映射，处理器从哪个地址 claim；二是 CLINT 的 mtime 频率，因为定时器中断的计算离不开时间频率。没有这两份信息，根本无从下手。

5.4 嵌套与抢占：RISC-V 如何在软件里"补课"

RISC-V 的默认行为是：进入中断时硬件自动清除 MIE，所以当前中断处理完之前，新的外部中断产生不会立刻被响应。要支持嵌套中断，必须由软件在 handler 里手动把 mstatus.MIE 重新置 1，同时还要注意保存旧的 mstatus 和 mepc 值，否则嵌套会发生状态丢失。

这是 RISC-V 和 ARM、x86 差异很显著的一点：它的嵌套策略完全开放。你可以在门槛上直接开中断，也可以先处理完最紧急的部分再开中断，甚至可以按优先级决定什么时候允许抢占。这种灵活性对实时操作系统非常友好，但也很考验设计者水平。

我写过一版 RISC-V 的裸机中断嵌套代码，最开始的方案就是简单地在 handler 开头塞了个 “csrsi mstatus, 0x8”，结果发生了灾难性的栈溢出。因为没有把 mstatus 的旧值保存到局部栈里，嵌套返回时把 MIE 和 MPIE 关系搞乱了，中断一多就崩。后续改成在进入 handler 时把所有 CSR 也压栈作为任务上下文，问题才彻底解决。

5.5 RISC-V 返回路径：mret 与中断现场保存的 ABI 约定

RISC-V 的返回指令是 mret（M 模式）或 sret（S 模式）。mret 会把 mstatus.MPIE 写回 mstatus.MIE，然后跳转到 mepc 指向的地址。这里一定要留意：mret 本身并不恢复通用寄存器，也不弹出栈，所有通用寄存器和栈的状态恢复，必须由软件在调用 mret 之前完成。

我在写 RISC-V 中断入口时，常挂的一个问题是“谁来保存 tp（线程指针）和 gp（全局指针）”。按照 RISC-V 的 ABI，这两个寄存器通常被约定为“由被调用者保存”，但在中断场景下，中断处理程序往往不是普通函数，编译器生成的调用约定不会自动帮你存。最稳妥的办法是入口汇编里无脑把全部 x1 到 x31 都压栈，虽然浪费一些栈空间，但能避免那些极其隐蔽的寄存器覆盖 bug。

如果你用 C 语言写中断处理，也建议不要依赖编译器自动处理现场，而是用一个汇编包装函数：先保存现场、关中断，再调用 C handler，最后恢复现场、mret。这套做法在 RISC-V 世界里通用性很好，学一次就能用在一堆芯片上。

6. 三种架构的分步对照：到底各自"全自动"还是"半自动"

6.1 分步对照表：六步链路一眼看懂

为了让大家一眼看清差异，我整理了一个三架构对比表，按中断主线的六个环节逐项排列：

这张表最核心的结论是：x86 把很多中断流程细节固化在硬件里，Cortex-M 的“保姆”程度甚至比 x86 还高；Cortex-A 和 RISC-V 则走了另一条路，硬件只做最小必要的状态保存，剩下的全部交给软件。理解这个趋势后，你再看各家启动代码、Linux 源码里的中断入口，就清楚那些汇编到底在干嘛了。

6.2 向量表差异：描述符、跳板与 CSR

x86 的 IDT 是真正的“表”，每一项是门描述符，里有目标地址、特权级和类型。它支持通过 int 指令可以做的软中断来触发系统调用，逻辑灵活但比较重。

ARM 的向量表是“跳板”。每个入口 128 字节，头部放一条跳转指令。优势是硬件响应极快，不查表格直接从固定地址装载 PC；缺点是每个入口空间有限，大段逻辑需要再跳一次。

RISC-V 的向量表设计更自由。Direct 模式最省事，一个入口分发全部中断；Vectored 模式是跳转表。它没有特权级检查，也不会自己做合法校验，所有校验全靠软件在 mcause 分发时完成。从安全角度看，这增加了软件责任，但从简洁性看，也是极佳的设计。

我自己的偏好是：在裸机、RTOS 这类可控环境里，RISC-V 用 Direct 模式配合软件分发反而更容易调试；而在追求低延迟的实时场景，可以考虑 Vectored。关键是要理解每种模式的行为差异，而不是盲目套用。

6.3 现场保存策略：硬件压栈 vs 软件压栈

现场保存是三种架构区别最“硬核”的地方。

x86 中断门触发时：CPU 自动压入 SS、RSP、RFLAGS、CS、RIP，遇到特权级切换还会从 TSS 取 RSP；如果是 #PF 等异常，还额外压一个错误码。这意味着你在入口函数里看到的栈布局，基本是硬件规定死的，你不能动它的格式，只能顺着它继续压别的寄存器。

Cortex-M 是另一个极端：硬件自动压 8 个寄存器，向量表直接给 ISR 地址，返回靠 EXC_RETURN。这层硬件自动保护让单片机中断处理写起来非常舒服，但也意味着当你需要做任务上下文切换时，要额外处理 MSP/PSP 原来压入的内容，并不是“硬件帮你全包了”。

Cortex-A 和 RISC-V 则是类似风格：硬件只存断点和原因，通用寄存器现场全部由软件保存。这套方案灵活，但写起来容易漏，特别是漏保存某个调用者保存寄存器。我曾经在一次中断服务里用了 x28，却忘了在入口压栈，结果任务回来得随机崩溃，查了整整一天。

6.4 特权级与栈切换：谁切换得多，谁切换得少

三种架构对“中断要不要改栈”的处理差异，可以总结成三句话：

x86 非常强制，一旦从用户态跳入内核态处理中断，硬件一定从 TSS 加载新的 RSP，强制切换栈。这个设计很古老但稳定，解决了用户栈不可信问题。

ARM 的异常级别和栈指针绑定比较灵活。EL0 触发中断进入 EL1 时，会自动切换到 EL1 的 SP_EL1；但在同一异常级别内响应中断，则不强制换栈，可以选择用 SP_EL0 还是 SP_EL1。这种灵活性让内核可以自己决定临界区里怎么处理。

RISC-V 最灵活：它不区分“用户栈”和“内核栈”，也没有硬件栈切换指令，全看你把 sp 指向哪里。也因此，RISC-V 的裸机启动代码里，中断入口切换栈是个非常容易出错的地方，一旦 SP 没有切换到位，中断处理用的还是被中断程序的栈，很容易造成栈冲突。

对于想做 RTOS 任务切换的朋友，这个差异尤其重要。x86 的任务切换是硬件和操作系统配合，ARM 用 SVC 异常配合软件切换，RISC-V 则需要你在 trap 入口自己判断栈指针并执行切换。没有哪个更好，只有你更习惯哪一个。

7. 实操过程：在 QEMU 里用定时器中断跑通三种流程

7.1 环境准备：QEMU 与交叉工具链

理论讲完，直接上实操。我习惯用 QEMU 做这类实验，因为不需要真实硬件，还能随时看寄存器和内存。你只需要装好 QEMU 和对应的交叉编译器，就能在一台普通电脑上同时体验三种架构的中断流程。

我常用这组命令作为基础环境：

# 安装 QEMU（Ubuntu/Debian 系） sudo apt install qemu-system-misc qemu-system-arm qemu-system-x86 # RISC-V 交叉工具链 sudo apt install gcc-riscv64-unknown-elf # ARM 交叉工具链 sudo apt install gcc-arm-none-eabi # x86 用本机 gcc 即可，比如 gcc -m64

如果你的发行版不一样，包名可能略有差别。我建议先把这些工具准备好，后面每个实验都能直接跑。

7.2 RISC-V：用 QEMU 观察 mtvec、mstatus、mepc 变化

先看 RISC-V。我写一个最小裸机程序，在 M 模式配置定时器中断，然后观察中断前后几个 CSR 的变化。

核心汇编片段大概长这样：

// 设置 mtvec uintptr_t handler_addr = (uintptr_t)trap_handler; asm volatile("csrw mtvec, %0" :: "r"(handler_addr)); // 开启全局中断 asm volatile("csrsi mstatus, 0x8"); // MIE 位置1 // 配置 mtimecmp，让定时器中断立刻发生 uint64_t time = read_mtime(); write_mtimecmp(time + 1000); asm volatile("csrsi mie, 0x80"); // MTIE 位置1

中断入口里，我第一件事就是读取并打印 mepc 和 mcause。

void trap_handler(void) { uintptr_t mepc_val = read_csr("mepc"); uintptr_t mcause_val = read_csr("mcause"); printf("mepc=0x%lx mcause=0x%lx\n", mepc_val, mcause_val); // 清除定时器中断，并更新 mtimecmp 以便下次触发 write_mtimecmp(read_mtime() + 1000); asm volatile("csrc mip, 0x80"); }

在 QEMU virt 平台上启动后，日志会持续打印 mepc 在同一个位置附近跳变，mcause 为 0x80000007（表示 M 模式定时器中断）。这个实验虽然简单，但能把 RISC-V 中断流程里“硬件只改 CSR、软件自己做现场保存和恢复”的特点直接验证出来。

如果你看到 mcause 一直是 0x80000003（机器软中断）而不是定时器中断，大概率是 mtimecmp 没配正确或者没有清中断标志。排错时先确认 mtime 频率、再确认 mtimecmp 写的是完整 64 位值，最后确认读 mip 时中断挂起位是否置起。

7.3 ARM：在 QEMU 的 virt 平台上观察异常级别与 GIC 寄存器

ARM 实验我用 QEMU 的 virt 机器，同时起一个最小裸机程序，配置 GIC 和定时器中断。AArch64 下，入口汇编先保存现场，然后调用 C 函数处理。

关键代码简化如下：

// 向量表基址写入 VBAR_EL1 asm volatile("msr vbar_el1, %0" :: "r"(vector_table)); // 使能 IRQ asm volatile("msr daifclr, #2"); // 清 I 位，使能 IRQ

在 GIC 侧，需要配置 Distributor 使能对应 SPI 中断，再配置 CPU Interface 使能组 0/组 1。通常流程是：

// 使能 Distributor GICD_CTLR = 1; // 使能 CPU Interface GICC_CTLR = 1; // 配置优先级和目标 CPU GICD_IPRIORITYR[irq] = 0xa0; GICD_ITARGETSR[irq] = 1 << 0; // 使能中断 GICD_ISENABLER[irq/32] |= (1 << (irq % 32));

中断服务程序里记得读 GICC_IAR 和写 GICC_EOIR，这是我前面反复强调的成对操作。在 QEMU 里，如果只开中断不入队列、不读 IAR，会导致中断反复触发，CPU 一直卡在异常入口，看起来像死循环，其实只是没完成确认步骤。

我建议在 QEMU 里加上-d int,cpu_reset -D qemu.log参数，你会发现 QEMU 会输出每次中断注入的详细日志，能看到中断是从哪个 GIC 通道进入 CPU 的。这个日志在排查“为什么中断没触发”时极其有用。

7.4 x86：在 QEMU 中观察 IDT、TSS 切换

x86 的实验稍微麻烦一点，因为需要一个真正的引导环境。最简单的办法是在 QEMU 里跑一个很小的 32 位保护模式内核，先设置 IDT 和 TSS，再触发一次软中断或者定时器中断观察流程。

IDT 设置核心代码大致是：

struct idt_entry { uint16_t base_low; uint16_t selector; uint8_t zero; uint8_t flags; uint16_t base_high; } __attribute__((packed)); void set_idt_entry(int n, uint32_t handler) { idt[n].base_low = handler & 0xffff; idt[n].selector = 0x08; idt[n].zero = 0; idt[n].flags = 0x8e; // present + interrupt gate idt[n].base_high = (handler >> 16) & 0xffff; }

TSS 里设置内核栈：

tss.ss0 = 0x10; tss.esp0 = 0x90000;

然后在中断处理里读取 ESP，你会看到用户态触发中断后，ESP 自动切换到了内核栈地址附近。这就是 TSS 栈切换在起作用。如果你没设 TSS.esp0，这一跳会跳到 0，直接用 QEMU 跑会把 CPU 打到三异常循环里，这就是前面说的 double fault 现场。

x86 实验的小技巧是：用 QEMU 的-d int参数配合 GDB，在 IDT 入口处打断点，观察栈顶数据和 IRET 之后的状态变化。这个组合让我当年快速理解 x86 的自动压栈行为，比我读三遍 Intel 手册都管用。

8. 常见问题与排查技巧实录

8.1 中断不触发：原因排查顺序

中断不触发，是我日常被问得最多的问题，也是我自己踩过最多的问题。排查顺序很重要，别一上来就怀疑编译器优化。

第一，查“使能链”。中断要在多个层级全部使能才能真正触发。x86 要查本地 APIC 的 LVT、外设自身的 mask 位；ARM 要查 GICD 的 enable 和 CPU 的 PSTATE.I；RISC-V 要查 mie、mstatus.MIE、PLIC 的 enable 和优先级。每一层都在一条链上，任何一层关掉都不能触发。

第二，查向量表。地址对不对、模式对不对、入口代码有没有真的放到对应位置。x86 里 IDT 的 base 和 limit 要加载到 idtr；ARM 里 VBAR 要写入正确的异常级别；RISC-V 里 mtvec 的模式位不能乱设。

第三，查中断号的匹配。你是不是在中断控制器里使能了 17 号中断，但外设实际发的是 18 号？这种“号不匹配”在三种架构里都很常见，尤其是平台中断号经过控制器重映射之后。

我一般还会让外设先产生一个持续的电平信号，然后用调试器读中断控制器的“pending”寄存器，直接看硬件层面到底有没有收到请求。有了这个信息，就能判断是中断源没工作、还是中断控制器/CPU 链路断了。

8.2 频频进入中断 / 中断风暴

中断风暴的典型表现是 CPU 一直泡在中断处理里，系统看起来卡顿或完全没响应。它通常是以下原因之一。

最常见的是没有正确地“清除中断标志”。比如 x86 外设中断没有写外设的状态寄存器清除 pending；ARM GIC 没有写 EOIR；RISC-V PLIC 没有写 complete，或者定时器中断没更新 mtimecmp。只要没有清除 pending，中断就会再次触发，形成死循环。

第二常见的是嵌套配置过激。你把全局中断使能开得太早，低优先级中断反复抢占高优先级中断，栈疯狂增长。解决方法是先关中断处理临界区，确认关键状态写完之后再开中断。

我记得有一次调 RISC-V 外部中断，现象是 CPU 不断重启。后来用 QEMU 日志一查，发现 PLIC 收到了中断，但我的驱动没调用 complete，于是 PLIC 认为 handler 还没处理完，又再次把中断送入 CPU。这个坑一度让我绕了很久，最后写个小脚本统计进入中断的次数才定位到。

8.3 返回后程序跑飞 / 跳回地址不对

返回后跑飞，通常意味着恢复现场时把“返回地址”给搞错了。

在 x86 上，最常见的是忘了处理错误码，导致 IRET 把栈上的错误码当成 CS:RIP 弹出；或者中断门和陷阱门混用，IF 标志状态不对。RISC-V 上常见的问题是 mepc 被覆盖，特别是嵌套中断时，如果新的中断把 mepc 改了，而旧中断又用 mret 返回，就会飞到完全无关的地址。

ARM 上则更常见的是 ELR 没保存好。在同一异常级别里嵌套中断时，如果没有把 ELR_EL1 提前保存到栈，第二次中断会覆盖第一次的 ELR，返回时用错误地址。我建议在所有异常级别可能嵌套的场景下，无论是 ARM 还是 RISC-V，都在进入 handler 的汇编开头把断点保存到内存栈里，而不是依赖硬件寄存器一直保持不变。

调试这类问题，最有效率的方法是在 QEMU 里开日志，加上 GDB 断点看栈回溯。只要你能确定中断点地址是多少、返回后跳到了哪里、栈上数据是什么，基本就能定位是哪一步恢复错了。

8.4 嵌套中断导致栈溢出

嵌套中断可以让你的栈在瞬间爆炸，尤其是高频率中断场景。x86、ARM、RISC-V 都存在这个问题，但表现略有差异。

x86 因为中断门会自动清 IF，默认不容易嵌套；你手动开 IF 之后才会有嵌套。Cortex-M 的 NVIC 默认支持硬件抢占，也要注意分配好优先级，避免高优先级中断无限打断主线任务，导致栈使用率飙升。RISC-V 默认关 MIE，软件允许嵌套时尤其要小心，因为你每嵌套一层，现场保存量都不小。

我的建议是给中断任务分配独立的栈，并且每层嵌套都预留足够余量。在 RTOS 里，通常要给中断上下文单独一个“中断栈”，这比“直接用任务栈”安全得多。栈溢出有时候不会立刻崩溃，而是在某个特别深的调用路径上随机出问题，非常难查。

我在做一个小型 RTOS 时，主任务栈只有 4KB，中断处理函数里又有大数组，结果系统运行几小时后偶发死机。排查了很久才发现是中断嵌套栈溢出了。后来把中断栈单独划了 8KB，问题再也没出现。

8.5 向量表对齐和布局

向量表对齐是底层开发的经典坑。ARM 要求 VBAR 低 5 位（或者 6 位，视异常级别而定）必须为 0；RISC-V 的 mtvec 要求基础地址 4 字节对齐，Vectored 模式下则要按照 4 字节乘以最大中断数来对齐；x86 的 IDT 由 idtr 指出，对地址没有特别严格的对齐要求，但限制在 0 到 65535 范围内。

我在 RISC-V 上就吃过一次亏：把 mtvec 设成了一个跳转表的地址，但是编译器把表放在了 2 字节对齐的地方，导致 Vectored 模式下的偏移计算错乱，中断一进来就跑到错误指令上。这种问题用普通打印很难发现，用 GDB 看 PC 跳转位置就一目了然。

建议你在写启动代码时，给向量表加上显式的对齐属性。比如 RISC-V 的裸机代码里常写__attribute__((aligned(64)))，ARM 的向量表则用__attribute__((aligned(2048)))之类的宏，确保不同编译优化下也不会出问题。

8.6 常见问题速查表

毛病归类成一张速查表，贴在下面，方便遇到问题时一眼定位：

我自己积累的经验是：底层中断排错，永远要多用工具观察硬件状态，而不是只盯着代码逻辑。QEMU 的 -d int、GDB 的寄存器窗口、逻辑分析仪（如果真机）都是很好的辅助工具。你的目标，是尽快把问题收敛到“是没收到中断信号、还是收到了没处理、还是处理了没返回”这三者之一。只要定位到这一层，再往下分析就顺了。

最后再分享一个小心得。我每次写中断相关代码，都会在入口处打印或记录当前异常原因和返回地址，哪怕函数最终会删掉这行打印。这个习惯帮我节省了大量排查时间。底层开发最怕的不是 bug，而是你不知道系统到底执行到哪一步了；把异常信息留下，就等于给系统装了一个黑匣子。