[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的框架代码。

图1-1 Hypervisor(KVM)的核心框架代码

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

图1-2 Hypervisor(KVM)的体系(ARM64)相关代码

在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所示。

图1-3 xen的核心代码结构

这个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所示:

图1-4 Hypervisor Types

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

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

有了对Hypervisor一些经典的开源项目代码结构的大致介绍，相信理解Hypervisor的分类应该不难，主要看Hypervisor这一段代码是否能够直接控制硬件资源这一个维度。
还有另外一个维度（特权等级），就是ARM官方文档中介绍的通过配置“ HCR_EL2.E2H”这个寄存器可以让Host OS在ELx级别工作的表述，先看图1-5，一个典型的虚拟化架构（基于aarch64）的各个Level模块工作的特权等级。

图1-5 Exception Levels(ARM)

后续的文章会专门介绍ARM架构的Exception模型，这里面简单介绍一下，不同的软件模块工作的特权等级是不一样的，那么何为特权等级:

Privilege dictates which processor resources a software entity can see and control.

目前的ARMv8架构下，总共分成四个等级EL0到EL3(对应x86架构，ring4到ring0)，Hypervisor一般情况下需要工作在EL2级别，这对于Type1类型的Hypervisor比较简单明了，但是对于Type2型的Hypervisor就比较复杂一些，因为Type2类型的Hypervisor需要寄生在一个Host OS中才能工作，因此整体系统工作的时候需要做精确而频繁的Exception Level的管控，例如KVM就需要使用Linux内核中已经完善的进程调度、内存管理、IO管理等基础功能完成Hypervisor的工作，这个时候KVM可以理解为轻量化的Hypervisor或者狭义的Type-2型的Hypervisor，那么此时把Linux的kernel配置成EL2权限，那么此时Hypervisor+Linux kernel就可以理解成广义的Hypervisor，而这个广义的Hypervisor就可以看成是Type1型的Hypervisor。虽然从特权等级的角度去区分Hypervisor的类型不够严谨，但是事实上很多文档资料中的表述还是会这样去做归类，这里和大家讲清楚，避免大家看到后感到困惑。

1.3 Hypervisor的特征

上面我们已经了解了Hypervisor的概念和分类，这个章节会介绍一下Hypervisor的特征，其实也是虚拟化技术的特征，这里还是先引用一段ARM文档中的描述：

Virtualization is a widely used technology, and underpins almost all modern cloud computing and enterprise infrastructure. Virtualization is used by developers to run multiple Operating Systems (OS) on a single machine, and to test software without the risk of damaging the main computing environment.
Virtualization is popular for server systems, and support for virtualization is a requirement for most server grade processors. This is because virtualization gives very desirable features to the data center, including:
• Isolation:
At its core, virtualization provides isolation between virtual machines running on a single physical system. This isolation allows the sharing of a physical system between mutually distrusting computing environments. For example, two competitors can share the same physical machine in a data center without being able to access each other’s data.
• High Availability:
Virtualization allows seamless and transparent migration of workloads between physical machines. This technique is commonly used to migrate workloads away from a faulting hardware platform that may require maintenance and replacement.
• Workload balancing:
To optimize the hardware and power budget of the data center, it is important to use each hardware platform as much as possible. Again, this can be achieved using migration of virtual machines, or by co-hosting suitable workloads on physical machines. This means that the physical machines are used for as much of their capacity as possible. This provides the best power budget for the data center provider, and the best performance for the tenant.
• Sandboxing:
VMs can be used to provide sandboxes for applications that might interfere with the rest of the machine that they run on. Examples of such applications include legacy applications, or software that is in development. Running those applications in a VM prevents bugs or malicious parts of the applications from interfering with other applications or data on the physical machine.

这里ARM的官方文档着重举例了云计算领域，虚拟化技术所要具备的特征，实际上ARM的虚拟化技术却是在嵌入式领域使用的比较多，而且越来越多，下面我们逐一分析下这几个特征：
隔离
主要是针对的是VMs，具体就是一套硬件环境运行不同的虚拟机，彼此共享硬件，却可以隔离各自数据。首先翻译翻译啥是数据，一个VM上徐行的GuestOS中一个应用，比如Camera程序，一个用户拍了几张照片，其他VM上的GuestOS中的相册应用就不能查看这张照片，这就是隔离。其他种类的数据，大家自行脑补。但是，实际的业务上，有的时候又需要VM之间共享一些数据，这就另外的课题，后面文章会专门讲一下。这里面从技术上简要分析一下隔离的边界，这个隔离的维度一定要搞清楚是事情是相同Level(x86上叫ring，Arm上叫Exception)的隔离，高Level的软件模块仍然有权限访问任何低Level的数据，比如Linux内核可以访问所有应用层的数据。那么同样Hypervisor有权限访问低Level GuestOS中的所有数据。

隔离技术目前包括硬件隔离、容器隔离、进程隔离、虚拟化隔离等,其中虚拟化隔离(VMM实现OS级别的隔离)是最佳解决⽅案。
例如在汽⻋业务中,不同的领域有不同的需求,所使⽤的操作系统也不同:
(1)在座舱域业务中,交互体验和应⽤⽣态是关键,⼤部分⼚家会使⽤Android系统;
(2)在仪表盘、辅助驾驶等业务中,可靠性和操作性是关键,⼤部分⼚家会使⽤RTLinux、RTOS。
(3)在这些域融合的过程中,⼚家需要使⽤隔离技术来使得这些系统⽣态可并发独⽴运⾏(单个系统宕机不会影响其他系统正常运⾏),安全可靠,可互相兼容。
(4)这种场景下只能用虚拟化级别的隔离。

高可用性
虚拟机可以无缝迁移到其他硬件环境，但是这个适用云端场景。嵌入式场景就比较尴尬了，一台车的HUT发生了硬件故障，只能去4S店换件。
负载均衡
充分利用硬件平台资源,将负载均衡的迁移到不同的physical machines。这个在嵌入式场景的表现要有一些区别，现代处理器很多都是异构架构，比如高通的8155型号CPU有8个核，但是算力分布确实不均匀的（1大3金4银），那么VMs算力的分配就要提前设计好，哪些核做绑定具体VM的配置，哪些核做VMs之间共享算力的配置。当然算力资源只是一种比较突出的资源，另外一个比较重要的资源就是内存。由于嵌入式场景的硬件封闭属性，那么所有的资源基本都要在硬件出厂前配置好，与云端比较的话，在runtime的场景下做负载均衡处理的空间不大。
沙箱
隔离的意义差不多,避免其他软件的干扰。这个很好解释的，一个GuestOS中的应用有bug不能影响别的GuestOS的稳定性；一个GuestOS中了病毒不能影响别的GuestOS的数据安全和功能。

1.4 虚拟化分类

借Hypervisor这一方宝地，我么介绍下虚拟化技术的分类，以帮忙大家理清混沌的虚拟化世界。

计算机的世界也是混沌的，因为很多概念不是非黑既白的，就像我们前面讨论Hypervisor的分类一样，从不同的角度看过去，Hypervisor也是不一样的。虚拟化技术体系庞大而复杂，尤其是一个量产的系统，为了达到最优的效果，往往要打破很多技术的边界做各种融合，这些技术交织在一起往往让人感到困惑，虚拟化系统不是一个维度能够讲清楚的，要通过多个角度去观察去思考才能够摸到这个虚拟化世界的大致轮廓，从这个轮廓一个点深入下去才能够领略虚拟化内部的结构。

（1）前面已经讲过了虚拟化技术的核心点就是对硬件资源做空间和时间上的分割，那么从硬件资源的角度对虚拟化做分类，大致可以归为如下几种类型
计算资源的虚拟化
主要是针对CPU和内存资源的虚拟化技术，这部分核心代码一般情况下要实现在Hypervisor内部。如图1-6、图1-7所示的vCPU和虚拟化内存的架构。

图1-6 CPU虚拟化

图1-7 memory虚拟化

IO资源虚拟化
针对IO资源的虚拟化技术，其实就是对除了CPU和内存之外的所有设备，熟悉内存模型的同学都知道，不论是统一和独立的编地，所有的外部设备（GIC、Timer、GPU、aDsp、USB HOST\RootHUB、PCI HOST、SPI HOST、NIC、SMMU\IOMMU、UART HOST、I2CHOST等等）都需要特定的IO内存空间才能够和CPU打交道，这些设备统称为IO资源。
这些IO资源的虚拟化就要在具体的环境下看实现的方式了，主要还是依赖Hypervisor的架构方案。核心的代码一般情况下会从Hypervisor做分离，从操作系统的角度看，这些设备的驱动一般都会在单独的进程中运行。如图1-8所示：

图1-8 IO设备虚拟化

存储资源虚拟化
针对磁盘存储的虚拟化技术，属于IO资源虚拟化范畴。在云计算领域情况比较复杂，与嵌入式设备比较，云端的存储资源是一个资源池，存储的介质、位置、结构、安全等级都不一样（我们主要针对嵌入式场景，这个点暂时不做重点讨论）。如图1-9所示

图1-9 存储资源虚拟化

网络资源虚拟化
针对网络链路资源虚拟化技术，属于IO资源虚拟化范畴。同样在云计算领域情况比较复杂，一般都是服务器集群场景的大规模架构，这里不做重点讨论（主要是太复杂，研究水平还不到位，讨论不了,哈哈）。如图1-10所示:

图1-10 网络资源虚拟化

上面的分类涉及到一个设计模式的问题，通常情况下都是“单一资源多个逻辑表示”这种模式，一个物理资源被虚拟化以后，供多个消费者使用。例如，在嵌入式场景下，每个VM都认为自己独占显卡或者CPU等资源。云计算场景下就不是这样了，由于服务器集群的特殊物理架构，软件方面的消费节点（软件OS节点）期望的其实是一个硬件资源节点，那么此时的虚拟模式，应该是“多个资源单一逻辑表示”。当然，还有其他的各种设计模式，都需要依赖特定的场景选择合适的设计模式。本文主要是还是聚焦在嵌入式场景，因此行文中如无特殊树明，都是在“单一资源多个逻辑表示”这种模式下展开。

（2）从资源的角度我们已经对虚拟化做了简单的归类，下面从实现虚拟化的技术方案的角度对虚拟化技术做分类，目前主流的实现方案有三种: 全虚拟化(Full virtualization-emulation)、半虚拟化(para-virtualization)、硬件辅助虚拟化(Hardware-Assisted Virtualization)。核心的点就是VM如何通过Hypervisor提供虚拟的硬件资源。
全虚拟化(Full virtualization-emulation)
全虚拟化指虚拟机模拟了完整的底层硬件,包括处理器、物理内存、时钟、外设等,使得为原始硬件设计的GuestOS完全不作任何修改就可以在虚拟机中运⾏。
这个其实是比较好理解的，核心的点就是GuestOS不需要任何修改（这个也是全虚拟化方案最突出的优点），此时的GuestOS认为它访问的就是真实的硬件。此时，windows系统也可以跑在Linux上；Linux系统&Android系统的镜像不做任何修改也可以跑在虚拟机上。
任何事情都是有代价的，此时任何涉及到任何敏感指令（更高权限的需求）或者敏感资源的访问（访问所有硬件的操作）都需要Hypervisor兜底儿识别，这个对于物理CPU是有时间开销（也就是算力的开销）。正常GuestOS访问一个寄存器（比如timer的计数）一条指令就够了，现在这个操作就要被Hypervisor截获跳转到另外一串代码去处理，然后返回给GuestOS，这个过程就增加CPU算力的消耗。如果是相同体系的ISA（GuestOS和Hypervisor相同），此时性能还尚可，如果不同ISA体系，那么GuestOS的每条指令都需要做截获处理，这个CPU的算力开销是非常大。（本文主要讨论相同ISA体系的情况，也就是Virtualization的情况）

The classic definition of a VM is a separate, isolated computing environment, which is indistinguishable from the real physical machine. Even though it is possible to fully emulate real machines on Arm-based system, this is often not an efficient thing to do. Therefore, this kind of emulation is not done very often. For example, emulating a real Ethernet device is slow, because each access to an emulated register performed by the Guest OS must be handled in software by the hypervisor. This handling can be much more expensive than accessing registers on a physical device.

图1-11 全虚拟化架构示例

通过图1-11 可以看到以外部设备为角度的全虚拟化方案，这里可以看出一些特征:
(1) 模拟的设备可以是一个物理设备无关联的节点，就是纯纯的模拟出来的一个设备，比如一个GuestOS中要使用PCI总线控制一个外设，而且物理soc上可能都没有PCI控制器，那么此时就需要VM模拟一个PCI控制器和GuestOS的PCI驱动协同工作。
(2) GuestOS中的驱动不需要任何修改，那么所有的硬件逻辑比如中断通知、DMA传输数据等等，都要由VM中的模拟设备吸收，而且要Hypervisor频繁的捕获，转发这些消息给虚拟设备做相应的操作。

关于截获， 事实上不是每条敏感指令的操作，都能够被Hypervisor截获，这个就涉及的虚拟话漏洞的课题，而且这个课题适合体系相关的（x86架构就有一些敏感操作的指令，Hypervisor捕获不了），这里暂时不展开讨论了。

陷入、捕获、模拟等也是虚拟化技术的重要课题(Trap and emulate is the key mechanism to support the device emulation)，这里先不展开讨论，大家暂时能理解下面的例子就可以。例如，一个Hypervisor上运行了两个VMs，这个两个VM分别运行了两个GuestOS（一个Android OS和一个Linux OS），此时Android系统中一个应用通过Android的Power接口通知系统下电，此时Android系统的意图是通知它所运行的虚拟机下电，而不是物理机器。按照Hypervisor的“隔离”和“沙箱”属性，此时的Hypervisor要保证目前的场景下另外一个GuestOS(Linux)正常工作的。因此，Hypervisor必须对Android系统的Power接口的请求做捕获，先挂起Android的执行流（先别动，Android被陷入了），Hypervisor根据既定的策略忙活一阵（自己模拟或者让VM模拟），然后恢复Android系统继续执行。

半虚拟化(para-virtualization)/超虚拟化(Paravirtualization)/准虚拟化
ParaVirtualization的翻译各位神的意见都不一样，上面都列了一下，但是个人觉得半虚拟化的翻译更贴切一些。在全虚拟化之后搞出半虚拟化技术方案，核心还是为了提高虚拟化系统的执行效率(还有一部分原因是因为虚拟化漏洞)。如图1-12，为一般的半虚拟化的架构。

图1-12 半虚拟化架构示例

全虚拟化因为频繁的捕获导致GuestOS的执行效率低，算力消耗大，那么半虚拟化的解决思路就是通过修改GuestOS的软件模块配合Hypervisor和VM一起减少Hypervisor对GuestOS的敏感指令的捕获，进而导致的GuestOS被频繁的陷入。主要是有两个方向: HVC 和 VIRTIO。
(1) HVC 首先此时的GuestOS是清楚自身运行在VM上的，因此需要尽量修改原生代码中对于敏感资源的访问操作以及特权指令的使用，通过直接和Hypervisor通信（Hypervisor层需要提供接口）使用Hypervisor的服务。这里有一点要清楚，通过使用HVC的方式使用Hypervisor的服务还是需要Hypervisor做捕获的，CPU的context也是需要做Exception Level的切换的，不能绝对避免Hypervisor的捕获操作，但是因为大大减少捕获操作从而减少了GuestOS的陷入次数，从而提高了GuestOS的执行的效率。
(2) VIRTIO GuestOS性能差还有一个原因是因为IO的操作几乎都是对敏感资源的访问，而敏感资源是被Hypervisor保护的，如果不做修改那么所有的操作都会被捕获，而且这些IO的操作一般的虚拟化架构下外设的后端驱动（虚拟机外设服务）都不是Hypervisor提供的，而是由一个独立的进程或者干脆是一个实时系统，那么此时HVC是不起作用，那么就需要提供一种机制，在Hypervisor的帮助下，将各种各种前端设备的驱动（GuestOS中的设备驱动）的IO操作标准化、序列化、通过少量的陷入就可以达到访问设备的需求。如图1-13所示，通过加一个抽象一套VIRTIO接口，借助Tansport层就可以达到目的。

VIRTIO机制后面会有文章单独讲一下 ，这里暂时不展开了。核心的原理也没有那么神秘，以操作系统的视角看去，大家(GuestOS&VM)本来就工作在一个系统环境下，共享同一个内存节点，分属于不同的线程(GuestOS和VM同进程，但是不在一个线程)或者进程。因为在全虚拟化的环境下不知道彼此的存在，因而沟通的时候花了很多冤枉时间内，而在半虚拟化环境下大家都认识了，有些弯子就不必绕了，只来直去就好了。

图1-13 全虚拟化和半虚拟化对比

硬件辅助虚拟化(Hardware-Assisted Virtualization)
半虚拟化的技术应用之后，GuestOS的性能得到了很大提高，但是各个芯片厂商并没有满足现状，不管是云计算领域还是嵌入式领域都需要更快的GuestOS，于是很多厂家在自家的芯片上增加了新的设计来优化虚拟化的体验，也就是硬件辅助虚拟化技术。
硬件辅助虚拟化(Hardware-Assisted Virtualization)是指借助硬件(主要是主机处理器)的⽀持来实现⾼效的全虚拟化。
(1) 首先是增加了新的模式来区分GuestOS、VMM、以及VM各自软件的运行环境，将他们隔离开来。
(2) 改造和丰富硬件体系ISA，GuestOS可以直接在不同ELx使用这些指令集加速执行自己的业务代码。例如，通过特殊的指令实现GuestOS和VMM的上下文切换，提高捕获、陷入进入和退出的速度。
(3) 增加了大量的寄存器，例如给vCPU配置整套的vRegs以实现在GuestOS运行模式下像物理CPU的同等性能靠拢的效果。
(4) 优化CPU的总线架构，增加虚拟的CPU接口，实现高频的业务直接透传到GuestOS，而无需进行ELx的切换，从而提高性能。如图1-14 所示ARM对GIC控制器的功能增强，使得物理中断或者虚拟机产生的模拟中断可以虚拟中断的形式直接通知到GuestOS。

ARMv7 architectures with hardware virtualization support also include virtualization support for timers and the interrupt controller.
Marc Zyngier implemented support for these features, which are called “generic timers” (a.k.a. architected timers) and the Virtual Generic Interrupt Controller (VGIC).
Today, on most architectures that have hardware support for virtualization, including Arm, the Guest OS runs mostly unmodified. The Guest OS thinks that it is operating on real hardware, except for drivers for I/O peripherals such as block storage and networking, which use paravirtualized devices and device drivers. Examples of such paravirtualized I/O devices are Virtio and Xen PV Bus.

图1-14 ARMv8 Virtual GIC 系统架构

(5) 优化体系的内存模型，可以使一些物理设备能够直接透传到一个具体的GuestOS。这种模式下，GuestOS可以独占物理设备，例如一个USB的Host Controller直接和USB的HCD通信，这样这个USB Root Hub下的所有的USB设备就自动透传到这个GuestOS，可以有效的提高GuestOS对这些设备的访问速度，接近和Native 系统一样的性能。通常这种模式，在虚拟化范畴被成为passthrough模式，如图1-15所示。

图1-15 Passthrough模式

融合:
虽然上⾯对虚拟化的分类已较为精确,但这种分类并不是绝对的,⼀个优秀的虚拟化软件往往需要更加具体的工程项目的实施情况融合多项技术方案。

2. Hypervisor software functions:

前面阐述了Hypervisor的概念、作用、分类，但是颗粒度还是比较大的，下面我们把颗粒度变小，看看Hypervisor具体要干那些事情，下面还是引用一段ARM官方文档中的介绍:

The functions that a hypervisor performs do not depend on the type of hypervisor deployed. They include:
• Memory management.
• Device emulation.
• Device assignment.
• Exception handling.
• Instruction trapping.
• Managing virtual exceptions.
• Interrupt controller management.
• Scheduling.
• Context switching.
• Memory translation.
• Managing multiple virtual address spaces.

这里大家可以先简单了解一下，着急的话可以先自行阅读ARM的文档，我们会在后面文章中逐一阐述，这些具体的功能还是结合具体的场景分析比较好。另外，上面是芯片设计领域对Hypervisor的功能的设计，实际到软件开发阶段还会融入更多的服务进入Hypervisor，例如加密计算、安全领域等等，这些专业的领域也非常的有趣。

结语

由于Emulation可以归类为一种特殊的全虚拟化模式，也不是我们要讨论的重点，这里我们就不花笔墨做详细的阐述了，我们的精力主要还是放在Virtualization这个领域。

本文着重阐述了Hypervisor(VMM)，在虚拟化这个技术领域，Hypervisor就是灵魂。在GuestOS、VMs、VMM组成的虚拟化体系下，VMM就是核心和纽带，所有的虚拟化软件方案和技术都要围绕着Hypervisor这个点展开，以Hypervisor的类型和基础服务为基础做二次设计。例如GuestOS的定制，VM中的后端驱动服务的开发，Graphic子系统、Audio子系统、网络子系统的架构设计等等。

对于Hypervisor的分类，我们也做了详细的说明。随着微内核操作系统技术的发展,很多基于微内核操作系统设计的Hypervisor依赖的Host OS已经非常精简，只包括基本的、不变的功能，CPU调度和内存管理，设备驱动和其他可变组件处于内核之外，这类Hypervisor应当归于Type1、还是Type2,业内存在分歧。总体来说,微内核Hypervisor更小、更稳定、扩展性更好,更适合用于嵌入式虚拟化场合。

虚拟化技术是一个多种技术方案融合技术体系，从来不是一个点或者一条线能够解释清楚，通过这个体系下各个组件千丝万缕的联系在时间和空间两个维度分割和高效利用了硬件资源。后续的文章，会围绕着Hypervisor这个核心逐渐展开，为大家呈现出虚拟化技术的宏伟和精妙之处。

reference

[00] <80-ARM-VIRT-cs0004_Armv8架构虚拟化介绍.pdf>
[01] <aarch64_virtualization_100942_0100_en.pdf>
[02] <80-ARM-VIRT-cs0002_ARM虚拟化介绍.pdf>
[03] <80-ARM-VIRT-cs0003_ARM虚拟化技术简介.pdf>
[04] <Armv8-A-virtualization.pdf>
[05] <aarch64_exception_model_102412_0102_en.pdf>
[06] <80-VIRT-OVW-cs0009_虚拟化技术概述介绍.pdf>
[07] 指令集介绍 - <ISA****.pdf>
[08] 寄存器集合 - <SysReg****.pdf>
[09] <vd80-3xxx5-1c_AUTO_SAxxxx_QNX_HYPERVISOR_ARCHITECTURE_OVERVIEW_(CHINESE).mp4>
[10] <80-VIRT-CPU-cs0001_什么是CPU虚拟化.pdf>
[11] <80-VIRT-CPU-cs0002_CPU虚拟化.pdf>
[12] <80-VIRT-hyper-虚拟化(Hypervisor)技术详解.pdf>
[13] <80-VIRT-OVW-cs0010_Emulation和Hardware-virtualization的比较.pdf>
[14] <80-VIRT-OVW-cs0011_完全仿真与完全虚拟化.pdf>
[15] <80-VIRT-OVW-cs0004_虚拟化技术的实现-完全虚拟化-硬件辅助虚拟化.pdf>
[16] <80-VIRT-OVW-wx0003_车载OS-虚拟化技术与微内核的技术路线选择.pdf>
[17] <80-VIRT-OVW-cs0008_深入理解虚拟化.pdf>
[18] <79-V-KVM-lq0001_QEMU-KVM源码解析与应用.pdf>

Glossary

BE - Back End
FDE - Full Disk Encryption
FE - Front End
GVM - Guest Virtual Machine
QCPE - Qualcomm Protected Environment
SMMU - System Memory Management Unit
TZ - TrustZone
VM - Virtual Machine
vPE - virtual Processing Element (vPE)
ELs - Exception Levels
VMID - virtual machine identifier
TLB - translation lookaside buffer(地址变换高速缓存)
IPA - Intermediate Physical Address(IPA地址空间由Hypervisor控制)
VTTBR_EL2 - Virtualization Translation Table Base Registers(ArmV8 寄存器)
ASID - Address Space Identifier (ASID)
PSCI - Power State Coordination Interface
DVFS - Dynamic Voltage and Frequency Scaling (DVFS)
ACPI - Advanced Configuration and Power Interface (ACPI)
FDT - Flattened Device Tree
SCMI - System Control and Management Interface (SCMI)
KVM - Kernel-based Virtual Machine
SMMU - System Memory Management Units (SMMUs)
WFI - Wait For Interrupt (WFI)
GIC - Arm’s Generic Interrupt Controller (GIC)
IRQ - Interrupt ReQuest
FIQ - Fast Interrupt Request
VHE - Virtualization Host Extensions (VHEs)
BLSP - BAM low-speed peripheral
trap - 捕获(trap)
QUP - -Qualcomm Universal Peripheral
PCIe - Peripheral component interconnect express
C2C - chip 2 chip
SPMI - System power management interface
PMIC - Power Management IC
IC - Integrated Circuit Chip
HLOS - High level operating system
IFS - Initial File System
FDE - Full disk encryption
LCM - Lifecycle manager
VMM - Virtual Machine Manager
VMM - Virtual Machine Monitor
HCR - Hypervisor Configuration Register
PMSA - Protected Memory System Architecture
DMB - Data Memory Barrier
DSB - Data Synchronization Barrier
SPI - Shared Peripheral Interrupts (SPIs)
PPI - Private Peripheral Interrupts (PPIs)
SGI - Software Generated Interrupts (SGIs)
SDN - software defined networking
NFV - network functions virtualization 网络功能虚拟化
VBAR - Vector Base Address Register
SCTLR - System Control Register
ELR - Exception Link Register
ESR - Exception Syndrome Register
FAR - Fault Address Register
HCR - Hypervisor Configuration Register
SCR - Secure Configuration Register
SCTLR - System Control Register
SPSR - Saved Program Status Register
ISA - Instruction Set Architecture