3、RISC-V特权架构：机器模式、监督模式、用户模式，以及CSR寄存器和异常处理的初步认识
RISC-V 指令集架构最显著的特点之一，是将“通用计算”与“特权资源管理”清晰地分层。与 x86/ARM 中复杂的历史包袱不同，RISC-V 从设计之初就定义了三种特权模式（Machine Mode、Supervisor Mode、User Mode）和一套统一的控制状态寄存器（CSR）体系。理解这一章，是后续进行中断处理、虚拟内存管理、操作系统移植以及芯片级调试的基石。本章将深入剖析三种特权模式的职责边界、CSR 的访问规则，以及异常处理的硬件自动流程。
3.1 三种特权模式的核心原理与职责边界
RISC-V 规范定义了三种特权模式，分别对应不同的软件栈层次。机器模式（Machine Mode，简称 M-Mode）是权限最高的模式，也是硬件复位后默认进入的模式。M-Mode 可以访问所有 CSR 和物理内存，是可信运行时环境（如 OpenSBI、U-Boot SPL）和固件运行的场所。监督模式（Supervisor Mode，简称 S-Mode）通常运行操作系统内核，如 Linux Kernel 或 RT-Thread。S-Mode 可以访问一部分 CSR，但关键的控制寄存器（如 mstatus、mtvec）仍受 M-Mode 保护。用户模式（User Mode，简称 U-Mode）运行应用程序，权限最低，无法直接访问硬件资源，必须通过系统调用（ecall 指令）陷入 S-Mode 或 M-Mode 请求服务。
这种分层设计并非 RISC-V 独有，但 RISC-V 的精妙之处在于：它允许通过配置将某些异常直接委托给 S-Mode 处理，从而减少 M-Mode 的介入开销。例如，Linux 内核中的时钟中断和系统调用，可以通过 medeleg 和 mideleg 寄存器委托给 S-Mode，这样每次中断不需要先陷入 M-Mode 再转发到 S-Mode，显著提升了性能。
| 特性 | M-Mode（机器模式） | S-Mode（监督模式） | U-Mode（用户模式） |
|---|---|---|---|
| 典型软件 | 固件、Bootloader、OpenSBI | 操作系统内核 | 应用程序 |
| CSR 访问权限 | 全部 CSR | 部分 CSR（sstatus、stvec 等） | 极少数（fflags、frm） |
| 异常处理入口 | mtvec 指向的向量表 | stvec 指向的向量表 | 无独立入口，通过 ecall 陷入 |
| 返回指令 | mret | sret | 无 |
| 复位后默认模式 | 是 | 否 | 否 |
实战场景：在嵌入式裸机开发中，如果不需要运行操作系统，通常所有代码都运行在 M-Mode 下。此时不需要配置 medeleg，所有中断和异常都直接由 M-Mode 的 mtvec 向量表处理。而在运行 Linux 的 RISC-V 开发板上，OpenSBI 运行在 M-Mode，Linux Kernel 运行在 S-Mode，用户程序运行在 U-Mode。OpenSBI 负责将定时器中断和软件中断委托给 S-Mode，从而让 Linux 内核直接处理这些中断，避免每次陷入 M-Mode 的开销。
3.2 CSR 寄存器体系与访问规则
CSR（Control and Status Register）是 RISC-V 中用于配置和控制处理器行为的寄存器集合。每个 CSR 都有一个 12 位的地址编码，最高两位表示可访问的最低特权级。例如，mstatus 的地址是 0x300，其最高两位为 11，表示只有 M-Mode 可以访问；sstatus 的地址是 0x100，最高两位为 01，表示 S-Mode 及以上可以访问。
访问 CSR 的指令主要有 csrrw（读后写）、csrrs（读后置位）、csrrc（读后清除），以及对应的立即数版本 csrrwi、csrrsi、csrrci。这些指令在汇编层面提供了对 CSR 的原子读写操作。例如，要开启全局中断，需要将 mstatus 的 MIE 位（第 3 位）置 1：
# 开启 M-Mode 全局中断
li t0, 0x8 # MIE 位 = 1 << 3
csrrs zero, mstatus, t0 # 将 mstatus.MIE 置 1
# 读取 mcause 寄存器
csrr t0, mcause # 将异常原因编码读取到 t0在芯片级调试中，CSR 的访问权限错误是常见问题。如果 U-Mode 下的程序尝试访问 mstatus，硬件会触发非法指令异常（Illegal Instruction Exception），并将 mcause 设置为 2。调试时，可以通过检查 mcause 的值快速定位问题。
风险提示：在修改 mstatus 或 sstatus 时，务必注意 MPP/SMP 字段（记录进入异常前的特权级）。如果错误地修改了这些字段，mret 或 sret 可能返回到错误的特权级，导致系统崩溃。例如，在 M-Mode 中断处理程序中，如果错误地将 MPP 设置为 0（U-Mode），mret 后 CPU 将跳转到 U-Mode 执行，而 U-Mode 没有权限访问内核资源，立即触发异常。
3.3 异常处理的硬件自动流程与向量表设计
当异常或中断发生时，RISC-V 硬件会自动执行以下步骤（以 M-Mode 为例）：
- 将当前指令的 PC 保存到
mepc寄存器。 - 将异常原因编码写入
mcause寄存器（如 11 表示环境调用，7 表示存储访问异常）。 - 根据
mtvec寄存器配置的基地址，跳转到异常向量表。 - 如果异常是中断，还会设置
mstatus.MPIE保存之前的中断使能状态，并清除mstatus.MIE以屏蔽嵌套中断。
mtvec 寄存器支持两种模式：直接模式（Direct Mode）和向量模式（Vectored Mode）。在直接模式下，所有异常都跳转到同一个入口地址；在向量模式下，每个中断源对应一个独立的入口地址，入口地址间隔为 4 字节（或 16 字节，取决于 mtvec.MODE 字段）。对于中断密集型的应用，向量模式可以减少中断分发的时间。
# 设置 mtvec 为直接模式，入口地址为 0x80000000
la t0, trap_entry
csrw mtvec, t0
# 设置 stvec 为向量模式（MODE=1），基地址为 0x80200000
la t0, vector_table
ori t0, t0, 0x1 # 设置 MODE 字段为 1
csrw stvec, t0经验总结：在芯片调试初期，建议使用直接模式，将所有异常集中到一个入口，在入口处打印 mcause 和 mepc 的值，便于快速定位问题。当系统稳定后，再切换到向量模式以提升中断响应速度。
3.4 异常委托机制与典型应用场景
默认情况下，所有异常和中断都会跳转到 M-Mode 处理。但在实际系统中，如果每个定时器中断都要陷入 M-Mode，再由 M-Mode 转发给 S-Mode，会带来额外的上下文切换开销。RISC-V 提供了 medeleg（Machine Exception Delegation）和 mideleg（Machine Interrupt Delegation）寄存器，允许将特定的异常/中断委托给 S-Mode 处理。
例如，在运行 Linux 的 RISC-V 平台上，OpenSBI 通常会将以下中断委托给 S-Mode：
- 软件中断（Software Interrupt，用于 IPI 处理器间中断）
- 定时器中断（Timer Interrupt，用于内核调度）
- 外部中断（External Interrupt，用于 PLIC 中断控制器）
委托后，当这些中断发生时，硬件会自动跳转到 stvec 指向的 S-Mode 向量表，而 scause 会记录中断原因。S-Mode 处理完毕后，执行 sret 返回。这样，M-Mode 只在系统启动和异常兜底时介入，大大减少了运行时的开销。
| 异常类型 | mcause 编码 | 是否可委托 | 典型处理者 |
|---|---|---|---|
| 指令未对齐 | 0 | 是 | M-Mode 或 S-Mode |
| 非法指令 | 2 | 是 | M-Mode（模拟新指令） |
| 环境调用（ecall） | 11 | 是 | S-Mode（系统调用） |
| 定时器中断 | 0x80000007 | 是 | S-Mode（内核调度） |
| 外部中断 | 0x8000000B | 是 | S-Mode（PLIC 驱动） |
案例拆解：假设我们正在调试一个 RISC-V 开发板，运行 FreeRTOS 在 S-Mode，OpenSBI 在 M-Mode。系统启动后，定时器中断频繁触发，但 FreeRTOS 的调度器无法响应。通过 GDB 调试发现，mcause 始终为 0x80000007（定时器中断），且 PC 停留在 OpenSBI 的异常处理函数中。进一步检查 mideleg 寄存器，发现其值为 0，说明定时器中断没有被委托给 S-Mode。解决方案是：在 OpenSBI 初始化代码中，将 mideleg 的第 7 位置 1（对应定时器中断），并设置 stvec 指向 FreeRTOS 的中断向量表。修改后，定时器中断直接跳转到 S-Mode，FreeRTOS 调度器恢复正常。
3.5 常见误区与调试复盘
在学习和调试 RISC-V 特权架构时，初学者容易陷入以下几个误区：
- 误区一：认为所有代码都可以运行在 M-Mode。虽然技术上可行，但会丧失操作系统的内存保护和多任务隔离能力。正确的做法是：M-Mode 只做初始化、安全监控和异常兜底，业务逻辑交给 S-Mode/U-Mode。
- 误区二：忽略
mstatus.MPP字段。在中断嵌套或异常返回时，如果 MPP 设置错误，mret会返回到错误的特权级。调试时，务必在进入异常处理程序后立即保存并检查 MPP。 - 误区三：忘记同步
satp寄存器。在 S-Mode 启用虚拟内存时，satp寄存器控制页表基地址。切换进程时，需要重新加载satp并执行 SFENCE.VMA 指令刷新 TLB。如果遗漏，会导致内存访问异常。 - 误区四：中断处理程序中未保存/恢复全部上下文。RISC-V 的异常处理程序需要软件保存被中断现场的通用寄存器、
mepc、mstatus等。如果只保存部分寄存器，可能导致数据竞争或系统崩溃。
调试建议：在芯片级调试中，建议在异常处理程序的入口处添加以下调试代码：将 mcause、mepc、mstatus 的值保存到固定的内存地址，并通过串口或 JTAG 输出。这样，即使系统崩溃，也可以通过分析这些值定位异常原因。例如，如果 mcause 为 15（Store/AMO 访问异常），且 mepc 指向某个内存写指令，可以检查该地址是否越界或未对齐。
总结来说，RISC-V 的特权架构通过三种模式实现了从固件到应用程序的完整隔离，CSR 寄存器提供了精细的控制能力，而异常委托机制则兼顾了安全性和性能。掌握这些内容，是后续进行中断控制器（PLIC/CLINT）配置、虚拟内存实现和操作系统移植的基础。在下一阶段的调试中，建议读者结合 QEMU 或真实开发板，动手编写一个简单的 M-Mode 异常处理程序，逐步理解每个 CSR 的作用和异常处理的完整流程。