VirtualBox是2类虚拟机管理程序，其中内核已完全虚拟化，在环1上运行，或者如果硬件支持可用，则它在环0 vmx非根模式下运行。了解到如果没有硬件虚拟化支持，则无法对客户操作系统进行64位全虚拟化，这立即就说明了原因，因为在当前进程或虚拟cpu状态等情况下，影子页表将没有空间。
对于没有硬件虚拟化支持（32位来宾）的完整虚拟化，想到的一个想法是虚拟机监控程序可以覆盖其内核空间中主机操作系统安装其IDT的虚拟地址上的PTE，以指向安装了虚拟机监控程序的IDT。 。可以看到这样做，因为来宾将仅使用底部的4GB。尽管Windows不允许将文件映射到内核空间中的基址，但必须有一种方法可以执行此操作。如果它可以将自己的IDT放在相同的内核虚拟地址上，则动态重新编译器/虚拟机监控程序过程中的任何异常都将由虚拟机监控程序IDT处理，并指向可以在客户机上模拟异常并填充虚拟机的虚拟机监控程序代码。 cr2，但是当它重新尝试出错的指令时，将再次发生页面错误，并且管理程序异常处理程序将识别来宾已经进行了映射（可能来自先前设置的且未清除的标志），因此它将在SPT中进行映射。当虚拟机管理程序拦截软件中断时，或者在模拟页面错误IDT访问并可能在虚拟机管理程序IDT的第一环描述符中插入中断以反映CPU上的更改时，虚拟机管理程序还需要使用来宾CPL模拟来宾的环0 。甚至不需要。当它遇到特权指令时，它有可能将其重新编译成软件中断，成为环0虚拟机监控程序描述符，该描述符将对虚拟硬件/程序物理寄存器执行操作。我不确定其他所有操作怎么做，而且似乎确实存在安全风险，因为系统管理程序可能会将任何旧代码粘贴在异常处理程序上或使描述符设为环0，并且它将立即在环0中运行，并允许进程执行修改其内核映射会导致此类硬件漏洞，因此我不确定如何与主机内核协商信任。
对于具有不带EPT的硬件支持的完全虚拟化，64位客户机占用了进程的整个虚拟地址空间，据我所知，这意味着SPT和虚拟硬件需要移至另一个虚拟机管理程序进程地址空间来宾进程使用的cr3是虚拟机管理程序进程的cr3。页面故障导致VM退出（在VMCS中配置）到虚拟机管理程序入口点（RIP）。在像VMware ESXi这样的类型1虚拟机管理程序中，这很好，因为虚拟机管理程序对此具有完全控制权，但是在Virtualbox方案中，虚拟机管理程序是主机OS上的用户空间进程，将允许其在vmx根模式环0下运行并指定RIP 。当然，这意味着如果恶意软件影响VirtualBox进程，它是否可以完全控制系统和主机OS内核内存？
无论如何，系统管理程序会在VMCS中看到它是页面错误代码，然后我猜测它模拟来宾的异常。不确定如何执行此操作，但可能会在来宾的虚拟TSS中指示的内核堆栈上写入陷阱帧（它可以作为虚拟机管理程序进程cr3与来宾进程cr3相同），并替换VMCS状态图中的RSP ，替换其他寄存器，用来宾的虚拟IDT中的RIP / CPL替换RIP / CPL，插入cr2，然后执行VM Resumes。 （Windows可以使用MiAddressToPte将cr2转换为PTE）。一旦处理完毕，它将重新尝试进行内存访问，然后由于未进行真正的映射而再次发生页面错误。这将导致VM退出，并且管理程序将必须使用先前设置的且未清除的标志来识别这种情况，并将更新SPT和VMRESUME。
如果支持EPT，则guest虚拟机将使用真实的cr3，并且由于它以vmx非根模式运行，因此无需系统管理程序干预即可访问。当出现页面错误时，guest虚拟机可以更新此映射，并且虚拟机监控程序无需干预，正常的页面错误不会导致VM退出。重新尝试访问时，EPT故障将导致VM退出，其EPTP等效于cr2，并为来宾指向虚拟机管理程序EPTP的指针。然后它将更新其映射和VMRESUME到故障指令的RIP。这样，VM退出将发生1次而不是3次。
有人可以在这里补充或纠正我的想法吗？