深度探索Linux系统虚拟化：原理与实现
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

1.1.3　VMX

虽然大家从软件层面采用了多种方案来解决x86架构在虚拟化时遇到的问题，但是这些解决方案除了引入了额外的开销外，还给VMM的实现带来了巨大的复杂性。于是，Intel尝试从硬件层面解决这个问题。Intel并没有将那些非特权的敏感指令修改为特权指令，因为并不是所有的特权指令都需要拦截处理。举一个典型的例子，每当操作系统内核切换进程时，都会切换cr3寄存器，使其指向当前运行进程的页表。但是，当使用影子页表进行GVA到HPA的映射时，VMM模块需要捕获Guest每一次设置cr3寄存器的操作，使其指向影子页表。而当启用了硬件层面的EPT支持后，cr3寄存器不再需要指向影子页表，其仍然指向Guest的进程的页表。因此，VMM无须再捕捉Guest设置cr3寄存器的操作，也就是说，虽然写cr3寄存器是一个特权操作，但这个操作不需要陷入VMM。

Intel开发了VT技术以支持虚拟化，为CPU增加了Virtual-Machine Extensions，简称VMX。一旦启动了CPU的VMX支持，CPU将提供两种运行模式：VMX Root Mode和VMX non-Root Mode，每一种模式都支持ring 0～ring 3。VMM运行在VMX Root Mode，除了支持VMX外，VMX Root Mode和普通的模式并无本质区别。VM运行在VMX non-Root Mode，Guest无须再采用特权级压缩方式，Guest kernel可以直接运行在VMX non-Root Mode的ring 0中，如图1-1所示。

图1-1　VMX运行模式

处于VMX Root Mode的VMM可以通过执行CPU提供的虚拟化指令VMLaunch切换到VMX non-Root Mode，因为这个过程相当于进入Guest，所以通常也被称为VM entry。当Guest内部执行了敏感指令，比如某些I/O操作后，将触发CPU发生陷入的动作，从VMX non-Root Mode切换回VMX Root Mode，这个过程相当于退出VM，所以也称为VM exit。然后VMM将对Guest的操作进行模拟。相比于将Guest的内核也运行在用户模式（ring 1～ring 3）的方式，支持VMX的CPU有以下3点不同：

1）运行于Guest模式时，Guest用户空间的系统调用直接陷入Guest模式的内核空间，而不再是陷入Host模式的内核空间。

2）对于外部中断，因为需要由VMM控制系统的资源，所以处于Guest模式的CPU收到外部中断后，则触发CPU从Guest模式退出到Host模式，由Host内核处理外部中断。处理完中断后，再重新切入Guest模式。为了提高I/O效率，Intel支持外设透传模式，在这种模式下，Guest不必产生VM exit，“设备虚拟化”一章将讨论这种特殊方式。

3）不再是所有的特权指令都会导致处于Guest模式的CPU发生VM exit，仅当运行敏感指令时才会导致CPU从Guest模式陷入Host模式，因为有的特权指令并不需要由VMM介入处理。

如同一个CPU可以分时运行多个任务一样，每个任务有自己的上下文，由调度器在调度时切换上下文，从而实现同一个CPU同时运行多个任务。在虚拟化场景下，同一个物理CPU“一人分饰多角”，分时运行着Host及Guest，在不同模式间按需切换，因此，不同模式也需要保存自己的上下文。为此，VMX设计了一个保存上下文的数据结构：VMCS。每一个Guest都有一个VMCS实例，当物理CPU加载了不同的VMCS时，将运行不同的Guest如图1-2所示。

图1-2　多个Guest切换

VMCS中主要保存着两大类数据，一类是状态，包括Host的状态和Guest的状态，另外一类是控制Guest运行时的行为。其中：

1）Guest-state area，保存虚拟机状态的区域。当发生VM exit时，Guest的状态将保存在这个区域；当VM entry时，这些状态将被装载到CPU中。这些都是硬件层面的自动行为，无须VMM编码干预。

2）Host-state area，保存宿主机状态的区域。当发生VM entry时，CPU自动将宿主机状态保存到这个区域；当发生VM exit时，CPU自动从VMCS恢复宿主机状态到物理CPU。

3）VM-exit information fields。当虚拟机发生VM exit时，VMM需要知道导致VM exit的原因，然后才能“对症下药”，进行相应的模拟操作。为此，CPU会自动将Guest退出的原因保存在这个区域，供VMM使用。

4）VM-execution control fields。这个区域中的各种字段控制着虚拟机运行时的一些行为，比如设置Guest运行时访问cr3寄存器时是否触发VM exit；控制VM entry与VM exit时行为的VM-entry control fields和VM-exit control fields。此外还有很多不同功能的区域，我们不再一一列举，读者如有需要可以查阅Intel手册。

在创建VCPU时，KVM模块将为每个VCPU申请一个VMCS，每次CPU准备切入Guest模式时，将设置其VMCS指针指向即将切入的Guest对应的VMCS实例：

commit 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
[PATCH] kvm: userspace interface
linux.git/drivers/kvm/vmx.c
static struct kvm_vcpu *vmx_vcpu_load(struct kvm_vcpu *vcpu)
{
    u64 phys_addr = __pa(vcpu->vmcs);
    int cpu;
    cpu = get_cpu();
    …
    if (per_cpu(current_vmcs, cpu) != vcpu->vmcs) {
        …
        per_cpu(current_vmcs, cpu) = vcpu->vmcs;
        asm volatile (ASM_VMX_VMPTRLD_RAX "; setna %0"
                  : "=g"(error) : "a"(&phys_addr), "m"(phys_addr)
                  : "cc");
        …
    }
    …
}

并不是所有的状态都由CPU自动保存与恢复，我们还需要考虑效率。以cr2寄存器为例，大多数时候，从Guest退出Host到再次进入Guest期间，Host并不会改变cr2寄存器的值，而且写cr2的开销很大，如果每次VM entry时都更新一次cr2，除了浪费CPU的算力毫无意义。因此，将这些状态交给VMM，由软件自行控制更为合理。

上一章目录下一章