计算虚拟化1——CPU虚拟化

目录

vCPU的概念

vCPU和CPU的关系

CPU的Ring级别

CPU虚拟化技术

软件辅助全虚拟化

半虚拟化

硬件辅助虚拟化

---

计算资源的虚拟化可以分为CPU虚拟化、内存虚拟化、I/O虚拟化三个方面

CPU虚拟化：多个虚拟机共享CPU资源，对虚拟机中的敏感指令进行截获并模拟执行

内存虚拟化：多个虚拟机共享同一物理内存，需要相互隔离

I/O设备虚拟化：多个虚拟机共享一个物理设备

vCPU的概念

vCPU和CPU的关系

vCPU和物理CPU的关系

一个物理CPU有多个内核，每个内核可以有多个线程

如果物理CPU没有超线程技术

一个内核同时只能处理一个任务

即一个内核对应一个vCPU，将一个内核虚拟为一个vCPU，为虚拟机提供CPU资源

如果物理CPU有超线程技术

一个内核若有两个线程，就可以同时处理2个任务

即一个线程对应一个vCPU，将一个线程虚拟为一个vCPU，为虚拟机提供CPU资源

综上可知：多台虚拟机之间可以复用同一个物理CPU

vCPU的分配

虚拟CPU分配给虚拟机时，虚拟CPU的数量不能超过单台物理节点所能提供的vCPU数量

即：虚拟机分配的CPU总量不能超过单台物理节点所能提供的vCPU数量

分配规则

为虚拟机分配CPU初始值，该初始值应考虑该虚拟机在物理机运行所需的配置（在物理机运行需要多少cpu资源，虚拟机就分配多少cpu资源）

观察该虚拟机使用资源的均值和峰值（2个星期左右），然后再修改CPU的分配数量，得到资源利用最大化（修改后的CPU尽量保证虚拟机的均值控制在50~70%，峰值控制在50~90%之间）

CPU的Ring级别

CPU 指令分级

现代计算机的CPU技术有个核心的特点，就是根据指令的敏感程度分为不同的权限级别来实现运行的，避免了用户与应用程序层面的错误导致整个系统的崩溃

不同类型的CPU会有不同的权限级别，不过总体的思想是一致的，以下我们主要通过x86的CPU作为代表来讲解CPU的虚拟化

x86 物理CPU的权限分级

x86 CPU分为4个级别，分别为Ring0、Ring1、Ring2、Ring3

Ring0级别（内核态）

直接作用于操作系统内核，给系统核心命令使用的权限，调用系统资源，优先级最高；可以访问内存的所有数据

Ring1-2级别

主要运行的是设备驱动（操作系统服务）的命令

Ring3级别（用户态）

应用程序APP使用的权限，优先级最低；只能受限的访问内存，并且CPU资源可以被其他程序获取（Ring1-2也属于用户态）

我们重点关注的是Ring0（内核态）与Ring3（用户态）

每一层只能访问本层以及权限更底层的数据，当用户态直接执行Ring0权限的指令时，会被系统显示为非法指令，会报错，这种操作可能会导致系统出错

CPU的指令类型

特权指令

必须在Ring0权限级别上才能运行的指令，具有最高的权限级别

可以直接访问和控制计算机系统的硬件和核心资源，如内存、外设等

普通指令（非特权指令）

在CPU普通权限级别上就可以运行，即在Ring3、2级别上运行的指令，部分指令在Ring1

敏感指令

在Ring1上运行的指令，部分指令运行在Ring0

也可以直接访问和控制硬件和核心资源，但是其执行权限级别较低；通常由需要执行敏感操作的应用程序或服务使用，例如访问用户隐私数据、修改系统设置等

物理机操作系统中的用户态如何实现访问内核态呢

当APP需要执行访问磁盘、写文件等操作时，APP需要通过执行系统调用函数，在执行系统调用时CPU的运行级别就会从Ring3切换到Ring0，并跳转到系统调用对应的内核代码位置来进行相关操作，相关操作执行完成之后，从Ring0返回到Ring3，实现用户态与内核态的切换

---

CPU虚拟化技术

传统的CPU架构在虚拟化架构中存在的问题

当时在CPU的设计之初仅仅考虑了CPU的正常工作，并没有考虑虚拟化场景，因此当CPU运行在虚拟化场景下会存在问题，具体问题如下

1. 物理主机操作系统的一些操作底层硬件的指令运行在内核态Ring0，应用程序运行在Ring3
2. 在物理机上安装VMM对于物理机来说其实也是一个应用，因此VMM也运行在Ring3上
3. 在VMM上创建的虚拟机，也就属于Ring3；此时虚拟机上的应用等是在Ring3级别的，这个没有问题；但是虚拟机的操作系统也需要操作底层硬件，也需要运行在Ring0上，此时就存在问题（虚拟机操作底层硬件的指令本应该运行在Ring0上，实际处于Ring3）

