企业官网建设流程全解析

CSR 是 RISC-V 里最容易让人“看着都会、一写就错”的东西。地址位宽 12 位、特权模式 M/S/U 三级、几十个功能寄存器混在一起，加上mstatus里那些让人头皮发麻的位域，很多做嵌入式开发的朋友第一次翻 Privileged Spec 时直接劝退。这篇专栏不打算逐条翻译手册，而是把 CSR 和特权架构拆成几条主线，讲清楚它们怎么配合、为什么要这么设计、实际写代码和调板子时哪些位必须关注、哪些位根本不用管。看完你可以拿着它当速查手册用，也能理解 M/S/U 切换时 CPU 内部到底发生了什么。如果你正在写 RISC-V 核、移植 RTOS、或者只是想搞懂mret和sret的区别，这篇内容都适合你。

1. 特权架构的全局认知：没有 M/S/U，RISC-V 就是一块裸金属

1.1 单模式处理器的困境

假设一个 CPU 只有一个运行模式，所有程序都能执行全部指令、访问全部内存。这对 bare-metal 的小项目没问题，但一旦跑操作系统，麻烦立刻出现：用户程序可以用一条csrw直接改写中断入口，可以把页表关掉，可以把自己进程的特权级抬上去，甚至可以读取任意物理内存里的敏感数据。整个系统没有任何隔离边界，任何一个用户程序的 bug 都能让整机崩溃，更谈不上安全性。

RISC-V 的特权架构解决的就是这个问题。它把 CPU 的运行状态分成机器模式（M）、监督模式（S）、用户模式（U），每个模式有对应的权限边界：能执行什么指令、能访问哪些 CSR、能触碰哪些内存区域，全部由硬件强制约束。U 模式想干特权操作，必须先触发异常，把控制权交给更高特权级的软件，由高特权软件来裁决、代为执行。这个过程就是操作系统领域常说的 trap。

1.2 三模式各自的分工

三个模式的定位差异非常大。M 模式是 RISC-V 里权限最高的模式，也是唯一必须实现的模式。它直接管理物理资源：配置中断控制器、设置 PMP 物理内存保护、决定哪些异常可以委托给 S 模式处理。嵌入式裸机程序、安全监视器、开机引导代码都跑在 M 模式，它相当于是整个系统的“硬件管家”。

S 模式是给操作系统内核准备的。它在 M 模式之下，但在 U 模式之上，拥有独立的异常入口、中断开关和页表寄存器。Linux、RT-Thread SMP 这类系统跑在 S 模式上，用户进程则放在 U 模式。S 模式通过satp寄存器开启基于虚拟地址的页表翻译，U 模式进程的内存隔离就是靠这一层实现的。

U 模式权限最低，只能访问自己的地址空间和一部分不影响系统状态的 CSR。普通应用程序就运行在这层，它无法直接改写中断向量、无法关中断、无法修改页表。如果一个 U 模式程序想读取系统信息，或者想请求内核提供某个服务，只能通过ecall指令发出环境调用，让控制权落入 S 模式或 M 模式，由内核代劳。

这三个模式合在一起，构成了 RISC-V 软件生态的地基。后面所有 CSR 的讨论，都得先放在这个 M/S/U 的框架下理解才不拧巴。记住一句话：CSR 的可读可写性，本质上是特权模式权限的直接体现。

2. CSR 的基础规则：地址、访问指令与读写语义

2.1 12 位 CSR 地址空间的布局逻辑

CSR 藏在 CPU 内部，数量取决于具体实现，但全部挂在同一个 12 位地址空间里，地址范围 0x000 到 0xFFF，总共 4096 个位置。这里有个关键点：并不是所有地址都有寄存器，CPU 设计者只会实现自己需要的 CSR，访问不存在的地址会直接触发非法指令异常。

