其实这个东西不是一两句话能说清楚的，
要回答这个问题，首先看为什么一个OS无法直接与另外的OS共存。答案很简单，OS作为硬件上第一层软件，认为自己拥有全部的硬件的访问和控制权，且自己是唯一的控制者。在这种情况下，如果两个OS共存，必然产生问题。
OS主要负责管理的是CPU和内存，以及众多的IO设备。于是我们可以分别讨论。hypervisor是实现虚拟化的关键，它会以一个内核态的驱动存在。
CPU的虚拟化：
背景知识：x86 CPU有一项权限机制，把CPU的状态置于RING 0到RING 3分别使CPU具有最高的权限到最低的权限。以Linux为例，内核运行于RING 0上，而其余全部用户进程运行于RING 3上（Xen比较奇葩，Linux在Xen下面会运行于RING 1）。在用户权限下，所有的IO设备是不可操作的，另外，有些控制寄存寄是无法访问的，一些privilege的指令是不能运行的。因此一个用户进程要想读写文件，进行一些操作，就要依赖于内核。系统调用能够使CPU运行于RING 0，并执行内核代码（具体方法见一些操作系统教程）。
背景说完。一个CPU的全部状态其实就是所有寄存器的值，只要保证任何操作之后寄存寄的值在OS看来是正确的，guest OS就可以正常执行。hypervisor会为每个虚拟的CPU创建一个数据结构，模拟CPU的全部寄存器的值，在适当的时候跟踪并修改这些值。
那么考虑虚拟化一个CPU，在虚拟化的guest OS里面，CPU无论如何也不可能运行于RING 0，因为这样的话，host OS必然会crash掉。因此，当一个guest OS想要进入到RING 0执行内核代码时，hypervisor会向guest OS说谎，并告诉它，你已经在RING 0上了，而实际上，所有的指令还是在RING 3上。当guest OS访问到任何privilege的东西时，hypervisor会接到fault，此时hypervisor会判断这个指令是什么，并修改相应的虚拟寄存器的状态，然后返回。这样guest OS就可以正常的运行。需要指出的是，在大多数的指令下代码是直接跑在硬件上的，而不需要软件介入。只有在一些权限高的请求下，软件会介入，并维护虚拟的CPU状态。
内存的虚拟化：
背景知识：虚拟内存，页表结构等。OS的基础内容，不表。
hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下，一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下，由于所谓的物理内存仍然是虚拟的，因此shadow page table就要做到：虚拟内存->虚拟的物理内存->真正的物理内存。
以下是细节，如果看着闹心，请忽略。hypervisor会维护一个从虚拟内存到物理内存的映射，当guest OS更换自己的page table，也就是改变CR3寄存器的值，hypervisor会因为用户态的权限不足而接到一个general exception，hypervisor会记录用户想要更换的新的页表，并放上一个空的shadow page table，然后返回。这个空的shadow page table会在接下来的执行中造成CPU无法进行地址翻译，而产生page fault。在fault发生后，hypervisor会得到一个虚拟地址，然后根据之前记录的用户的页表结构，翻译出一个虚拟机器地址，然后再把这个虚拟的机器地址，由hypervisor维护的映射翻译为实际的机器地址，然后装入shadow page table，并返回执行。如此，就实现了：虚拟内存->虚拟的物理内存->真正的物理内存。
I/O虚拟化：
背景知识：memory mapped I/O device。大多数的PCI设备都是直接将自己的某些控制寄存器映射到物理内存空间上，CPU访问这些控制寄存器的方法和访问内存相同。CPU通过修改和读取这些寄存器来操作I/O设备。
虚拟化的方法很简单，没当hypervisor接到page fault，并发现实际上虚拟的物理内存地址对应的是一个I/O设备，hypervisor就用软件模拟这个设备的工作情况，并返回。比如当CPU想要写磁盘时，hypervisor就把相应的东西写到一个host OS的文件上，这个文件实际上就模拟了虚拟的磁盘。
