虚拟机管理程序来宾操作系统中的内存地址转换

Question

假设有这样的代码。

MOV [0x1234], EAX (intel assembly)

假设 CPU 想要处理这条指令。 让我们假设没有管理程序。 我们只是在linux环境中使用普通的x86 CPU（保护模式）。

现在，我的理解是 因为 0x1234 是虚拟地址，所以需要翻译 到物理地址。（让我们跳过分段部分）

CPU 只是将此地址（0x1234）传递给 MMU 硬件。 MMU 遍历页表并使用物理地址访问内存内容。

我说的对吗？

现在让我们假设有管理程序和这段代码 正在从来宾操作系统运行。

到底发生了什么？？

我知道管理程序提供了另一层页表。 但我不明白这是如何工作的。

如果客户代码“MOV [0x1234], EAX”被执行 在真正的 CPU 中。虚拟地址 0x1234 将由 真正的硬件 MMU。所以我认为这个指令必须是 重写（0x1234 应替换为另一个地址 在代码执行之前），或者被困在管理程序中......

我错了吗？ 如果我错了，请纠正我的理解...

提前谢谢你。

Answer 1

回答您的第一个问题：是的，您是。这基本上就是虚拟内存的工作原理。

现在，让我们看看当管理程序在 MMU 和来宾操作系统之间运行时会发生什么。出于性能考虑，管理程序（无论是 type 1 还是 type 2）会尽量避免在每次来宾操作系统内存访问时陷入陷阱。这个想法是让来宾操作系统管理 MMU。我将详细说明可能的实现，一种用于 x86，一种用于 PowerPC。

在 x86 上，来自Intel's manual 3B：

27.3.2 访客和主机物理地址空间

内存虚拟化为客户软件提供了连续的客户物理 地址空间从零开始并扩展到支持的最大地址 来宾虚拟处理器的物理地址宽度。 VMM 利用来宾物理 主机物理地址映射以定位来宾物理的全部或部分 主机内存中的地址空间。 VMM 负责策略和算法 对于这种映射，它可能会考虑到主机系统的物理 内存映射和虚拟化物理内存映射暴露给来宾 VMM。

VMM 知道 VM 的当前 PDBR 基地址（PDBR 保存在 CR3 寄存器中），因为对 CR3 的访问将导致 VM_EXIT。 VMM 将能够代表来宾操作系统维护真实页面目录。我的意思是，当客户操作系统修改其页面目录以将逻辑地址 A 映射到物理地址 B 时，VMM 会捕获此问题，而不是将 A 映射到 B，而是将 A 映射到 C。因此，对 A 的任何进一步访问都不会导致#PF，它将通过 MMU 完美地路由到 C。这种方法的可悲之处在于客户机认为它已将 A 映射到 B，但实际上 A 已映射到 C，因此 VMM 必须维护一个虚拟页面目录，以防客户机读取它先前映射 A 的位置。 VMM 捕获此读取访问，而不是说 A 映射到 B，它返回给客户机 A 映射到 C。

27.3.3 通过蛮力虚拟化虚拟内存

一种简单的方法是确保所有访客尝试访问 到 VMM 的地址转换硬件陷阱，此类操作可以正确执行 效仿。它必须确保对页目录和页表的访问也得到 被困。这可以通过使用常规保护这些内存结构来完成 基于页面的保护。 VMM 可以这样做，因为它可以定位页面 目录，因为它的基地址在 CR3 中，并且 VMM 接收对任何 更改为 CR3；它可以定位页表，因为它们的基地址在 页面目录。

在 PowerPC 上，您没有英特尔的页面目录的硬件表遍历。 TLB 的每次修改都是由一条指令引起的，通常来自内核内存管理器。同样，一个简单的想法是捕获每个访客对 TLB 的访问（例如，当访客执行 tlbwe 指令时设置导致 VM 退出；注意：tlbwe 将条目写入 TLB）。一旦进入 VMM，管理程序就会对捕获指令进行解码，并模拟其行为，但它不是将 A 映射到 B，而是将 A 映射到 C，直接进入 TLB。同样，VMM 必须维护一个虚拟 TLB，以防客户操作系统想要检查 TLB 中的内容，并返回它认为之前放入 TLB 中的内容。

总而言之，尽管一些硬件功能有助于虚拟化客户机物理内存，通常由 VMM 来管理有效的客户机-物理到主机-物理内存映射。