12 位地址在硬件上被分成两组。地址的最高两位（bit 11 和 bit 10）标识 CSR 的读写属性：11表示该 CSR 同时支持读写，01表示只读。如果对只读 CSR 执行写操作，会触发非法指令异常。这也意味着，只要看地址的最高两位，就能立刻判断一个 CSR 能不能写。比如mcycle的地址是 0xB00，最高两位是10？不对，0xB00 的二进制是 1011 0000 0000，bit 11 和 bit 10 是10，这代表什么？查表可知10才是读写？这里要小心，很多手册的表格会给出一整串地址，最好直接记住常见的：0x300 段的mstatus是读写，0xF11 段的mvendorid是只读。实际写代码时，编译器和汇编器会处理这些细节，但硬件设计时就必须按照这个编码规则去接 CSR 的写使能信号。

CSR 的地址同时还揭示了它的功能归属。低 10 位进一步划分为几个区段：

• 0x000-0x0FF：Machine 模式的浮点与状态相关 CSR
• 0x100-0x1FF：Machine 模式陷阱与中断相关 CSR
• 0x200-0x2FF：Machine 模式内存保护与计数相关 CSR
• 0x300-0x3FF：Machine 模式更底层控制（mstatus、misa、mtvec 等）
• 0x500-0x5FF：Supervisor 模式陷阱与中断相关 CSR
• 0x600-0x6FF：Supervisor 模式控制（sstatus、stvec、satp 等）
• 0x7A0-0x7AF：Debug 模式 CSR
• 0xB00-0xBFF：M 模式计数器
• 0xC00-0xCFF：只读计数器

这个布局不是随便排的，功能相关的寄存器会凑在一起。比如 S 模式的所有 trap 相关寄存器都在 0x100-0x1FF 的“高半区”，M 模式的 trap 相关寄存器则在 0x300-0x3FF。地址位本身就是在给硬件设计者做译码提示。

2.2 csrrw/csrrs/csrrc 四条指令的语义差别

RISC-V 定义了 4 条 CSR 访问指令：csrrw、csrrs、csrrc，以及它们对应的立即数版本csrrwi、csrrsi、csrrci。很多人一开始容易搞混csrrs和csrrc的区别，其实只要抓住“读-清-写”的操作语义就清楚。

csrrw是把 CSR 的旧值读到 rd，然后把 rs1 的新值写入 CSR，属于整字替换。csrrs则是先把 CSR 旧值读到 rd，再把 rs1 中为 1 的位与 CSR 当前值进行按位或，也就是说它只置位不清理。csrrc与之对应，把 rs1 中为 1 的位在 CSR 中清零，其他位不动。注意这三个操作都同时完成“读旧值”和“改新值”，并且在硬件上必须是原子的，中间不允许被打断。

这种读-改-写原子性对并发场景特别重要。典型例子是mie寄存器：要开一个中断，用csrrs置位对应 bit 就行；要关一个中断，用csrrc清位就行。如果拆成“先读再写”两条指令，在中断处理过程中极有可能把别的中断状态覆盖掉。RISC-V 直接把这步合并成单条指令，把原子性的责任放在硬件上，软件就不用费心加锁了。

汇编里常见写法：

# 读取 mtvec csrr t0, mtvec # 把 mie 的 bit 7 置 1（假设是机器定时器中断） csrrsi t0, mie, 0x80 # t0 读出旧值，mie 的 bit7 被置位 # 把 mip 的 bit 3 清零（清除外部中断挂起标志） csrrci t0, mip, 0x08

当然，实际 C 语言中用内联汇编或read_csr/write_csr宏更常见，但底层语义完全一致。

2.3 读清写置：一个容易忽略的硬件行为

写中断状态类 CSR 时，软件习惯上只修改自己关心的那几个 bit，不希望影响其他中断位。csrrs和csrrc正是为此设计，它们只动 rs1 里为 1 的位，对 0 的位保持原样。这个行为叫“读后置位”和“读后清除”，与之相对的csrrw是整体覆写。

实际使用中有一个高频坑：想通过csrrw给mstatus写入一个新值时，如果不小心把整个值算错，很容易把MPP、MPIE这些关键状态位清掉，导致mret返回地址错误。反之用csrrs/csrrc操作mstatus的单个位（比如修改全局中断使能MIE）就安全很多。建议：能按位操作就不要整体覆写，能局部修改就不要全量赋值。这条经验在写中断嵌套、任务切换代码时能帮你省一堆调试时间。

