我正在 QEMU 中运行模拟的 RV64GC 内核，并试图更好地理解 RISC-V 中的虚拟内存子系统和地址转换过程。我的模拟系统使用 OpenSBI、Linux Kernal v5.5 和最小的 rootfs 运行。
在 QEMU 调试跟踪中，我发现有时（最常见的是 ecall）控制权会传递给 SBI，并且地址会从偏移量为 0xffffffe000000000 的内核（虚拟？）地址更改为 RAM 中看起来像真实物理地址的地址。例如，
...
0xffffffe00003a192：00000073 紧急呼叫
...
输入：sbi_ecall_0_1_handler
0x0000000080004844：00093603ld a2，0（s2）
0x0000000080004848：4785阿迪a5，零，1
0x000000008000484a：00a797b3 sll a5，a5，a0
...
在 RISC-V 特权规范版本 1.11 的第 4.1.12 节中，satp CSR（控制和状态寄存器）被定义为具有确定地址转换指定的 MODE 字段。 MODE 为 0 意味着转换是裸露的（地址被视为物理），MODE 为 8 或 9 分别需要 Sv39 或 Sv48 基于页面的虚拟寻址，并且保留任何其他 MODE 值。
现在，RISC-V 特权和非特权规范似乎都没有提及何时可以更改 satp（除了 csrrw），因此这让我产生以下问题：
当控制权交给 SBI 时（与上面的 ecall 一样），satp MODE 是否会更改为 0？如果是，这是否意味着应该在 u/s/mret 指令上重置 satp 模式？是否还有其他情况（除了 csrrw）需要更改 satp？
如果没有，是否有其他机制可以将地址解释并指定为物理地址？或者这些地址（上面的 0x80XXXXXX 地址）是否被视为虚拟地址，并且应该经历通常的虚拟地址转换过程（如 RISC-V 特权规范第 4.3.2 节所述）？如果是这种情况，什么时候为此创建页表条目？
RISC-V 的内存模型的工作原理如下：
M 模式有自己的内存保护系统，在特权规范第 3.6 节中描述，称为 PMP（物理内存保护）。这是为了对较低权限级别以及 M 模式本身施加内存保护（如果使用锁定位）。 M模式下没有虚拟内存系统。
现在在 S 模式下，它具有基于页面的虚拟内存系统，S 模式可以使用该系统来设置虚拟地址到物理地址的映射，并对 S 模式本身和 U 模式施加内存限制。
因此，每个权限级别都可以控制自己的资源以及低于其权限的资源，但不能控制高于其权限级别的资源。这就是事情的运作方式。
M 模式可以控制 M、S 和 U 模式可访问的内存，S 模式可以控制内存视图（虚拟内存）以及 S 和 U 模式的可访问性，但不能控制 M 模式。因此，当移动到 M 模式时，satp 模式甚至不会改变。因为它所指向的映射甚至永远不适用于 M 模式（除非设置了 mstatus.MPRV 位）。它有其内存保护单元。
如果较低的权限级别可以对较高的权限级别施加内存限制，这将是巨大的安全漏洞。