linux-kernel - RISC-V 中的地址指定

Question

我正在 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 时(与上面的 ecall 一样)，satp MODE 是否更改为 0？如果是，这是否意味着应该在 u/s/mret 指令上重置 satp 模式？是否有其他情况(除了 csrrw)satp 应该改变？

如果没有，是否有其他机制可以解释地址并将其指定为物理地址？或者地址(上面的 0x80XXXXXX 地址)是否被认为是虚拟的，应该通过通常的虚拟地址转换过程(如 RISC-V 特权规范的第 4.3.2 节所述)？如果是这种情况，何时为此创建页表条目？

Answer 1

RISC-V 的内存模型的工作方式如下:
M 模式有自己的内存保护系统，在称为 PMP(物理内存保护)的特权规范第 3.6 节中进行了描述。这是为了对较低权限级别以及 M 模式本身(如果使用锁定位)施加内存保护。 M模式下没有虚拟内存系统。
现在在 S 模式中，它具有基于页面的虚拟内存系统，S 模式可以使用它来设置虚拟到物理地址的映射，并且还可以对 S 模式本身和 U 模式施加内存限制。
所以每个权限级别都可以控制自己的资源和它下面的资源，但永远不会控制它上面权限级别的资源。这就是事情的运作方式。
M模式可以控制M、S和U模式可访问的内存，S模式可以控制内存 View (虚拟内存)和S和U模式的可访问性，但不能控制M模式。所以当切换到 M 模式时，satp 模式甚至永远不会改变。由于它所指向的映射甚至永远不适用于 M 模式。它有它的内存保护单元。
如果较低的权限级别可以对较高的权限级别施加内存限制，这将是一个巨大的安全漏洞。