3. 常用 CSR 速查表：从 M 模式到 S/U 模式

3.1 机器模式：mstatus/mtvec/mepc/mcause 是异常处理的四件套

M 模式的异常处理离不开四个寄存器：mstatus、mtvec、mepc、mcause。mtvec保存异常入口地址，mepc保存异常发生时的 PC，mcause记录异常原因，mstatus则负责保存和切换全局状态。这四者的配合关系可以简单类比成一扇门：mtvec是门的位置，CPU 遇到异常就跳到那里；mepc是你在异常前正在做的事情的“书签”；mcause是你为什么被叫进来的“原因”；mstatus是进入门前你身上穿的“外套”，mret时要把外套还回去。

mstatus是 M 模式最复杂、最核心的 CSR，里面每个位几乎都有讲究。常见字段包括：

• MIE（bit 3）：机器模式全局中断使能。为 0 时屏蔽所有 M 模式中断。
• MPIE（bit 7）：进入异常前 MIE 值的备份，mret时会把 MPIE 写回 MIE。
• MPP（bit 12-11）：异常发生前 CPU 所处特权模式，mret时恢复到这个模式。如果写入非法值00（U 模式）是不允许的，硬件行为在 spec 里是 UNSPECIFIED，这是实现时要特别注意的点。
• MPRV（bit 17）：内存保护模式。为 1 时，即使 CPU 当前跑在 M 模式，访存时也会按照 MPP 字段指定的模式去做权限检查，主要用于让 M 模式软件模拟低特权模式的内存访问。
• MXR（bit 19）：可执行只读。允许从只读页取指，用于把代码页当作数据页读。
• SUM（bit 18）：允许 S 模式访问 U 模式页面。这在 Linux 内核拷贝用户态数据时非常关键。
• TVM（bit 20）、TW（bit 21）、TSR（bit 22）：分别控制 S 模式下satp访问、wfi指令和sret指令是否需要陷入 M 模式。

mtvec还有一个容易被忽视的细节：它支持直接模式和向量模式。直接模式（mtvec.MODE = 00）下，所有异常都跳到同一个入口地址；向量模式（MODE = 01）下，入口地址 =mtvec.BASE + 4 × 异常编号，每个异常有自己的处理入口。硬件实现时要注意对齐：直接模式要求 4 字节对齐，向量模式要求4 × 最大异常数字节对齐。我见过有人把向量表 base 对齐搞错，导致中断一跳就跳进非法地址，排查起来很痛苦。

3.2 中断与委托：mie/mip/medeleg/mideleg

M 模式的中断控制可以分成两个维度：中断源使能（mie）和中断挂起状态（mip）。mie里对应位为 1 表示该中断源被允许触发，mip里对应位为 1 表示该中断源的触发条件已经满足但还没被响应。CPU 只有在mstatus.MIE = 1且mie对应位为 1 且mip对应位为 1 三者同时满足时，才会真正进入中断处理。

常见的三个中断源是：软件中断MSI（bit 3）、定时器中断MTI（bit 7）、外部中断MEI（bit 11）。注意 RISC-V 的中断号是固定的：软件中断号为 3，定时器中断号为 7，外部中断号为 11。这与 ARM 的中断向量表设计思路完全不同。

委托机制是 RISC-V 特权架构的一个巧妙设计。medeleg控制异常委托，mideleg控制中断委托，两个寄存器都是 12 位宽，每一位对应一个异常/中断号。比如把medeleg的 bit 1（非法指令异常）置 1，那么 U 模式或 S 模式触发非法指令时，CPU 不进入 M 模式，而是直接跳转到 S 模式的stvec。委托的本质是：M 模式软件主动把一部分异常处理的“权力”下放给 S 模式，避免每一次系统调用都要经过 M 模式转手。

实际跑 Linux 的时候，几乎所有常见异常（系统调用、缺页、非法指令）都会被委托给 S 模式，M 模式只处理少数平台级事件。这样设计的原因很实在：如果每次系统调用都先进 M 模式，再由 M 模式软件转发给 S 模式，等于多了一层上下文切换，性能损失很大。

