我正在QEMU中运行一个模拟的RV64GC内核，并试图更好地了解RISC-V中的虚拟内存子系统和地址转换过程。我的模拟系统在OpenSBI，Linux Kernal v5.5和最小的rootfs上运行。
在QEMU调试跟踪中，我看到有时（最常见于ecalls）控制权传递给SBI，并且地址从内核（虚拟？）地址更改为偏移量0xffffffe000000000，看起来像真实的，物理的地址在RAM中。例如，
...
0xffffffe00003a192：00000073 ecall
...
IN：sbi_ecall_0_1_handler
0x0000000080004844：00093603 ld a2,0（s2）
0x0000000080004848：4785 addi a5，zero，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时（如上述调用一样），satp MODE是否变为0？如果是，这是否意味着应在u / s / mret指令中重置satp模式？是否有其他实例（除了csrrw之外）的satp会发生变化？
如果没有，是否还有其他机制可以通过这些机制来解释地址并将其指定为物理地址？还是地址（上面的0x80XXXXXX地址）被认为是虚拟的，应该经过通常的虚拟地址转换过程（如RISC-V特权规范的4.3.2节所述）？如果是这样，什么时候为此创建页表条目？
答案 0 :(得分：2)
RISC-V的内存模型按以下方式工作：
M模式具有自己的内存保护系统，在特权规范的第3.6节中对此进行了描述，称为PMP（物理内存保护）。这是为了在较低特权级别上以及M模式本身（如果使用了锁定位）上施加了内存保护。 M模式下没有虚拟内存系统。
现在在S模式下，它具有基于页面的虚拟内存系统，S模式可用于设置虚拟到物理地址的映射，并对S模式本身以及U模式施加内存限制。
因此，每个特权级别都可以控制自己的资源和其下的资源，而不能控制其上级特权的资源。这就是工作原理。
M模式可以控制可通过M，S和U模式访问的内存，而S模式可以控制内存视图（虚拟内存）以及S和U模式而非M模式的可访问性。因此，进入M模式时，satp模式甚至不会改变。正如它所指出的那样，映射甚至都不适用于M模式。它具有内存保护单元。
如果较低的特权级别可以对较高的特权级别施加内存限制，则这将是一个巨大的安全漏洞。