📚 课程目录第4章监督态（S-mode）特性

监督态（S-mode）特性：监督态职责、中断与异常处理入口，以及操作系统内核运行的基础

在 RISC-V 特权级架构中，监督态（Supervisor Mode，S-mode）是连接用户态（U-mode）与机器态（M-mode）的中间桥梁。它既不是权限最高的可信执行环境，也不是直接面向应用程序的执行层，而是操作系统内核赖以生存的“主战场”。理解 S-mode 的职责边界、异常处理入口以及其与 M-mode 的协作关系，是掌握 RISC-V 系统软件设计的关键。本章将深入剖析 S-mode 的核心特性，从职责划分、中断异常入口机制到内核运行的基础设施，并结合实际案例帮助读者建立完整的监督态运行视图。

监督态的核心职责与权限边界

S-mode 的职责可以概括为“承上启下”：向上承接 M-mode 委托的异常与中断，向下管理 U-mode 的进程执行与资源隔离。在 RISC-V 规范中，S-mode 拥有独立的 CSR 寄存器组、地址翻译机制以及中断控制能力，这使得操作系统内核可以在不依赖 M-mode 干预的情况下完成绝大多数系统管理任务。

从权限模型来看，S-mode 可以执行所有 U-mode 指令，但无法直接访问 M-mode 的私有 CSR（如 mstatus、mepc、mideleg 等）。这种设计保证了机器态固件（如 OpenSBI、U-Boot）的权威，同时给予内核足够的自主权。S-mode 的典型职责包括：

进程管理：创建、调度、终止用户态进程，处理上下文切换。
内存管理：通过 satp 寄存器维护页表，实现虚拟地址到物理地址的映射。
中断与异常处理：接收来自 U-mode 的 ecall、页错误、非法指令等异常，以及定时器、外部设备中断。
系统调用接口：作为 U-mode 请求内核服务的唯一入口（通过 ecall 指令）。
虚拟化支持（可选）：在支持 H 扩展的处理器上，S-mode 还可作为 Type-2 虚拟化监视器（Hypervisor）运行。

核心原理：S-mode 的权限边界由 mstatus.MPP 字段和 mideleg/medeleg 委托寄存器共同决定。当 U-mode 发生异常时，处理器首先检查该异常是否被委托给 S-mode；若已委托，则直接陷入 S-mode，否则陷入 M-mode。这种机制避免了所有异常都经过 M-mode 造成的性能损耗。

中断与异常处理入口：stvec 与 trap 流程

S-mode 的异常处理入口由 stvec（Supervisor Trap Vector Base Address）寄存器指定。stvec 包含两个字段：BASE（异常处理基地址）和 MODE（向量模式）。MODE 字段支持两种模式：Direct（直接模式）和 Vectored（向量模式）。在 Direct 模式下，所有异常都跳转到 BASE 地址；在 Vectored 模式下，中断根据 cause 编号偏移跳转，而异常仍跳转到 BASE。

当 S-mode 接收到一个 trap（中断或异常）时，硬件自动执行以下操作：

将当前 PC 保存到 sepc 寄存器。
将 trap 原因编码写入 scause 寄存器（最高位为 1 表示中断，低 63 位为中断/异常编号）。
将附加信息（如触发异常的虚拟地址）写入 stval 寄存器。
将 sstatus.SIE（全局中断使能）清零，屏蔽嵌套中断。
将当前特权级保存到 sstatus.SPP 字段，并将特权级切换为 S-mode。
跳转到 stvec 指定的地址开始执行。

内核的 trap 处理程序需要完成上下文保存、原因分发、处理执行和恢复返回四个阶段。以下是一个典型的 S-mode trap 入口汇编代码片段：

trap_entry:
    # 保存通用寄存器到内核栈
    sd sp, -8(sp)
    sd ra, -16(sp)
    sd gp, -24(sp)
    sd tp, -32(sp)
    # ... 保存所有 x1-x31 寄存器
    
    # 读取 scause 和 sepc
    csrr t0, scause
    csrr t1, sepc
    csrr t2, stval
    
    # 根据 scause 分发处理
    bgez t0, handle_exception   # 最高位为 0 表示异常
    # 中断处理路径
    call handle_interrupt
    j trap_exit
    
handle_exception:
    # 异常处理路径
    call handle_exception_c
    j trap_exit
    
trap_exit:
    # 恢复寄存器
    ld ra, -16(sp)
    ld gp, -24(sp)
    # ... 恢复所有寄存器
    sret    # 返回 U-mode 或继续执行

操作系统内核运行的基础设施

S-mode 为操作系统内核提供了三大关键基础设施：地址翻译机制、中断控制器接口和定时器支持。这些设施共同构成了内核运行的最低硬件要求。

地址翻译与 satp 寄存器

satp（Supervisor Address Translation and Protection）寄存器是 S-mode 内存管理的核心。它包含 MODE（翻译模式）、ASID（地址空间标识符）和 PPN（页表根目录物理页号）三个字段。RISC-V 支持多种翻译模式，常见的有 Sv39（39 位虚拟地址，三级页表）和 Sv48（48 位虚拟地址，四级页表）。

翻译模式	虚拟地址宽度	页表级数	页大小	典型应用
Sv32	32 位	2 级	4KB	32 位嵌入式系统
Sv39	39 位	3 级	4KB / 2MB / 1GB	通用 64 位 Linux 内核
Sv48	48 位	4 级	4KB / 2MB / 1GB	大型服务器 / 数据库

内核通过修改 satp 寄存器切换地址空间。每次写 satp 后，TLB（Translation Lookaside Buffer）中的旧映射可能失效，需要通过 sfence.vma 指令刷新。ASID 字段允许不同进程的 TLB 条目共存，减少上下文切换时的 TLB 刷新开销。