3.3 监督模式与地址翻译：sstatus/satp/stvec

S 模式的 CSR 结构与 M 模式高度对称，你可以把sstatus看作mstatus的子集，stvec对应mtvec，sepc对应mepc，scause对应mcause。这套对称设计让内核代码和 M 模式固件在逻辑上保持一致，学习成本很低。

satp是 S 模式最重要的单一寄存器，负责控制地址翻译。它有三个字段：MODE控制翻译模式，ASID是地址空间标识符，PPN是根页表的物理页号。在 RV64 上，常见的MODE值是Sv39（39 位虚拟地址空间，对应 0x8）和Sv48（48 位虚拟地址空间，对应 0x9）。每次写satp时，CPU 会刷新 TLB 中属于当前 ASID 的缓存项，这本质上是一种软件控制的 TLB 失效操作。

执行satp写入时有一点必须留意：在 RV64 上，satp的高位（bit 63 及未使用的 bit）必须为零，否则结果未定义。Linux 内核里__tlbsync()这类代码会先写satp再执行sfence.vma，顺序不能反过来，否则页表缓存可能残留旧映射，造成访问非法地址还不报错的诡异现象。

3.4 关于“CSR 压缩存储”的补充说明

有朋友看到“CSR 压缩存储”这几个字，以为是 RISC-V 的 CSR 做了某种压缩编码来省内存。其实不是。在 RISC-V 语境下，CSR 是 Control and Status Register 的缩写，指的是 CPU 内部寄存器；而在图论和数值计算领域，CSR 是 Compressed Sparse Row 的缩写，是一种稀疏矩阵压缩存储格式，两者完全是两码事。

如果你搜索时看到“邻接表和 CSR 压缩存储内存空间消耗是同一个量级吗”，那讨论的是图存储结构：邻接表用链表存边，CSR 用两个数组（偏移数组+邻接数组）存边，两者都能压缩稀疏图的空间，量级上差异不大，但 CSR 的存储更紧凑且能利用连续内存，所以实际内存占用通常更小，适合对缓存友好的场景。这个主题本质上与 RISC-V 无关，属于容易搜串门的误区，顺手帮你排掉。

4. 模式切换的完整链路：ecall、mret 与中断委托

4.1 ecall 陷入的完整流程

ecall是 RISC-V 里发起系统调用的核心指令。执行ecall后，CPU 会先根据当前特权模式和委托配置决定异常目标：如果异常委托给了 S 模式，就进入 S 模式；否则直接进入 M 模式。以 U 模式进程执行ecall为例，典型流程是：

1. CPU 捕获到异常，异常原因写入scause（或mcause），异常编号为 8（Environment call from U-mode）。
2. 当前 PC 写入sepc（或mepc）。
3. 异常发生时 CPU 所在模式和当时的全局中断使能状态，保存到sstatus.SPP和sstatus.SPIE。
4. sstatus.SIE被清零，屏蔽嵌套中断。
5. PC 跳转到stvec（或mtvec）指定的入口地址。

这套流程里，最关键的一点是：异常发生时 CPU 不会自动切换栈指针。也就是说进入异常处理函数后，软件必须自己保存通用寄存器、自己切换栈。RISC-V 没有硬件压栈机制，这是它和 ARM Cortex-M 系列一个很大的差异。所以写 RISC-V 的 trap handler 时，第一步永远是先分配一段独立的异常栈，避免复用被中断任务栈导致栈溢出。

4.2 mret/sret 返回的还原逻辑

mret和sret是异常返回指令，逻辑对称。mret从 M 模式异常中返回，动作包括：把mstatus.MPIE写回mstatus.MIE，把mstatus.MPP写回当前特权模式，把 PC 设置为mepc。sret用于 S 模式异常，对应还原sstatus.SPIE和sstatus.SPP。