所以传统CPU结构并不能满足虚拟机操作系统想要运行的环境，这也是最早虚拟化所面临的第一大难题 

虚拟化架构知识

为了解决以上问题，提出了软件辅助全虚拟化（全虚拟化）、半虚拟化、硬件辅助全虚拟化三种解决方法

不论是哪种虚拟化技术，关于虚拟机特权指令的操作都要交给VMM，由VMM交给底层硬件，不同的虚拟化技术只是说VMM交给底层硬件的方式不同

	软件辅助全虚拟化	半虚拟化	硬件虚拟化
实现技术	通过二进制转换、翻译实现	通过超级调用Hypercall实现	通过将特权指令转到Root模式实现
应用厂商	Vmware Workstation	Xen 不过Xen只支持对Linux的虚拟化 不支持对Windows的虚拟化 因为Windows不开源	Vmware ESXi/Hyper-v/KVM/Xen 3.0
性能	差	最好，几乎与物理主机性能相同	CPU需要在两种模式切换，带来额外开销 不过其性能正逐渐逼近半虚拟化
兼容性	最佳兼容性	需要修改操作系统，兼容性差	最佳兼容性

软件辅助全虚拟化

针对传统CPU在虚拟化场景存在的问题，最早由Vmware公司提出并解决

这个解决方法就为Binary Translation，中文名叫二进制转化

实现的原理

具体实现方式就是给VMM附加了一个功能，并且使得VMM运行在最高权限等级

由VMM来收集、辨识虚拟机的所有命令（包括Ring3、2、1、0）；对于虚拟机的Ring3的命令正常运行，VMM不拦截，对于Ring0的命令进行拦截，将拦截的命令进行翻译和替换，使之成为只能对虚拟机生效的虚拟特权指令，最终可以让虚拟机内核态的指令运行在Ring0的环境

提供两种工作机制（特权解除、陷入模拟）

特权解触（优先级压缩）

虚拟机执行Ring0指令时，将指令发到VMM时会触发VMM异常，这些异常就被VMM捕获，再由VMM将这些特权指令进行虚拟化成为只针对虚拟CPU起作用的虚拟特权指令

本质为使用能运行在物理机用户态中的非特权指令模拟出只对虚拟机有效的虚拟特权指令，实现特权指令的降级

存在的问题：有一部分特权指令会存在于Ring1权限中，而Ring1指令并不会触发VMM的异常捕获，从而导致在虚拟机中执行的特权指令直接对物理机造成了影响，可能导致系统出现故障

陷入模拟（二进制模拟—使用较多）

VMM会对虚拟机传来的指令的二进制代码进行扫描，一旦发现执行的是特权指令时，会将这些二进制代码翻译成虚拟特权指令的二进制代码或者是翻译成运行在核心态中的特权指令二进制代码从而强制的触发异常

这种方案就解决了虚拟机运行Ring1指令时没有被VMM捕获的问题

缺点

VMM有大量的工作负荷，也会占用大量的CPU和内存资源，实际使用效率较低，性能开销大

半虚拟化

实现的原理

通过对Guest OS的内核代码进行一定的修改，将原来在Host OS上执行的一些特权指令修改成可以和VMM直接交互的方式（即将虚拟机对特权指令的调用改为直接对VMM的调用---这种调用方式为Hypercall），由VMM直接将特权指令传递给物理机，这样就不会有捕获异常、翻译等过程，性能损耗比较少

缺点

需要给虚拟机操作系统打补丁，并且虚拟机系统的镜像文件并不通用，兼容性弱

此时虚拟机知道自己是运行在虚拟环境中，并不是运行在真正的物理主机上（主要是针对Linux实现半虚拟化）

硬件辅助虚拟化

通过此方式CPU有两个工作形态（Root态和非Root）

通过这种新的执行态，使得VMM和Guest OS被完全隔离

Root与非Root操作模式将原有的CPU操作区分为VMM所在的Root操作区和虚拟机所在的非Root操作区，每个操作区都拥有Ring0-3的所有指令级别

实现原理

硬件辅助虚拟化是使用了支持虚拟化功能的CPU进行支撑（Inter-TV和AMD-V技术就可以使得CPU支持虚拟化）

虚拟机运行在非Root态的核心态中，可以直接调用特权指令，不过其调用特权指令是通过硬件的虚拟化机制将特权指令调转到处在根模式下的VMM中，由VMM完成对硬件的统一管理

CPU厂商支持虚拟化的力度在不断加大，靠着硬件辅助的虚拟化技术性能逐渐逼近半虚拟化，再加上该虚拟化不需要修改客户端操作系统的优势，该虚拟方式是未来的发展趋势（目前很多的服务器/CPU 上面都可以开启硬件辅助虚拟化）

在使用时需要进入BIOS将CPU的硬件辅助虚拟化功能打开