虚拟化浅解

1、虚拟化的两种模型

Type-I：不需要在硬件安装操作系统，让虚拟化软件直接运行在硬件上面，直接的管理硬件资源，虚拟机全部运行在硬件上面。

Type-II：需要在硬件上先安装操作系统（OS），在操作系统上面安装一个虚拟化软件，在虚拟化软件上面创建虚拟机。

2、简介

我们常见的虚拟化软件有VMWare workstation(VMWare)、VirtualBox(Oracle)、Hyper-V(Microsoft)、KVM(Redhat)、Xen等，这些软件统称为VMM(Virtual Machine Monitor)，它们使用不同的虚拟化来实现。而这些虚拟化实现的方式可以分为全虚拟化、半虚拟化、硬件辅助虚拟化等，本篇主要是理解这些虚拟化的实现原理。

3、x86 CPU架构与虚拟化的关系

在说虚拟化之前，我们先看看一般x86 CPU的架构

注意：CPU为了保证代码执行的安全性、多用户的独立性、保护OS的正常运行，实现了CPU执行状态的概念。这样能够限制不同程序之间的访问能力，避免一个程序获取另一个程序的内存数据，同时也避免了程序错误操作物理硬件。一般CPU都会划分为用户态和内核态，x86细分了Ring3~0四种状态。

Ring 3（用户态）：运行在用户态的代码需要被CPU检查，这些代码只能访问内存页表项中规定能被用户态访问的页面的虚拟地址(受限的访问内存)，而且只能访问TSS中的I/O Permission Bitmap中规定能被用户态访问的端口。甚至不能访问外围设备、不能抢占CPU。所有的用户程序(Application)都运行在用户态。当运行在用户态的应用程序需要调用硬件设备时，CPU会通过特别的接口去调用核心态的代码，之后用户态的应用程序才能对硬件设备进行操作。 如果用户态的应用程序直接调用硬件设备时，就会被Host OS捕捉到并触发异常。

Ring 1–Ring 2 保留着，没有被使用

Ring 0（内核态）：是Host OS Kernel运行的模式，运行在核心态的代码可以无限制的对系统内存、设备驱动程序、网卡接口、显卡接口等外围设备进行访问。只有Host OS能够无限制的访问硬盘、键盘等外围硬件设备的数据(但需要驱动程序)。

(1) 所有OS设计时都认为Kernel是可以控制所有硬件,并可运行CPU的特权指令,即Kernel运行于CPU的Ring0上。
(2) 多个OS无法同时直接运行于硬件层之上,它们必须运行在Hypervisor层(下文称:Host)上；就如同不安装操作系统就不能安装VMware,没有VMware就无法让虚拟机(下文称:Guest)运行起来一样。那问题来了,若GuestOS必须
运行在CPU的Ring0上,Host运行在哪里？
(3) OS设计时它认为自己是可以控制所有硬件资源的,那GuestOS之间不就可以相互影响了吗？Guest1要关机，如果它直接执行CPU的特权指令关机,那它应该就可以关闭整个物理机器,这就乱套了，这不是虚拟化所希的。
(4) 这就给CPU虚拟化带来了诸多问题, 但实际上Host一定是真正能执行CPU的特权指令的,Guest运行起来后,它实际控制的CPU是通过软件模拟的CPU,实际上任何物理硬件都是通过集成电路进行运算,通过微代码向外提供输出结果的接口,只有通过软件模拟出这些接口就可以模拟硬件.
(5) CPU的虚拟化
》模拟CPU：完整虚拟,即模拟出CPU的Ring 0,Ring 1,Ring 2,Ring 3；这通常在底层硬件与虚拟环境的硬件不同时采用模拟CPU的方式。
》虚拟CPU：仅模拟CPU的Ring 0, Guest的用户空间中的APP可直接运行在物理CPU的Ring 3上,仅Ring 0上的特权指令进行翻译.这是Guest的硬件环境与底层硬件环境一致时用。

总的来说，GuestOS和VMM都属于运行在Ring3上的应用程序，GuestOS操作硬件设备时会先将操作指令传递给VMM，VMM对该指令进行监控和检测后将指令传递给HostOS，HostOS会将GuestOS发出的运行于用户态的指令模拟为核心态指令，最后交由CPU处理。

4、半虚拟化 Para virtualization