这个还原逻辑解决了一个常见的疑问：为什么进入异常时要额外保存MPP和MPIE？因为在处理异常的过程中，M 模式软件可能嵌套处理更高优先级异常，或者主动打开中断，MIE的值早就变了。如果不备份原始状态，返回时根本不知道要恢复成什么样子。MPP和MPIE就是在异常入口“自动拍快照”，mret时“自动还原”。

还有一个细节值得注意：mret执行后，即使mepc指向的指令仍然是一条ecall，CPU 也会照常执行并再次触发异常，不会出现“这次返回后抑制下一次异常”的逻辑。这在一些低功耗场景能派上用场：可以通过异常嵌套反复进入处理函数，但写代码时也要小心别因为mepc没推进而陷入死循环。

4.3 委托机制让 S 模式接管大多数异常

委托机制设计得非常有思路。如果没有委托，S 模式内核每次处理系统调用，都需要先陷入 M 模式，M 模式软件再把执行权交给 S 模式。这意味着除了用户态/内核态的切换，还要额外多一层“M 模式中间人”。有了medeleg和mideleg，硬件直接让异常目标落在 S 模式，省掉了这层中间环节。

委托的配置入口有两个：medeleg处理同步异常委托，mideleg处理中断委托。在 RV64 上，这两个寄存器都是低 12 位有效。常见的设置是：把medeleg里除breakpoint（异常号 3）、machine external（中断号 11）、machine timer（中断号 7）之外的所有异常全部委托给 S 模式。值得强调：中断号 11（机器外部中断）和中断号 7（机器定时器中断）不能被委托给 S 模式，因为中断编号空间里高位代表 M 模式专属。如果你想在 S 模式里接收外部中断，需要借助 AIA 或 PLIC 的中断转发机制，并不直接通过mideleg完成。

配置委托的典型 C 代码：

// 将绝大多数同步异常委托给 S 模式 write_csr(medeleg, 0xffff); // 将 S 模式软件中断、定时器中断、外部中断委托下去 write_csr(mideleg, 0x888);

注意这里 0x888 对应 bit 3（SSI）、bit 7（STI）、bit 11（SEI），也就是三个常见的 S 模式中断源。

5. CPU 设计视角：CSR 实现中的 WARL 与硬连线取舍

5.1 WARL 字段：可写但有限制

从 CPU 设计者的角度看，RISC-V 的 CSR 规范里最让人头疼的莫过于 WARL（Write Any Values, Reads Legal Values）字段。这类字段允许软件写入任意值，但在读回时只会返回硬件支持的合法值。这样做的好处是：软件可以自由试探硬件能力，不必在启动时查询一长串特性列表。

misa就是一个典型的 WARL 寄存器。它标识 CPU 支持的指令集扩展，比如I、M、A、C、F、D等。软件在启动时通常会尝试写入一些 bit，再读回看看有没有成功，以此探测硬件是否支持对应扩展。硬件实现时，对misa的每一位需要考虑是硬连线为常量，还是用寄存器存储，还是 WIRI（Write Ignored, Read Ignored）。实际设计中，misa的低 26 位（扩展字母位）通常做成寄存器，但只有实现了的扩展位才允许写 1，写 0 则直接忽略。

mstatus.MPP也是一个 WARL 字段。RV64 上MPP只有 2 位宽，合法值只有11（M 模式）、01（S 模式）、00（U 模式），而10是保留组合。如果软件写入10，硬件在读回时可能返回00或11，具体行为由实现决定。留给设计者的关键是：对 WARL 字段做写入过滤时，不能简单把低位截断，因为很多 WARL 字段并不是简单地丢弃高位，而是按合法集合做映射。比如MPP的合法值是高位为1的组合，你如果只保留 bit 12 而忽略 bit 11，就会把S模式误映射成M模式。

5.2 几条务实的实现建议

我在写一个教育级 RISC-V 核时总结了几条 CSR 实现的实用经验，这里有参考价值：

第一，CSR 模块不要做成集中式大寄存器堆，而是散落在各个功能子模块旁边。比如mepc放在取指/异常处理模块，mstatus放在模式管理模块，mie放在中断控制器旁边。这样每个模块只需驱动自己那几根线，综合时序更好收敛，调试时也不用在巨大的 case 语句里翻地址。

