CSR 是 RISC-V 里最容易让人“看着都会、一写就错”的东西。地址位宽 12 位、特权模式 M/S/U 三级、几十个功能寄存器混在一起加上mstatus里那些让人头皮发麻的位域很多做嵌入式开发的朋友第一次翻 Privileged Spec 时直接劝退。这篇专栏不打算逐条翻译手册而是把 CSR 和特权架构拆成几条主线讲清楚它们怎么配合、为什么要这么设计、实际写代码和调板子时哪些位必须关注、哪些位根本不用管。看完你可以拿着它当速查手册用也能理解 M/S/U 切换时 CPU 内部到底发生了什么。如果你正在写 RISC-V 核、移植 RTOS、或者只是想搞懂mret和sret的区别这篇内容都适合你。1. 特权架构的全局认知没有 M/S/URISC-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 0000bit 11 和 bit 10 是10这代表什么查表可知10才是读写这里要小心很多手册的表格会给出一整串地址最好直接记住常见的0x300 段的mstatus是读写0xF11 段的mvendorid是只读。实际写代码时编译器和汇编器会处理这些细节但硬件设计时就必须按照这个编码规则去接 CSR 的写使能信号。CSR 的地址同时还揭示了它的功能归属。低 10 位进一步划分为几个区段0x000-0x0FFMachine 模式的浮点与状态相关 CSR0x100-0x1FFMachine 模式陷阱与中断相关 CSR0x200-0x2FFMachine 模式内存保护与计数相关 CSR0x300-0x3FFMachine 模式更底层控制mstatus、misa、mtvec 等0x500-0x5FFSupervisor 模式陷阱与中断相关 CSR0x600-0x6FFSupervisor 模式控制sstatus、stvec、satp 等0x7A0-0x7AFDebug 模式 CSR0xB00-0xBFFM 模式计数器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保存异常发生时的 PCmcause记录异常原因mstatus则负责保存和切换全局状态。这四者的配合关系可以简单类比成一扇门mtvec是门的位置CPU 遇到异常就跳到那里mepc是你在异常前正在做的事情的“书签”mcause是你为什么被叫进来的“原因”mstatus是进入门前你身上穿的“外套”mret时要把外套还回去。mstatus是 M 模式最复杂、最核心的 CSR里面每个位几乎都有讲究。常见字段包括MIEbit 3机器模式全局中断使能。为 0 时屏蔽所有 M 模式中断。MPIEbit 7进入异常前 MIE 值的备份mret时会把 MPIE 写回 MIE。MPPbit 12-11异常发生前 CPU 所处特权模式mret时恢复到这个模式。如果写入非法值00U 模式是不允许的硬件行为在 spec 里是 UNSPECIFIED这是实现时要特别注意的点。MPRVbit 17内存保护模式。为 1 时即使 CPU 当前跑在 M 模式访存时也会按照 MPP 字段指定的模式去做权限检查主要用于让 M 模式软件模拟低特权模式的内存访问。MXRbit 19可执行只读。允许从只读页取指用于把代码页当作数据页读。SUMbit 18允许 S 模式访问 U 模式页面。这在 Linux 内核拷贝用户态数据时非常关键。TVMbit 20、TWbit 21、TSRbit 22分别控制 S 模式下satp访问、wfi指令和sret指令是否需要陷入 M 模式。mtvec还有一个容易被忽视的细节它支持直接模式和向量模式。直接模式mtvec.MODE 00下所有异常都跳到同一个入口地址向量模式MODE 01下入口地址 mtvec.BASE 4 × 异常编号每个异常有自己的处理入口。硬件实现时要注意对齐直接模式要求 4 字节对齐向量模式要求4 × 最大异常数字节对齐。我见过有人把向量表 base 对齐搞错导致中断一跳就跳进非法地址排查起来很痛苦。3.2 中断与委托mie/mip/medeleg/midelegM 模式的中断控制可以分成两个维度中断源使能mie和中断挂起状态mip。mie里对应位为 1 表示该中断源被允许触发mip里对应位为 1 表示该中断源的触发条件已经满足但还没被响应。CPU 只有在mstatus.MIE 1且mie对应位为 1 且mip对应位为 1 三者同时满足时才会真正进入中断处理。常见的三个中断源是软件中断MSIbit 3、定时器中断MTIbit 7、外部中断MEIbit 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/stvecS 模式的 CSR 结构与 M 模式高度对称你可以把sstatus看作mstatus的子集stvec对应mtvecsepc对应mepcscause对应mcause。这套对称设计让内核代码和 M 模式固件在逻辑上保持一致学习成本很低。satp是 S 模式最重要的单一寄存器负责控制地址翻译。它有三个字段MODE控制翻译模式ASID是地址空间标识符PPN是根页表的物理页号。在 RV64 上常见的MODE值是Sv3939 位虚拟地址空间对应 0x8和Sv4848 位虚拟地址空间对应 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为例典型流程是CPU 捕获到异常异常原因写入scause或mcause异常编号为 8Environment call from U-mode。当前 PC 写入sepc或mepc。异常发生时 CPU 所在模式和当时的全局中断使能状态保存到sstatus.SPP和sstatus.SPIE。sstatus.SIE被清零屏蔽嵌套中断。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指向的指令仍然是一条ecallCPU 也会照常执行并再次触发异常不会出现“这次返回后抑制下一次异常”的逻辑。这在一些低功耗场景能派上用场可以通过异常嵌套反复进入处理函数但写代码时也要小心别因为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 3SSI、bit 7STI、bit 11SEI也就是三个常见的 S 模式中断源。5. CPU 设计视角CSR 实现中的 WARL 与硬连线取舍5.1 WARL 字段可写但有限制从 CPU 设计者的角度看RISC-V 的 CSR 规范里最让人头疼的莫过于 WARLWrite Any Values, Reads Legal Values字段。这类字段允许软件写入任意值但在读回时只会返回硬件支持的合法值。这样做的好处是软件可以自由试探硬件能力不必在启动时查询一长串特性列表。misa就是一个典型的 WARL 寄存器。它标识 CPU 支持的指令集扩展比如I、M、A、C、F、D等。软件在启动时通常会尝试写入一些 bit再读回看看有没有成功以此探测硬件是否支持对应扩展。硬件实现时对misa的每一位需要考虑是硬连线为常量还是用寄存器存储还是 WIRIWrite Ignored, Read Ignored。实际设计中misa的低 26 位扩展字母位通常做成寄存器但只有实现了的扩展位才允许写 1写 0 则直接忽略。mstatus.MPP也是一个 WARL 字段。RV64 上MPP只有 2 位宽合法值只有11M 模式、01S 模式、00U 模式而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. 常见问题排查与避坑速查表这里整理一份直接可用的排查表覆盖我调试过程中遇到频率最高的问题症状可能原因排查思路csrw指令触发非法指令异常当前特权模式低于 CSR 要求的最低模式写入了只读 CSR检查当前特权模式用csrr读取mstatus.MPP确认检查 CSR 地址最高两位mret返回后 PC 跳飞mepc未正确保存MPP被意外改写对照mepc和MPP的值确认在异常处理中是否误用了csrrw mstatus导致 MPP 改变中断响应后无法再次触发同类中断中断处理结束时未清mip中对应位或mstatus.MIE未恢复查看mip挂起位确认 handler 尾部的mret前是否重新使能全局中断中断入口跳转地址总是 4 字节对齐但跳错了mtvec对齐方式错误向量模式没有满足对齐要求确认mtvec.MODE和 BASE 的对齐值向量模式要求 16/32 字节对齐S 模式访问 U 模式数据页被拒绝未设置sstatus.SUM为 1在内核态执行csrrs sstatus, sstatus, 0x40000置位 SUMsatp写入后 TLB 仍使用旧页表写入satp后未执行sfence.vma在写satp后立即执行sfence.vma且确认 ASID 是否冲突非法指令异常处理后mepc指向下一条指令某些机器在异常入口会自动推进mepc检查硬件是否把mepc更新为PC4正常情况下mepc应指向故障指令本身软件中断置位了却不触发mstatus.MIE为 0mie.MSIE或mip.MSIP未置位按 MIE-mie-mip 三层逐级排查仿真波形中 CSR 读回值一直为 0CSR 译码时地址未对齐读数据通路接错检查译码 case 中地址位宽和低位掩码确认读端口是否绑定了寄存器的输出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 寄存器的行为不像普通内存那样直观一旦状态乱了恢复成本极高所以预防性记录远比事后调试划算。
CSR 是 RISC-V 里最容易让人“看着都会、一写就错”的东西。地址位宽 12 位、特权模式 M/S/U 三级、几十个功能寄存器混在一起加上mstatus里那些让人头皮发麻的位域很多做嵌入式开发的朋友第一次翻 Privileged Spec 时直接劝退。这篇专栏不打算逐条翻译手册而是把 CSR 和特权架构拆成几条主线讲清楚它们怎么配合、为什么要这么设计、实际写代码和调板子时哪些位必须关注、哪些位根本不用管。看完你可以拿着它当速查手册用也能理解 M/S/U 切换时 CPU 内部到底发生了什么。如果你正在写 RISC-V 核、移植 RTOS、或者只是想搞懂mret和sret的区别这篇内容都适合你。1. 特权架构的全局认知没有 M/S/URISC-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 0000bit 11 和 bit 10 是10这代表什么查表可知10才是读写这里要小心很多手册的表格会给出一整串地址最好直接记住常见的0x300 段的mstatus是读写0xF11 段的mvendorid是只读。实际写代码时编译器和汇编器会处理这些细节但硬件设计时就必须按照这个编码规则去接 CSR 的写使能信号。CSR 的地址同时还揭示了它的功能归属。低 10 位进一步划分为几个区段0x000-0x0FFMachine 模式的浮点与状态相关 CSR0x100-0x1FFMachine 模式陷阱与中断相关 CSR0x200-0x2FFMachine 模式内存保护与计数相关 CSR0x300-0x3FFMachine 模式更底层控制mstatus、misa、mtvec 等0x500-0x5FFSupervisor 模式陷阱与中断相关 CSR0x600-0x6FFSupervisor 模式控制sstatus、stvec、satp 等0x7A0-0x7AFDebug 模式 CSR0xB00-0xBFFM 模式计数器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保存异常发生时的 PCmcause记录异常原因mstatus则负责保存和切换全局状态。这四者的配合关系可以简单类比成一扇门mtvec是门的位置CPU 遇到异常就跳到那里mepc是你在异常前正在做的事情的“书签”mcause是你为什么被叫进来的“原因”mstatus是进入门前你身上穿的“外套”mret时要把外套还回去。mstatus是 M 模式最复杂、最核心的 CSR里面每个位几乎都有讲究。常见字段包括MIEbit 3机器模式全局中断使能。为 0 时屏蔽所有 M 模式中断。MPIEbit 7进入异常前 MIE 值的备份mret时会把 MPIE 写回 MIE。MPPbit 12-11异常发生前 CPU 所处特权模式mret时恢复到这个模式。如果写入非法值00U 模式是不允许的硬件行为在 spec 里是 UNSPECIFIED这是实现时要特别注意的点。MPRVbit 17内存保护模式。为 1 时即使 CPU 当前跑在 M 模式访存时也会按照 MPP 字段指定的模式去做权限检查主要用于让 M 模式软件模拟低特权模式的内存访问。MXRbit 19可执行只读。允许从只读页取指用于把代码页当作数据页读。SUMbit 18允许 S 模式访问 U 模式页面。这在 Linux 内核拷贝用户态数据时非常关键。TVMbit 20、TWbit 21、TSRbit 22分别控制 S 模式下satp访问、wfi指令和sret指令是否需要陷入 M 模式。mtvec还有一个容易被忽视的细节它支持直接模式和向量模式。直接模式mtvec.MODE 00下所有异常都跳到同一个入口地址向量模式MODE 01下入口地址 mtvec.BASE 4 × 异常编号每个异常有自己的处理入口。硬件实现时要注意对齐直接模式要求 4 字节对齐向量模式要求4 × 最大异常数字节对齐。我见过有人把向量表 base 对齐搞错导致中断一跳就跳进非法地址排查起来很痛苦。3.2 中断与委托mie/mip/medeleg/midelegM 模式的中断控制可以分成两个维度中断源使能mie和中断挂起状态mip。mie里对应位为 1 表示该中断源被允许触发mip里对应位为 1 表示该中断源的触发条件已经满足但还没被响应。CPU 只有在mstatus.MIE 1且mie对应位为 1 且mip对应位为 1 三者同时满足时才会真正进入中断处理。常见的三个中断源是软件中断MSIbit 3、定时器中断MTIbit 7、外部中断MEIbit 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/stvecS 模式的 CSR 结构与 M 模式高度对称你可以把sstatus看作mstatus的子集stvec对应mtvecsepc对应mepcscause对应mcause。这套对称设计让内核代码和 M 模式固件在逻辑上保持一致学习成本很低。satp是 S 模式最重要的单一寄存器负责控制地址翻译。它有三个字段MODE控制翻译模式ASID是地址空间标识符PPN是根页表的物理页号。在 RV64 上常见的MODE值是Sv3939 位虚拟地址空间对应 0x8和Sv4848 位虚拟地址空间对应 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为例典型流程是CPU 捕获到异常异常原因写入scause或mcause异常编号为 8Environment call from U-mode。当前 PC 写入sepc或mepc。异常发生时 CPU 所在模式和当时的全局中断使能状态保存到sstatus.SPP和sstatus.SPIE。sstatus.SIE被清零屏蔽嵌套中断。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指向的指令仍然是一条ecallCPU 也会照常执行并再次触发异常不会出现“这次返回后抑制下一次异常”的逻辑。这在一些低功耗场景能派上用场可以通过异常嵌套反复进入处理函数但写代码时也要小心别因为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 3SSI、bit 7STI、bit 11SEI也就是三个常见的 S 模式中断源。5. CPU 设计视角CSR 实现中的 WARL 与硬连线取舍5.1 WARL 字段可写但有限制从 CPU 设计者的角度看RISC-V 的 CSR 规范里最让人头疼的莫过于 WARLWrite Any Values, Reads Legal Values字段。这类字段允许软件写入任意值但在读回时只会返回硬件支持的合法值。这样做的好处是软件可以自由试探硬件能力不必在启动时查询一长串特性列表。misa就是一个典型的 WARL 寄存器。它标识 CPU 支持的指令集扩展比如I、M、A、C、F、D等。软件在启动时通常会尝试写入一些 bit再读回看看有没有成功以此探测硬件是否支持对应扩展。硬件实现时对misa的每一位需要考虑是硬连线为常量还是用寄存器存储还是 WIRIWrite Ignored, Read Ignored。实际设计中misa的低 26 位扩展字母位通常做成寄存器但只有实现了的扩展位才允许写 1写 0 则直接忽略。mstatus.MPP也是一个 WARL 字段。RV64 上MPP只有 2 位宽合法值只有11M 模式、01S 模式、00U 模式而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. 常见问题排查与避坑速查表这里整理一份直接可用的排查表覆盖我调试过程中遇到频率最高的问题症状可能原因排查思路csrw指令触发非法指令异常当前特权模式低于 CSR 要求的最低模式写入了只读 CSR检查当前特权模式用csrr读取mstatus.MPP确认检查 CSR 地址最高两位mret返回后 PC 跳飞mepc未正确保存MPP被意外改写对照mepc和MPP的值确认在异常处理中是否误用了csrrw mstatus导致 MPP 改变中断响应后无法再次触发同类中断中断处理结束时未清mip中对应位或mstatus.MIE未恢复查看mip挂起位确认 handler 尾部的mret前是否重新使能全局中断中断入口跳转地址总是 4 字节对齐但跳错了mtvec对齐方式错误向量模式没有满足对齐要求确认mtvec.MODE和 BASE 的对齐值向量模式要求 16/32 字节对齐S 模式访问 U 模式数据页被拒绝未设置sstatus.SUM为 1在内核态执行csrrs sstatus, sstatus, 0x40000置位 SUMsatp写入后 TLB 仍使用旧页表写入satp后未执行sfence.vma在写satp后立即执行sfence.vma且确认 ASID 是否冲突非法指令异常处理后mepc指向下一条指令某些机器在异常入口会自动推进mepc检查硬件是否把mepc更新为PC4正常情况下mepc应指向故障指令本身软件中断置位了却不触发mstatus.MIE为 0mie.MSIE或mip.MSIP未置位按 MIE-mie-mip 三层逐级排查仿真波形中 CSR 读回值一直为 0CSR 译码时地址未对齐读数据通路接错检查译码 case 中地址位宽和低位掩码确认读端口是否绑定了寄存器的输出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 寄存器的行为不像普通内存那样直观一旦状态乱了恢复成本极高所以预防性记录远比事后调试划算。
