virtual-machine - 影子页表(用于 VMM)究竟是做什么的？

Question

我的理解是影子页表消除了在虚拟机内部模拟物理内存的需要。

IE。

代替:

guest OS -> VMM + virtual physical memory -> host OS -> host hardware

只是:

guest OS -> VMM -> host OS -> host hardware

影子页表只允许进程正确访问主机硬件的内存。我也不明白页面错误是如何工作的(或者因为所有物理内存都由主机处理，所以主机会处理页面错误、交换等)。

Answer 1

虚拟机管理程序使用影子页表来跟踪 guest “认为”其页表应该处于的状态。不能允许 guest 访问硬件页表，因为这样它就可以控制机器。因此，当相关 guest 正在执行时，管理程序将“真实”映射( guest 虚拟 -> 主机物理)保留在硬件中，并保留 guest 认为它“在阴影中”或在至少我是这么想的。

请注意，这避免了 GVA->GPA 转换步骤。

就页面错误而言，从硬件的角度来看没有任何变化(请记住，管理程序使硬件使用的页表包含 GVA->HPA 映射)，页面错误将简单地生成异常并重定向到适当的异常处理程序。但是，当虚拟机运行时发生页面错误时，可以将此异常“转发”到管理程序，然后管理程序可以适本地处理它。

管理程序必须建立这些影子页表，因为它看到 guest 生成的页面错误。当客户将映射写入其页表之一时，管理程序不会立即知道，因此影子页表不会立即与客户的意图“同步”。因此管理程序将建立影子页表，例如，以下方式:

guest 为 VA 0xdeadbeef 写入映射进入它的页表(内存中的一个位置)，但请记住，这个映射没有被硬件使用。

访客访问 0xdeadbeef ，这会导致页面错误，因为尚未更新实际页表以添加映射

页面错误被转发到管理程序

管理程序查看客户页表并注意到它们与影子页表不同，说“嘿，我还没有为 0xdeadbeef 创建真正的映射”

所以它更新它的影子页表并创建一个对应的0xdeadbeef -> 要使用的硬件的 HPA 映射。

前一种情况被称为影子页面错误，因为它完全是由内存虚拟化的引入引起的。因此页面错误的处理将在管理程序处停止，客户操作系统甚至不知道它发生了。请注意，客户也可能由于尚未尝试创建的映射而生成真正的页面错误，并且虚拟机管理程序会将这些重新转发给客户。还要意识到，这整个过程意味着客户机执行时发生的每个页面错误都必须导致 VMM 退出，以便可以保持影子页表的最新状态。这是昂贵的，也是为内存虚拟化引入硬件支持的原因之一。 ( here 是对嵌套或扩展页表的快速介绍)

一个很好的引用是 this book