第二，写使能的控制逻辑要统一。每个 CSR 的写使能信号应该由(当前特权模式 >= 该 CSR 要求的最低模式) & (该 CSR 可写) & (有写入指令)三者的组合生成。最高两位（bit 11、bit 10）等于11只代表“可写”，不等于“当前模式允许写”，这两件事要分开判断。很多初学者写 CSR 译码时，只检查地址不检查模式，结果 U 模式程序一执行csrw，硬件没有触发非法指令异常，安全模型直接破功。

第三，CSR 的读数据通路不要和写数据通路混在一起。读操作要求组合逻辑输出，写操作要求时序寄存器接收，二者路径完全不同。分开设计有助于时序收敛，也便于在仿真波形里单独观察读回值。

第四，mcycle和minstret这类计数器至少做成 64 位宽的寄存器。RV32 实现中可以拆成两个 32 位，通过mcycleh/minstreth分别访问，但拆分时要注意高半字的更新和低半字的回卷逻辑，否则会遭遇计数器跳变。

5.3 自测小技巧：用非法 CSR 访问验证异常入口

CPU 设计完以后，CSR 通路是否正常工作，有一个非常高效的验证方法：构造一条从 U 模式发起的csrw非法指令，检查能否正确触发非法指令异常并跳转到 M 模式处理入口。

具体做法是：让 CPU 先跑一段 M 模式代码，配置好mtvec和mepc，然后切换到 U 模式执行一条csrw mstatus, t0。如果硬件行为正确，CPU 应该进入 M 模式的异常入口，mcause应该读到 2（非法指令），mepc应指向这条csrw指令本身。这条测试能同时验证四件事：U 模式的权限限制、CSR 译码逻辑、异常入口跳转、mepc对异常指令的捕获。几乎所有 CSR 相关的门级 bug，都能通过这类最小用例快速暴露出来，比直接跑 Linux 调试省太多时间。

6. 常见问题排查与避坑速查表

这里整理一份直接可用的排查表，覆盖我调试过程中遇到频率最高的问题：

6.1 调试 CSR 最顺手的仿真技巧

调试 CSR，最顺手的工具不是逻辑分析仪，而是波形里的一组辅助观察信号。建议在 CPU 里引出几个 debug-only 信号：当前特权模式、当前执行的 CSR 地址、CSR 写使能、mstatus全字段值。在仿真时把这几根线单独拉出来看，几乎所有 CSR 相关的异常行为都能直接定位。

我踩过最深的一个坑，是mstatus里MPRV位的忘关问题。当时在 M 模式固件里用MPRV临时模拟 S 模式访问用户内存，用完后忘了清位，结果后面所有对外设寄存器的访问都带上了“S 模式权限 + MPP 指向 S 模式”的滤镜，导致外设访问全部失败。排查过程异常痛苦，最后靠波形里盯MPRV才找到根因。这类“状态残留”型的 bug，在 CSR 模块里特别常见，建议在每次特权模式切换、每次函数返回前都梳理一遍自己改过哪些 CSR 位。

6.2 给新手的两个实操建议

如果你刚开始接触 RISC-V 特权架构，我的建议是先在 QEMU 的sifive_u或virt机器上跑一遍 M 模式的 trap handler，把mtvec、mepc、mcause四个寄存器的行为摸透，然后再尝试打开 S 模式。不要一上来就啃 Linux。先把ecall->mret这个最小闭环跑通，再逐步加入外部中断、U 模式切换、页表开关，每一步都能稳定复现后再进下一步。

另外，强烈建议在代码里维护一份“CSR 使用日志”。每次修改一个 CSR，就在注释里写清楚：改了哪个位、为什么改、预期效果是什么、对应规范哪一节。这个习惯在查 bug 时能帮你把排查范围从“整个 CPU”缩小到“某个 CSR 位”，效率提升不是一点半点。CSR 寄存器的行为不像普通内存那样直观，一旦状态乱了，恢复成本极高，所以预防性记录远比事后调试划算。