Virtual machine 卷影页表（用于VMM）的具体功能是什么？

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

即

而不是：

来宾操作系统->VMM+虚拟物理内存->主机操作系统->主机硬件

只是：

来宾操作系统->VMM->主机操作系统->主机硬件

---

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

虚拟机监控程序使用卷影页面表来跟踪来宾“认为”其页面表应处于的状态。不能允许来宾访问硬件页表，因为这样它就基本上可以控制机器。因此，当相关客户机正在执行时，虚拟机监控程序在硬件中保留“真实”映射（客户机虚拟->主机物理），并保留客户机认为它正在“在阴影中”使用的页面表的表示，或者至少我喜欢这样想

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

就页面错误而言，从硬件的角度来看，没有任何变化（记住，虚拟机监控程序使硬件使用的页面表包含GVA->HPA映射），页面错误只会生成异常并重定向到相应的异常处理程序。但是，当VM运行时出现页面错误时，可以将此异常“转发”到虚拟机监控程序，然后虚拟机监控程序可以适当地处理它

当虚拟机监控程序看到客户机生成的页面错误时，它必须构建这些影子页面表。当来宾将映射写入其一个页面表时，虚拟机监控程序不会立即知道，因此影子页面表不会立即与来宾想要的内容“同步”。因此，虚拟机监控程序将以以下方式构建影子页面表：

• Guest将VA

  0xdeadbeef

  的映射写入其页表（内存中的一个位置），但请记住，硬件不使用此映射
• 来宾访问

  0xdeadbeef

  ，这会导致页面错误，因为实际页面表尚未更新以添加映射
• 页面错误被转发到虚拟机监控程序
• Hypervisor查看来宾页面表并注意到它们与影子页面表不同，说“嘿，我还没有为

  0xdeadbeef

  创建真正的映射”
• 因此，它更新其影子页表，并为要使用的硬件创建相应的

  0xdeadbeef

  ->HPA映射

前一种情况称为影子页面错误，因为它完全是由内存虚拟化的引入引起的。因此，页面错误的处理将在hypervisor停止，来宾操作系统甚至不知道它是否发生过。请注意，来宾还可以生成真正的页面错误，因为它尚未尝试创建映射，虚拟机监控程序会将这些错误转发到来宾中。还要认识到，这整个过程意味着来宾执行时发生的每个页面错误都必须导致VMM退出，这样影子页面表才能保持新鲜。这是昂贵的，也是为内存虚拟化引入硬件支持的原因之一。（是对嵌套或扩展页表的快速介绍）

这方面的一个很好的参考是

当来宾将映射写入其一个页面表时，虚拟机监控程序不会立即知道，因此影子页面表不会立即与来宾想要的内容“同步”

不完全是这样。来宾页面表是只读的。每当来宾页面表中有更新（例如，添加了新的映射）时，它就会捕获到虚拟机监控程序，虚拟机监控程序相应地更新影子页面表以与来宾“同步”

参考资料：

---

我直到现在才意识到，

0xdeadbeef

是我操作系统类之外的东西。回答得好。虚拟机监控程序如何获取来宾页面表进行同步？@firo当来宾加载cr3寄存器时，它可能会捕获到虚拟机监控程序，然后它可以知道来宾页面表的内容。虚拟机监控程序如何知道更改的是来宾页面表？@firo这也是我想知道的。由于写入页表只是一条简单的mov指令，虚拟机监控程序如何知道要加载到页表中的内容（或者这是由英特尔CPU支持通过简单记录错误mov指令的内容和地址来完成的。）虚拟机监控程序将各页标记为只读。将来的任何写入都会导致页面保护错误，这将捕获到虚拟机监控程序。然后，虚拟机监控程序可以更新卷影页表。