半虚拟化是需要GuestOS协助的虚拟化。因为在半虚拟化中运行GuestOS内核都进行过了特别的修改 (即需要修改内核)。半虚拟化VMM在处理敏感指令和内核态指令的流程上相对更简单一些。在半虚拟化VMM上运行的GuestOS都需要修改内核，主要是修改GuestOS内核指令集中包括敏感指令在内的内核态指令。让HostOS在接收到没有经过半虚拟化VMM模拟和翻译处理的GuestOS内核态指令或敏感指令时，HostOS也能够准确的判断出该指令是否是属于GuestOS(即虚拟机自己知道自己是虚拟机)。这样就可以高校的避免了上述问题。但是只可以安装开源的操作系统，因为闭源的操作系统没有开放代码无法对内核进行修改。典型的半虚拟化软件有——Xen、KVM-PowerPC(简易指令集)

5、全虚拟化 Full virtualization

GuestOS可以直接在全虚拟化VMM上运行而不需要对其本身做任何修改，全虚拟化的GuestOS具有完全的物理机特性。既VMM会为GuestOS模拟出它所需要的包括CPU、磁盘、内存、网卡、显卡等所有的抽象资源。GuestOS在使用网卡时，会调用VMM模拟的虚拟网卡驱动来操作物理网卡。
GuestOS是一个虚拟机，在我们使用GuestOS的时候，不可避免的会使用到GuestOS中的虚拟设备驱动程序和核心调度程序来操作硬件设备。与HostOS的不同在于，HostOS是运行在CPU的核心态中，这就表示了HostOS是可以直接操作硬件设备的。但GuestOS是运行在CPU用户态中，所以其不能直接操作硬件设备。为了解决这个问题，VMM引用了两个机制——特权解除和陷入模拟。
特权解除：即翻译，当GuestOS需要使用运行在核心态的指令时，VMM就会动态的将该指令捕获并调用若干的运行在非核心态的指令来模拟该核心态指令的效果，从而将核心态的特权解除。解除了核心态的特权后，GuestOS中的大部分指令都可以正常的执行。但是，这仍然不能完美的解决问题。因为在一个OS的指令集中还存在着一种敏感指令(可能是内核态，也可能是用户态)。此时就需要陷入模拟的实现。
陷入模拟：HostOS和GuestOS都含有敏感指令(reboot、shutdown等)，试想如果在GuestOS中执行了reboot指令，却将HostOS重启了，这将会非常糟糕。VMM的陷入模拟机制就是为了解决这个问题。在GuestOS中执行了需要运行在内核态中的reboot指令，VMM首先会将reboot指令获取、检测并判定为敏感指令。此时VMM就会陷入模拟，将敏感指令reboot模拟成一个只对GuestOS进行操作的、非敏感的、并且运行在非核心态的”reboot”指令，并将其交给CPU处理。最后由CPU准确的执行GuestOS重启的动作。
由于全虚拟化会将非内核态指令模拟成内核态指令再交由CPU处理，经过了两重转换，所以其效率会比半虚拟化更低，但全虚拟化的好处在于其不会对GuestOS做修改，所以全虚拟化的VMM可以安装绝大部分的OS(暂时来说只有已Linux、open soralis、BSD等几种OS开源了内核代码)。典型的全虚拟化软件有 —— VMWare、Hyper-V、KVM-x86(复杂指令集)。

6、硬件辅助虚拟化 HVM

2005年 Intel提出并开发了由CPU直接支持的虚拟化技术。这种虚拟化技术引入新的CPU运行模式和新的指令集，使得VMM和GuestOS运行于不同的模式下(VMM=Root Mode;GuestOS=Non-Root Mode)，GuestOS运行于受控模式，原来的一些敏感指令在受控模式下会全部陷入VMM，由VMM来实现模拟，这样就解决了部分非内核态敏感指令的陷入——模拟难题，而且模式切换时上下文的保存恢复由硬件来完成，这样就大大提高了陷入——模拟时上下文切换的效率 。该技术的引入使x86 CPU可以很容易地实现完全虚拟化。故皆被几乎所有之前分歧的各大流派所采用，包括KVM-x86，VMWare ESX Server 3，Xen 3.0 。

所谓硬件虚拟化就是让CPU具有5个环，分别是：Ring3，Ring2，Ring1，Ring0，Ring-1。
所以，我们称之为Ring-1位虚拟化的根环（区域），这就意味着HOST主机内核运行在Ring-1上的（因为此时的它是特权指令环），各个Guest主机运行在Ring0上，此时Ring0虽然存在，但并没有特权指令的，只是一个空壳而已。虚拟机的用户空间一人是运行在Ring3上的。由于虚拟机内核运行在Ring0上，它会认为自己就拥有了特权指令，但是当他调用特权指令的时候，HostOS内核是可以捕获到各个Guest对于特权指令的调用，最后由CPU硬件自己转换成（需要HostOS内核的参与）-1环中的特权指令。这就叫硬件辅助的虚拟机，简称HVM。
HVM的分类：
1). Intel –> VT-X
2). AMD –> AMD-V