中断控制与 PLIC

S-mode 的中断控制由 sie（Supervisor Interrupt Enable）和 sip（Supervisor Interrupt Pending）寄存器管理。sie 的 SSIE、STIE、SEIE 位分别控制软件中断、定时器中断和外部中断的使能。外部中断通过平台级中断控制器（PLIC）路由到 S-mode，PLIC 负责仲裁多个外设的中断优先级。

在典型的 RISC-V 系统中，M-mode 固件（如 OpenSBI）会将外部中断委托给 S-mode，使得内核可以直接处理 UART、网卡等设备中断，而无需陷入 M-mode。这种委托机制显著降低了中断延迟。

定时器与时钟中断

S-mode 的定时器中断基于 stimecmp 比较器（在 Sstc 扩展中）或通过 M-mode 的 mtime 寄存器间接实现。当 mtime 的值大于等于 stimecmp 时，产生定时器中断。Linux 内核利用该机制实现进程调度的时间片轮转。

经验提醒：在编写 S-mode 内核时，务必在 trap 入口的第一条指令处关闭中断（清 sstatus.SIE），防止在处理过程中被嵌套中断打断导致上下文损坏。同时，sret 指令会自动恢复 SIE 状态，因此无需手动重新开启中断。

案例拆解：基于 S-mode 的最小操作系统内核

为了更直观地理解 S-mode 的运行机制，我们设计一个最小化的操作系统内核实验。该内核运行在 QEMU 的 virt 机器上，使用 OpenSBI 作为 M-mode 固件，内核本身运行在 S-mode。

实验环境与约束：

QEMU 版本：7.2 以上，使用 qemu-system-riscv64 -machine virt
固件：OpenSBI（默认集成在 QEMU 中）
内核：自研最小内核，仅实现 UART 输出和定时器中断
目标：验证 S-mode 的 trap 入口、中断委托和 sret 返回流程

关键实现步骤：

链接脚本设置：将内核加载地址设为 0x80200000（OpenSBI 跳转地址）。
启动汇编：从 OpenSBI 进入 S-mode 后，设置栈指针、清零 BSS 段、跳转到 C 语言入口。
初始化 stvec：将 trap_entry 函数的地址写入 stvec，并设置为 Direct 模式。
配置定时器：通过 OpenSBI 提供的 SBI 调用（ecall 到 M-mode）设置定时器中断。
使能中断：设置 sie.STIE 和 sstatus.SIE，等待定时器中断触发。

初始现象与调试过程：

首次运行时，内核在 UART 输出 "Hello from S-mode" 后便不再响应。通过 GDB 调试发现，定时器中断触发后，程序跳转到了错误地址。检查 stvec 的值，发现写入的地址是虚拟地址而非物理地址。由于此时尚未开启分页（satp.MODE = Bare），虚拟地址等于物理地址，理论上不应出错。进一步检查发现，问题出在 trap_entry 中保存上下文的代码——我们使用了 sd sp, -8(sp) 将栈指针压栈，但此时 sp 尚未初始化为内核栈顶，导致数据写入到了未映射的内存区域。

解决方案：在 trap_entry 开头先加载内核栈指针到 sp，再进行上下文保存。修改后的代码片段如下：

trap_entry:
    # 加载内核栈指针（每个 CPU 一个独立栈）
    la sp, kernel_stack_top
    # 保存上下文
    addi sp, sp, -256
    sd ra, 0(sp)
    sd gp, 8(sp)
    sd tp, 16(sp)
    # ... 保存其他寄存器
    csrr t0, scause
    csrr t1, sepc
    # 分发处理
    call trap_handler
    # 恢复上下文
    ld ra, 0(sp)
    ld gp, 8(sp)
    ld tp, 16(sp)
    addi sp, sp, 256
    sret

结果对比：修复后，内核能够正确响应定时器中断，每次中断打印一次 "Timer tick"。通过该实验，我们验证了 S-mode trap 入口的完整流程，并理解了栈初始化在异常处理中的关键作用。

风险提示：在真实内核中，trap 入口的上下文保存必须考虑嵌套中断场景。如果允许嵌套中断，需要为每个中断级别保存独立的上下文区域，否则高优先级中断会覆盖低优先级中断的保存现场。Linux 内核通过 irqentry 和 irqexit 机制处理嵌套中断，初学者应避免在 trap 处理中过早开启中断。

常见误区与总结复盘

在学习 S-mode 特性时，开发者常陷入以下误区：

混淆 M-mode 与 S-mode 的 CSR：例如将 mstatus 与 sstatus 混用，导致特权级检查失败。S-mode 代码只能访问以 's' 开头的 CSR。
忽略 sret 的恢复语义：sret 不仅跳转到 sepc，还会将特权级恢复为 SPP 字段保存的值。如果 SPP 被错误设置为 M-mode，sret 会导致非法指令异常。
未处理 stval 的附加信息：对于页错误异常，stval 保存了触发异常的虚拟地址。如果内核不读取 stval，将无法实现按需分页。
中断委托配置遗漏：如果 M-mode 未将外部中断委托给 S-mode，内核将永远收不到设备中断，导致外设驱动无法工作。

总结复盘：S-mode 是 RISC-V 系统中软件复杂度最高的特权级。它通过 stvec 定义异常入口，通过 satp 管理地址空间，通过 sie/sip 控制中断，并通过 sret 完成返回。理解这些机制不仅有助于开发裸机内核，更是深入分析 Linux、RT-Thread 等操作系统在 RISC-V 上移植与运行的基础。建议读者在 QEMU 环境中动手实践本章的最小内核实验，通过修改 stvec、satp 和 sie 等寄存器观察系统行为变化，从而建立对监督态特性的直观认知。