有人告诉我，从某种意义上说，VirtualBox之类的虚拟化程序不会像模拟器那样工作，因为它不会模拟寄存器，而是将实际的寄存器用于CPU上的虚拟数据。仿真器必须仿真寄存器，因为它们主要用于执行依赖于外部环境的软件（例如，Genesis仿真器需要Motorola 68000的寄存器和内存地址，因此开发人员必须将这些资源用作仿真寄存器）。
我的主要问题是，如何开发虚拟化？我们如何使整个操作系统作为虚拟机中的进程运行，而又在仍使用实际CPU的情况下使其独立运行？我只知道仿真，而不是虚拟化，所以如果有人可以帮助，那就太好了！
PS：我并不是在问差异是什么，而是在软件运行方式上存在差异。
Answers:
最初，您无法让来宾OS使用真正的硬件，因为您无法控制它。如果尝试在实际CPU上运行它，则无法保证它将控制权交还给主机OS。
您所描述的虚拟化是通过允许在硬件级别应用某些规则和限制在硬件中实现的，这些规则和限制可以由主机OS管理。这允许主机OS设置关于来宾可以做什么和不能做什么的规则，然后在实际硬件上实际运行来宾。如果guest虚拟机尝试使用违反规则的真实硬件做某事（例如尝试访问磁盘设备），则硬件将挂起guest虚拟机并向主机发送中断，从而允许主机提供响应（例如从模拟磁盘设备返回数据），然后恢复来宾。
这是该过程的简化示例：
主机操作系统：嗨，CPU，我需要您虚拟运行此代码。如果它想做的不只是执行指令，请给我打电话。
主机CPU：知道了！
主机CPU保存所有主机寄存器和状态，然后开始执行Guest OS代码来宾操作系统：我还活着！嗨，CPU，您能给我这个文件吗？
主机CPU：嗯。一会儿
主机CPU保存所有来宾寄存器和状态，然后还原所有主机寄存器和状态
主机CPU：嗨，主机操作系统，来宾需要此文件！主机操作系统：哦，给他们这个：虚拟硬盘中的文件
主机CPU：知道了！
主机CPU保存所有主机寄存器和状态，还原来宾寄存器和状态，然后开始执行来宾OS代码
主机CPU：这是该文件！来宾操作系统：好的，谢谢！
这里的主要区别在于仿真器，来宾OS从未在硬件上实际运行。通过虚拟化，主机OS会在CPU中配置限制，然后在物理CPU上实际运行来宾代码。上面的示例已大大简化，但是可以在当今最新的处理器上控制内存，磁盘I / O甚至网络，从而可以安全地连接它们，而不必每次都打扰主机OS。只要来宾不尝试走出虚拟化边界，如果主机OS在给定的时间点无事可做，则主机OS可能不会运行任何代码。
稍微增加一点，这只是虚拟化和控制的悠久历史中的又一步。（不保证此顺序正确或详尽无遗，但应提供良好的入门概述）
最初，没有虚拟化。进程共享相同的内存空间，所有进程都拥有对硬件的完全访问权限，并且多任务处理能力完全取决于一个进程自行停止并控制下一个进程。如果OS希望对进程进行任何控制，则必须在模拟器中运行该进程（没有人这样做，因为它太慢了，太痛苦了）。
首先是特权内存：某些只能由特殊内存区域执行的操作。这些区域被OS占用，从而使其可以充当这些特权操作的网关。一个例子就是能够将数据读/写到硬件。这样可以防止进程直接将数据读/写到硬盘驱动器，而迫使它们要求操作系统为它们读/写。这意味着操作系统可以在执行操作之前检查进程是否具有权限。
接下来是虚拟化的“时间”。操作系统可以将CPU配置为按设置的时间间隔中断活动进程，从而使其可以控制调度并在进程之间进行切换。操作系统现在可以直接在硬件上运行进程，并且仍然可以防止它们滥用CPU时间。这是由硬件计时器提供的。
接下来是虚拟化内存：共享内存的问题是任何进程都可以读取任何其他进程的内存。当Mary的程序从网络浏览器中读取Bob的密码时，会发生什么情况？虚拟内存允许操作系统将进程看到的内存映射到物理内存的不同部分，甚至将它们完全移出物理内存（移至页面文件）。每当进程尝试读取或写入内存时，CPU的VMMU（虚拟内存管理单元）都会在物理内存中查找映射到的位置并执行操作。如果映射到内存不足，则CPU调用OS，以将页面从页面文件中提取到内存中。
好了，至此，我们已经到达了X86处理器的起点，在这里我们可以安全地运行进程，并可以积极地阻止它们接管系统，除非OS明确允许它们这样做。在这一点上，过程被有效地“虚拟化”了。这种支持已经存在了很长时间，因此您不会真正听到有人在谈论虚拟化流程，因为它只是假设现在所有流程都已虚拟化。
但是，为什么虚拟化操作系统有特殊之处？为什么我们不能仅将其作为一个过程启动并让它自己做呢？嗯，问题在于，作为操作系统，来宾系统希望能够访问和使用主机用来控制进程的相同控件-基本上，操作系统希望成为计算机的最高统治者，而他们根本不会这样做。如果不是这样，那就行不通。“硬件虚拟化”扩展（AMD的AMD-V和英特尔的VT-x）允许主机操作系统提供一组虚拟化的虚拟过程控件（虚拟特权内存，虚拟硬件计时器，虚拟虚拟内存）。
我们如何使整个操作系统作为虚拟机中的进程运行，而又在仍使用实际CPU的情况下使其独立运行？
（以下内容简化了很多。）
通过利用操作系统使用的相同或相似的机制来使用户模式进程保持一致。
用户模式进程在尝试执行不允许执行的操作时将导致CPU异常。
因此，如果我们有一个在用户模式下运行的OS内核，则每当它尝试直接执行诸如访问硬件之类的操作时，都会导致异常。系统管理程序可以处理该异常并以模拟或虚拟化的行为进行响应，而不会像正常内核那样导致系统崩溃。
它可以代表该内核执行硬件访问，执行修改后的硬件访问（即，访问文件的一部分而不是直接磁盘扇区访问），或者您可能梦dream以求的其他任何事情。
CPU虚拟机扩展从根本上将CPU的整个“管理程序”或“受保护”模式扩展了一个级别来完成此操作，还提供了虚拟内存的附加“嵌套级别”，因此分页更易于虚拟化。
虚拟化涉及模拟计算机硬件的各个部分（足以使来宾操作系统未经修改地运行），但是出于效率方面的考虑，大多数操作仍在实际硬件上进行。因此，虚拟化通常比仿真快，但是实际系统必须具有与来宾系统相同的体系结构。例如，VMWare可以提供一个虚拟环境，用于在真正的“内部”运行虚拟Windows XP计算机。但是，VMWare不能在真正的x86 PC之外的任何实际硬件上运行。
在仿真中，虚拟机在软件中仿真完整的硬件。这允许用于一种计算机体系结构的操作系统在为其编写模拟器的体系结构上运行。正因为如此，所有操作都在软件中运行，因此仿真往往会变慢，但由于它与硬件无关，因此可以支持更多平台。
为了完整起见，还进行了仿真，其中重复了机器的动作，但是使用的是内部结构可能与“实际”机器完全不同的代码。（想想“飞行模拟器”。）模拟器通常会编译“真实”机器的源代码，但目标是完全不同的CPU体系结构，具有完全不同的OS和I / O设施。