第2章 RISC-V特权架构与中断

2. RISC-V特权架构与中断：机器模式、监管模式、用户模式下的中断处理，mtvec/stvec寄存器详解

各位同学，咱们今天聊聊RISC-V的中断处理。说实话，中断这玩意儿，是芯片设计的核心难点之一。我当年刚入行时，就被中断优先级和模式切换搞得晕头转向。后来做了几个项目，才慢慢摸清门道。

RISC-V的特权架构，说白了就是给软件分了三个等级：机器模式（M模式）、监管模式（S模式）、用户模式（U模式）。这三个模式，就像公司的三个层级——老板、经理、员工。老板说了算，经理管日常，员工只管干活。

为什么要有这么多模式？你想想看，如果所有程序都能直接操作硬件，那系统早就乱套了。RISC-V通过特权隔离，让操作系统内核运行在S模式，应用程序跑在U模式，而最底层的硬件控制交给M模式。

M模式是最高权限模式，说白了就是「上帝模式」。它能看到所有硬件资源，能处理所有中断。我习惯把M模式比作芯片的「看门人」——所有中断进来，先经过M模式过滤一遍。

关键点：M模式的中断向量基地址由mtvec寄存器控制。这个寄存器一旦设置，就不能轻易改——除非你进入M模式本身。

S模式是操作系统内核运行的地方。它处理来自外设的中断、系统调用等。我在项目中遇到过一个问题：S模式的中断处理函数如果写得太长，会导致M模式的定时器中断被延迟——嗯，这是个坑。

U模式是应用程序的乐园。它不能直接处理中断——所有中断都会被S模式或M模式捕获。U模式想用中断？只能通过系统调用（ecall）来请求。

我的建议：设计U模式程序时，别指望它能直接响应中断。所有中断相关的操作，都通过操作系统提供的API来完成。否则，你会陷入无穷无尽的权限异常中。

mtvec是M模式的中断向量基地址寄存器。它决定了M模式中断发生后，CPU该跳到哪里去执行。

位域	名称	描述
[1:0]	MODE	0: Direct模式（直接跳转到BASE地址） 1: Vectored模式（跳转到BASE + 4 * 中断ID）
[63:2]	BASE	中断向量表的基地址，要求64字节对齐

我个人习惯用Direct模式——简单、可控。Vectored模式虽然快，但需要硬件自动查表，一旦中断表被破坏，后果很严重。

避坑指南：我曾经在项目中把mtvec的BASE地址设成了非对齐地址，结果中断一触发就跳到了错误的位置。调试了整整两天才发现是地址对齐问题。记住：BASE必须64字节对齐！

stvec是S模式的中断向量基地址寄存器。它的结构和mtvec类似，但作用域不同。

位域	名称	描述
[1:0]	MODE	0: Direct模式 1: Vectored模式
[63:2]	BASE	中断向量表的基地址，要求4字节对齐

注意：stvec的对齐要求是4字节，比mtvec宽松。为什么？因为S模式的中断处理通常更灵活，不需要那么严格的硬件对齐。

RISC-V有个很聪明的设计——中断委托。M模式可以把某些中断「下放」给S模式处理。这样M模式就不用事必躬亲了。

核心思想：中断委托的本质是「谁的地盘谁做主」。M模式只处理最核心的硬件中断，其他都交给S模式。这样既保证了安全性，又提高了效率。

咱们用一张图来梳理整个流程。这张图是我自己画的，虽然丑了点，但逻辑很清楚。

这张图展示了中断从产生到处理完成的完整路径。注意看M模式那个判断节点——它决定了中断由谁处理。这个设计很巧妙，既保留了M模式的绝对控制权，又给了S模式足够的自主权。

最后，分享几个我在项目中踩过的坑：

mtvec和stvec不要搞混：M模式的中断向量用mtvec，S模式用stvec。我见过有人把S模式的中断向量写进了mtvec，结果中断一触发就跳到了M模式——程序直接跑飞。
中断嵌套要小心：RISC-V默认不支持中断嵌套。如果你需要嵌套，得手动保存和恢复上下文。我建议非必要不嵌套，否则调试起来很痛苦。
委托不是万能的：委托给S模式的中断，M模式仍然可以拦截。所以别以为委托了就万事大吉——M模式随时可以收回控制权。

我的习惯：在项目初期，我会把所有中断都留在M模式处理。等系统稳定了，再把那些不紧急的中断委托给S模式。这样调试起来方便，出了问题也能快速定位。

好了，关于RISC-V特权架构和中断处理，咱们就聊到这儿。记住：模式切换是中断处理的核心，而mtvec和stvec就是切换的「开关」。把这两个寄存器搞明白，中断处理就成功了一半。