ver0.2
前言
设备虚拟化是整个虚拟化技术体系下一个非常重要的分支，围绕这个领域的研究的课题也非常的多。随着我们系列文章的深入，我们也会逐渐深入整个领域。如果说虚拟化架构核心资源，CPU、内存、中断等资源的虚拟化决定了整个用户体验的下限的话，那么设备虚拟化技术的体验直接决定了整个产品解决方案的上限。尤其是在车载座舱和智能驾驶领域，车机播放一个视频流畅与否、端侧模型运行的效率与准确率良好与否、等等，都直接决定了一款座舱产品的体验。树是有根的，水是有源的，设备虚拟化技术好也是有原因的。本文先从框架层面讨论设备虚拟化的分类，而后的文章再深入细节讨论具体的技术点。相关的内容，前面的文章已经做过一些基础性的介绍，尤其如下文章，建议大家优先读一读，先找找感觉。
(2)[V-01] 虚拟化概论-Hypervisor(基于AArch64)
正文
1.1 虚拟化思想
要理解虚拟化技术，就必须对硬件建立基本的认知。
1.1.1 SOC系统架构
SOC(System on Chip)作为一个硬件平台的核心，必须要对它有一个充分的认识，如图1-1所示。
图1-1 典型基于ARM体系的SOC系统架构
芯片厂商交付给用户的就是SOC，例如高通8155\8295，MTK的8676\8678都是SOC。SOC的基础能力决定了整个硬件平台硬件的Feature和性能上限。
硬件的Feature：例如CPU、GPU、ADSP、NUP、CDSP、DMA、外设接口总线等等，这些Feature大多数都会变成一个个独立的功能单元(IP-Core)，然后通过一个总线串联到一起，构成一个SOC芯片。
性能上限：主要体现在在各个IP-Core的算力、Cache Size、IO吞吐能力，例如CPU的算力和GPU的算力等等。
1.1.2 设备系统架构
只有SOC是不能工作的，拿到SOC之后需要对它进行必要的包装才让它发挥作用，于是就要基于SOC构建硬件平台，如图1-2所示。
图1-2 典型基于ARM体系硬件平台系统架构
CPU是指挥官，SOC就是司令部。在司令部的外围布置上相应的设备，比如磁盘、内存、传感器、屏幕、摄像头、蓝牙芯片等等作战单元就构成了一个完整的部队了。到这里，就构建了一个完整的设备体系，这些设备不光是大家看的见的，还有SOC内部高度集成化的大家看不见的。这些设备就构成了我们下一步讨论设备虚拟化技术的硬件基础。
1.1.3 单系统软件架构
硬件平台环境已经准备好了，下一步就是给它注入思想和灵魂了。在计算机的世界里面，软件就是硬件的思想和灵魂，它最开始的样子是这个样子的，如图1-3所示。
图1-3 典型基于ARM体系的硬件平台单OS架构
上图是一个典型的汽车座舱硬件平台的单系统软件架构，特点如下：
(1) Secure部分相关的软硬件已经是ARM标配了，这是一个非常重要且复杂的领域，这里我们不展开讨论了。
(2) 就是Hardware Platform上所有的设备，在软件层面都会抽象成驱动的形式，供更上层的软件模块使用。
(3) 这些设备驱动一般情况下会被组织在一个操作系统下，目前主流的嵌入式硬件平台操作系统有Android、Linux、QNX等。
(4) 最重要的一个特点就是所有的设备都是归操作系统直接管辖，不受任何其他实体干扰。
1.1.4 虚拟化软件架构
还是那一套硬件，人们发现跑一个系统浪费了，尤其现在的CPU更是在摩尔定律的支持下越来越强悍，内存等其他设备也在能力变得强大的基础上，价格还更加的公道。在这样的一个前提下，虚拟化软件的架构诞生了，如图1-4所示。
图1-4 典型基于ARM体系的硬件平台虚拟化软件架构
同样的硬件平台，但是上面的思想和灵魂不一样了，产生的效果也是不一样的。在虚拟化技术的加持下，上层的OS从一个变成了多个。在硬件能力满足的前提下，好处是显而易见的。还是以座舱平台为例，我们把娱乐相关的业务集中在Android系统下，把仪表相关的业务集中在Linux(SOS)下。这样应用层开发的同学可以享受Android系统丰富的接口，又可以使SOS避免受到Android系统过于丰富的应用带来的不稳定性，因为VM之间是隔离的。当然虚拟化带来的好处不止于此，我们这里还是回归到虚拟化本质：
(1) 首先虚拟化的啥，要先搞清楚。就像革命一样的，为了谁革命就非常重要。虚拟化的是硬件资源，以及资源代表的能力。比如，CPU、内存、中断子系统、SOC上的各个IP-Core，以及通过外设接口连接到SOC总线上的外部设备。
(2) 虚拟化的资源在软件系统内部要有一个分配的策略，比如CPU资源就要各个VM都要覆盖到，没有CPU资源这些VM就玩不转了。GPU资源只需要分配给需要显示相关的VM就可以了，比如Cluster和IVI，TBox就没有必要了。
(3) 多个VM并存在系统中，需要有管理者，要不然就乱套了，这个管理者就是Hypervisor。
(4) Hypervisor管理最重要的一个方面就是看是否有人不按规矩来，或者让大家怎么按照规矩来，比如IVI提交了一个GPU操作请求，目前到底是否可以提交给GPU，会不会对其他的VM的GPU操作请求造成影响。基于这种情况，系统就要有仲裁模块，通常这个仲裁模块就是Hypervisor，当然工程中Hypervisor也可以把相关仲裁的业务委托给其中一个VM。
1.1.5 虚拟化的核心思想
这个小结们只打算写一句话，那就是：
底层的资源或者通过空间的分割，或者通过时间的分割，将下层的资源通过一种简单易用的方式转换成另一种资源，提供给上层使用。
请大家结合前序文章和前面章节仔细理解这句话，理解了这句话，也就理解了虚拟化技术的精髓了。
1.2 设备虚拟化技术
经过前面的铺垫，我们下面的章节就比较轻松了。先看一下，工程中经常遇到的设备虚拟化的场景。
1.2.1 全虚拟化(Full Virtualization)
先看一下全虚拟化软件架构，如图1-5所示。
图1-5 全虚拟化架构
全虚拟化的最大特点就是VM中的驱动不和任何真实的物理设备相关联，Hypervisor需要兜底或者通过陷入的模式委托其他VM进行兜底。通过在Hypervisor或者其他VM模拟出一个和真实物理设备行为一致的虚拟设备和驱动程序对话。这种方式通常应用在VM之间的通信领域，由于是虚拟化系统内部的VM之间的通信，那么这种行为不需要和任何外部设备相关，搞搞内存交换就可以了，这种方式也通常称之为Emulation。(注意上图中，只画出了全虚拟的一种形式。)
1.2.2 半虚拟化(Para Virtualization)
半虚拟化也是工程领域使用最多的架构形式，如图1-6所示。
图1-6 半虚拟化架构
半虚拟化技术就比较友好了，通常情况下是一个前后端的结构(Frontend & Backend)。前端驱动和单系统的驱动一样收集来自用户空间或者兄弟驱动程序的各种请求，然后经过Hypervisor提供的通道汇总到后端驱动，由后端驱动调用真实的设备驱动反馈到物理硬件。上图的中例子，TBox和IVI共享Audio子系统的所有硬件，他们申请到内存buffer并填充待播放的数据后，都可以提交给BackendDriver所在的SOS进行汇总，后端驱动根据既定策略，比如TBox的Ecall发声优先级更高，那么它就会毫不留情的打算IVI请求，保证Audio硬件通道畅通来完成Ecall的业务。通过描述可以看到，半虚拟化的好处就是各个VM共享硬件，但是缺点也很明显就是VM之间的业务会产生干扰，记住这个结论。
1.2.3 直通模式(Passthrough)
还有一种就是直通模式，如图1-7所示。
图1-7 直通架构
直通架构就比较好理解了，比如WIFI设备，别的系统都不用，直接给IVI就好了，省得大家绕弯子。直通模式的有点很明显，我们在讲内存虚拟化的时候介绍过，Hypervisor会在Stage-2阶段直接将设备的真是物理地址分配VM发送过来的地址请求，自然就省事儿了。看上去挺美好是吧，但是确定也非常明显那就是选择直通模式的设备只能一个VM独享。对于Wifi这样的设备还好，如果是GPU这样的大红人就比较麻烦了，总不能让啊别的VM不用吧。如果要让多个VM使用，就享受不到Passthrough带来好处与便利了。
1.3 硬件虚拟化技术
1.3.1 软件虚拟化技术
终于到了我们本文的主题了，让我们来看看啥是硬件虚拟化。在搞清楚硬件虚拟化技术之前，让我们先看看啥是软件虚拟化技术。软件虚拟化通常称为应用级(站在芯片的角度所有的软件代码都是应用)虚拟化，是在操作系统层面或者Hypervisor创建虚拟环境的技术。前面提到的全虚拟化和半虚拟化技术都可以称之为软件虚拟化技术，这里我们举一个GPU虚拟的例子，如图1-8所示。
图1-8 GPU软件虚拟化典型架构
软件虚拟化技术发展到现在已经相当成熟了，目前技术体系下，大多数的设备涉及到在多个VM之间共享基本使用的都是软件虚拟化的技术。这种技术成熟不代表它完美，尤其是涉及到用户体验的场景下。以我们举得GPU软件虚拟化的方案，就可以列出如下的缺点：
(1) VM之间的对GPU的使用是会干扰到对方，一方用的多了就会造成另外一方分的资源不够。
(2) 前后端数据传递链路过长，尽管经过了很多工程师的优化，但是由于涉及到频繁的陷入和内存传递还是会造成数据的流的拥堵问题。
(3) 控制场景复杂，这主要指的是后端驱动，它要考虑的场景实在是太多了，稍不留神机会出错。
(4) 与单系统比，对上提供的接口能力有可能会下降，原因就是前面说的这些，比如上图中Android下就不支持Vulkun，这会对应用层的编程带来一定的平台化压力。
既然软件虚拟化技术有这么多缺点，为什么还在用啊？要我说，就是足够的便宜和稳定。如果不在乎成本，就想要更好的用户体验可以不?可以的，那就是引入硬件虚拟化技术。
1.3.2 硬件虚拟化技术
我们还是以GPU的虚拟化为例，如图1-9所示。
图1-9 基于ARM体系的GPU硬件虚拟化架构
这里直接参考软件虚拟化对比讨论：
(1) 硬件虚拟化上层对接的虚拟化架构，包括Hypervisor和VM等都不需要多过多调整，保持原有架构即可。
(2) 硬件虚拟化的GPU下无需前后端的驱动架构。
(3) 每个VM都可以直接访问真实的物理设备，这个就和直通模式很像了。
(4) GPU内部完成自身资源的划片，供各片资源对应的VM使用，这个和前面讲述的虚拟化思想也是契合的。
(5) 需要仲裁的场景需要GPU硬件发起并通知软件层按照策略执行仲裁，VM之间可以实现完全隔离不需要进行通信。
(6) 由于各个VM都独享GPU资源，那么用户体验特别是在极端工况下要远远优于软件虚拟化方案。
那么硬件虚拟化技术有没有缺点：
(1)系统复杂度高
这里我们就截取一小段手册中的描述就可以证明。
AXI buses
The GPU is accessed with one of 3 AXI busses, AXI-A, AXI-B, and AXI-C. The bus separation is provided to support the safety critical use cases.
AXI-A
Typically, AXI-A is used by a non-critical cluster. It runs quality-managed software, for example quality-managed VMs, such as Android.
AXI-B
Typically, AXI-B is used by a safety critical cluster. It runs safety critical workloads.
AXI-C
Typically, AXI-C is used by a safety island. It is responsible for allocating resources and handling errors.
(2) GPU微架构更加复杂
每分出一个group的资源片就要有一套独立的电源管理、任务管理、配置管理、窗口管理等单元模块，微架构的复杂度可想而知。
(3) 成本高
越复杂的东西越贵，这个就很好理解了，所有ARM目前也不是所有的GPU-IP都支持硬件虚拟化，也就是还没有全系标配，除了技术成熟度的考虑外，再就是成本考虑了，如图1-10所示。
图1-10 ARM体系下GPU硬件虚拟化配置
硬件虚拟化的原理，这里我们只简单提一下就是，详细的不展开了，后面会有专门的文章介绍。如图1-11、1-12所示，能看懂的大家自然就懂了，实在看不懂，可以等一下我们后续的文章，注意这是一个硬件平台上的两个VM的Stage-2内存视角。
图1-11 VM-Cluster-Stage-2内存视角
图1-12 VM-Android-Stage-2内存视角
结语
本文我们从虚拟化技术的思想一路推演下来，介绍了目前的软件虚拟化技术，最后引出了硬件虚拟化技术。值得注意的是，目前的硬件虚拟化技术并不是通用技术，还是有很大门槛的，笔者接触的几个大的芯片厂商提供的解决方案都是在高端产品上才有一两个IP-Core支持硬件虚拟化，所以目前虚拟化研究的领域热点还是软件虚拟化技术，大家还在不断的优化。这里，笔者抛砖引玉，希望更多的小伙伴加入进来，大家一起研究技术。谢谢大家，请点赞、评论、转发。
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.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>
[19] <arm_immortalis_and_mali_gpu_virtualization_guide.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
