[V-01]虚拟化概论-Hypervisor(VMM)(基于AArch64)

前言

虚拟化思想篇的介绍使我们大致了解了VMM诞生的过程，对于这个Monitor更通俗的说法叫Hypervisor(超级监管者)。本篇会介绍Hypervisor概念、特性、分类、作用。我们已经了解到VMM大致分为Emulation和Virtualization两个方向，Emulation虽然很重要，但不是我们讨论的重点。我们主要是介绍Virtualization这个方向，基于ARM的官方经典的入门文档展开。

1. Hypervisor

1.1 What is hypervisor(概念)

从理论上，我们已经知道虚拟化的核心思想就是从时间和空间上分割物理硬件平台给上层应用使用，ARM的文档中这样描述hypervisor：

We use the term hypervisor in this guide to mean a piece of software that is responsible for creating, managing, and scheduling of Virtual Machines (VMs).

首先Hypervisor是系统中的“a piece of software”，这段代码是负责创建、管理、调度虚拟机的(VMs)。“一段软件代码”的这个表述就是揭露了hypervisor的本质: Hypervisor这个超级监管者也是码霸（码农中的霸主）一行一行coding出来的。如图1-1，就是Type-1 Hypervisor的代表KVM的框架代码。

光有核心框架代码是不够的，还需要体系的代码配合Hypervisor核心框架才能让Hypervisor完成工作，如图1-2所示。

在linux上，就是这些核心框架代码和体系相关的代码组成了Hypervisor，注意他只是虚拟化管理者是leader，光有leader是不行的还得有被管理者啊，那就是VM和GuestOS。和这个世界上的所有leader一样，Hypervisor就是嘴上说的都是它是为VM和GuestOS服务的。VM就是虚拟的机器环境，有内存、CPU、完整的外设，并且这些资源都是可以配置的。GuestOS就比较好理解，前面废了半天劲，就是要让它run起来干活。那么Hypervisor在这个过程中，扮演的角色有两重身份：第一个是建立沟通的管道，让VM和GuestOS能够低成本（尽量少的时钟周期）的沟通；第二重身份，就是管理者，就是VM和GuestOS都不能做出格的事儿，比如GuestOS调用一个Power接口通知系统下电，这就是不被允许的。

这里的KVM源码我们能看到，还要感谢开源社区那些大牛，不是每个Hypervisor的源码都配让大家看的。做过8155和8285的同学都知道高通的基于QNX虚拟化方案，连高通的人都不配看的。
另外，Linux完整的虚拟化代码除了上面描述的框架代码、体系代码外，还有VirtIO相关的代码，因为Linux很多子系统已经实现了Para-Virtualization架构，这个后面会慢慢讲到。

从上面代码的组织形式看，Hypervisor似乎是另外一个系统的一个组件，Linux启动之后，Hypervisor才能够工作，确实如此，但不总是这样。这“a piece of software”还有另外一种组织形式，如图1-3所示。

这个Hypervisor(xen)是一个独立的代码模块，与KVM依附于Linux相比，它不依赖任何其他的系统。这种hypervisor是一种在虚拟环境中的“元”操作系统，位于虚拟机与底层硬件设备之间的虚拟层，直接运行于硬件设备之上，负责对硬件资源进行抽象，为上层的虚拟机提供运行环境所需资源，并使用虚拟机都能够互相不干扰，相互独立的运行于同一个系统中。

下面引用ARM官方文档中的一句话再次表述下Hypervisor的概念（注意我们这个系列文章只聚焦Virtualization 类型的Hypervisor）:

A hypervisor is a program that allows multiple operating systems to share a single hardware processor. Virtualization hypervisors can be broadly classified as bare metal or hosted according to their design. Each has specific use cases. Regardless of the classification, the functional role of a hypervisor remains the same, namely, arbitration of platform resources, and seamless operation of individual guest operating systems with minimal porting effort and runtime sacrifices.

1.2 Hypervisor分类

前面的章节，已经介绍了Hypervisor的基本概念，下面介绍下Hypervisor的分类（注意是Hypervisor的分类，后面还会讲一下虚拟化技术的分类），先引用一段Arm官方文档的介绍:

Hypervisors are broadly split into two basic types:
Type 1:
• Sometimes described as native or bare metal.
• Type 1 hypervisors execute directly on the hardware.
• Any application guest OS sees a virtualized view of this hardware.
Type 2:
• Sometimes described as hosted.
• Type 2 hypervisors run within a host OS.
• The host OS has a physical view of the hardware it runs on, but guest operating systems see a virtualized view.
This is a very broad categorization. In reality, there are variations on the above. The Armv8 architecture allows running a type 2 hypervisor at EL1 or EL2. This blurs the differences between type 1 and type 2.
If you set HCR_EL2.E2H to 1 it enables a configuration where a host OS runs in EL2, and the applications of the host OS run in EL0. In this scenario, EL2 also has an upper and a lower region.

Hypervisor的分类两种: 独立型 - standalone(Type-1)、寄生型 - hosted(Type-2)。如图1-4所示:

独立型(Type-1):
特点：Hypervisor对硬件平台和资源拥有全部的控制权。
代表：type 1 hypervisor比较典型的代表是Xen。

寄生型(Type-2):
特点：宿主OS对硬件平台和资源具有全部的控制权,包括CPU和物理内存。
代表：type 2 hypervisor比较典型的代表是KVM。

有了对Hypervisor一些经典的开源项目