虚拟化概述，Hypervisor简介

01虚拟化概述

1.1驱动力和优势

虚拟化是一种广泛使用的技术，支撑了几乎所有现代云计算和企业基础设施。开发人员基于虚拟化功能可以在单台机器上运行多个操作系统，从而完成软件测试而不会存在破坏主计算环境的风险。虚拟化为芯片和基础设施带来了许多特性，包括良好的隔离性、不同资源的可及性、同一资源的工作负载平衡、隔离保护等。 对于汽车芯片，尤其是座舱域SoC，当前的发展趋势是通过提高集成度来节省成本，因此在同一个SoC芯片上会集成多个操作系统对应的物理资源，这些资源需要在虚拟化环境中安全隔离的情况下共存。具体而言，车载SoC虚拟化需要面临的要求和挑战有：

至少三个具有不同安全要求和异构操作系统的域之间的隔离，运行RTOS操作系统的需要满足ASIL-D安全等级要求的安全岛，运行QNX或轻量级Linux操作系统的需要满足ASIL-B安全等级要求的仪表域，运行Android或鸿蒙操作系统的信息和娱乐域系统。

关键资源的可及性和工作负载平衡，包括内存、CPU工作线程等，尤其是在GPU或NPU处理巨大工作负载时。在功率约束和内存容量限制下，通过虚拟化来动态保证资源的可用性和灵活性。

1.2Hypervisor简介

Hypervisor是虚拟化功能最核心的支持组件。Hypervisor主要负责处理虚拟机下陷和管理实际物理资源等功能。Hypervisor主要可以分为两大类：

原生独立的Hypervisor，一般称为Type1 Hypervisor。这类Hypervisor以最高权限运行，控制和管理所有物理资源。在这类Hypervisor运行过程中，与每个虚拟机相关的资源管理和调度功能可以卸载到该虚拟机的操作系统中实现，这样管理程序可以专注于与虚拟化相关的功能。这类Hypervisor典型的案例有QNX Hypervisor和Xen Hypervisor等。

主操作系统内嵌Hypervisor扩展，一般称为Type2 Hypervisor，基本管理功能可以通过主机操作系统实现，Hypervisor扩展只专注于虚拟化支持，与主机操作系统配合实现虚拟化功能。这类Hypervisor典型的案例有Linux KVM等。

对应于ARM异常处理体系结构，通常虚拟机操作系统的应用程序或用户空间处于EL0安全等级。虚拟机操作系统的内核态空间处于EL1安全等级。为了支持虚拟化扩展引入EL2安全等级。具体安全等级细分如下图所示：

对于Type1 Hypervisor：属于虚拟机操作系统用户态空间在EL0安全等级，虚拟机操作系统内核态在EL1安全等级，独立的Hypervisor在EL2安全等级。

对于Type2 hypervisor：虚拟机操作系统用户态空间和宿主机操作系统的用户态空间都在EL0 安全等级，虚拟机操作系统内核态在EL1安全等级。带有Hypervisor扩展的宿主机操作系统内核态空间在EL2安全等级。

图1. Hypervisor类型和对应ARM异常处理等级 从不失一般性出发，后续章节将以 QNX Hypervisor相关的软件实现和基于ARMv8.0体系结构的硬件实现作为典型示例来介绍当前虚拟化的主要问题和解决方案。根据虚拟化场景的功能划分，当前主流座舱SoC的虚拟化大致可以分为三类：

用于VM管理和执行的CPU虚拟化；

用于内存空间分离和管理的内存虚拟化；

以及用于设备配置和管理的设备虚拟化。

02CPU虚拟化

2.1CPU虚拟化概述

CPU或处理器可以为VM提供虚拟处理器的抽象，并执行特定VM的相应指令。通常来说，Hypervisor管理程序直接在物理CPU上执行，占用物理资源并直接使用物理CPU的ISA。而虚拟机操作系统基于虚拟处理器的抽象占用相关资源并执行相关指令，除了需要更高权限的动作外，大部分场景也可以直接使用物理CPU资源和物理CPU的ISA。 Hypervisor和VM的协同管理是通过虚拟机下陷机制实现的，通常这种下陷是VM或应用需要更高的权限才能执行的时候会产生。在ARM架构中，上面介绍的对虚拟化的异常处理等级，VM和应用程序最多可以拥有EL1权限，因此对于不允许执行的指令，将触发虚拟机陷阱。详细流程如下：

通常情况下，VM在物理CPU上运行其指令，与没有Hypervisor的情况下一样；

当虚拟机操作系统或应用程序试图执行一条超出执行权限的指令时，触发虚拟机下陷，虚拟机操作系统做上下文切换，切到Hypervisor程序；

发生虚拟机陷阱后，Hypervisor接管现场，并保存虚拟机的上下文，之后处理虚拟机操作系统开启的任务；

当Hypervisor完成任务后，恢复VM的上下文并将执行权限交还给VM。

图2. 虚拟机下陷机制和处理流程 虚拟机抽象和下陷处理机制将在后续QNX Hypervisor和ARM体系结构中进一步介绍。

2.2QNX虚拟机和虚拟处理器支持

QNX Hypervisor软件架构中资源和组件的详细层次结构如下图所示，从Hypervisor作为操作系统视角来看，各个VM需要通过例化qvm进程来在Hypervisor操作系统用户态空间中注册。在配置某个VM时，会根据规范创建一个对应的qvm进程并进行配置，用以指定该VM的组件，包括虚拟虚拟处理器vCPU、虚拟设备、内存管理页表配置等。

图3. QNXHypervisor资源层级示意图 在Hypervisor正常运行期间，qvm 进程实例需要执行以下操作：

捕获从虚拟机出入的访问尝试，并根据类型进行相应的处理；

在切换物理CPU之前保存VM的上下文；

在物理CPU重新执行某个VM之前恢复该VM的上下文；

负责虚拟化相关故障处理；

执行确保虚拟机完整性所需的维护程序。

在一个qvm进程被例化的同时，会在进程内实例化多个vCPU线程、虚拟设备列表和Stage2页表，分别用于应用线程抽象、虚拟设备抽象和内存虚拟化抽象。对于vCPU抽象，QNX Hypervisor遵循基于优先级的vCPU共享模型，其中优先级包括qvm进程优先级和vCPU线程优先级。在Hypervisor运行规则中，qvm进程的相对优先级和qvm 进程内的 vCPU调度线程的优先级层次化地决定哪个vCPU可以访问物理CPU。但是映射过程和后续执行过程中，VM中运行的内容和数据对于Hypervisor来说是完全的黑盒。Hypervisor仅确保在基于 vCPU的优先级和调度策略共享物理CPU时，较高优先级的vCPU将始终抢占较低优先级的vCPU。除此之外的虚拟设备列表和Stage2页表将在后续章节介绍。

2.3ARM 虚拟机和虚拟处理器支持

ARM架构中的下陷机制是通过异常处理来实现的。如上文所述，通常虚拟机操作系统的应用程序或用户空间处于EL0安全等级。虚拟机操作系统的内核态空间处于EL1安全等级。Hypervisor处于EL2安全等级。如下如左边所示，当超出EL1安全等级的VM或者应用程序指令执行时，将向 EL2级别的Hypervisor发出异常下陷，交由Hypervisor来处理异常，然后通过上下文切换返回到EL1安全等级的VM。 下图右边示例了一个CPU捕获WFI的处理过程。执行等待中断WFI指令通常会使物理CPU进入低功耗状态。通过注入断言TWI信号，如果满足HCR_EL2.TWI==1，则在EL0或EL1安全等级上执行WFI将导致异常并下陷到EL2安全等级上处理。在此示例中，VM通常会在空闲循环中执行WFI，而Hypervisor可以捕获此类下陷动作，并调度不同的vCPU到这个物理CPU，而不是直接进入低功耗状态。

图4. 下陷机制和WFI下陷示例 在ARM体系结构中，vCPU一般代表虚拟的处理单元，每个vCPU在Hypervisor中需要例化对应的vCPU线程。VM对应的是Hypervisor中例化的qvm进程，会包含一个或者多个vCPU线程。

图5. ARM虚拟机和虚拟处理器层级关系

03内存虚拟化

3.1内存虚拟化概述

内存虚拟化配合CPU虚拟化，可以保证所有VM都有独立的内存空间，并严格按照权限进行隔离。而内存虚拟化的关键要求是地址管理，根据上下文配置和控制各个VM对物理内存的访问。 内存虚拟化通常是与通过内存分配和释放的管理相结合来实现的。从硬件实现视角，通常的内存虚拟化是通过控制两级地址翻译来实现的。Hypervisor和VM的内存分配和释放机制都和典型的操作系统内部内存分配和释放的机制类似，使用基于分级页表实现内存管理。

3.2 ARM内存管理体系

ARM架构中采用基于页表的两级地址翻译机制。通常来说，第一层级转换将虚拟地址VA转换为中间物理地址IPA，这一层级地址翻译由操作系统管理和控制。而第二层级地址翻译则将中间物理地址IPA转换为物理地址PA，这一层级地址翻译由Hypervisor管理和控制。这两个阶段的翻译是相互独立，互不干扰的。如下图6所示，连续的虚拟页地址可以映射到离散的中间物理页中的地址，而离散的中间物理页地址可以映射到连续的物理页地址。

图6. 两级地址翻译机制 下图7显示了ARMv8架构的典型两级地址空间。其中，虚拟地址空间主要代表有：

位于非安全EL0/EL1安全等级中的虚拟机操作系统虚拟内存映射空间；

位于非安全EL2安全等级中的Hypervisor虚拟内存映射空间；

位于EL3安全等级中的安全监视器虚拟内存映射空间。

这些虚拟地址空间都是相互独立的，并且每个内存空间都有独立的配置和页表。图示的两级页表可以比较完整地支持内存虚拟化功能，其中Stage1虚拟机操作系统页表可以将虚拟地址转换为中间物理地址，包括串口设备地址、内存地址和存储设备地址，而Stage2虚拟化页表，结合Hypervisor页表和安全监视器页表，可以将中间物理地址转换为合法的物理地址。

图7. ARMv8典型的两级地址空间 在AArch64架构中，物理地址通常为48bits，页表大小通常为4KB或者64KB，为避免页表空间太大，通常采用4级页表划分，按照地址段进行页表项查询。下图为4级页表和第一层级地址翻译示例，具体内容本文不再赘述。

图8. AArch64 4级页表和第一层级地址翻译示例

04设备虚拟化

4.1设备虚拟化概述

虚拟化中Device的概念可以概括为系统中除了运行Hypervisor和VM的处理器之外的可访问内存的设备。在座舱芯片中，典型的Device类型可以总结为：

软件模拟虚拟化设备：借助软件模拟或硬件虚拟化的方法捕捉原生驱动，之后在Hypervisor内模拟虚拟设备的行为，所有虚拟机都通过管理程序陷阱与该设备交互；

半虚拟化设备：为所有虚拟机模拟一个实际的物理设备，所有虚拟机都可以通过一次下陷与该设备进行批处理调用；

直通设备：被虚拟化环境中的特定虚拟机完全独占；

共享设备：可以供一个VM使用，也可以供一个或多个VM和Hypervisor本身使用。

后续章节将详细介绍QNX Hypervisor中设备虚拟化的具体实现以及在ARM体系结构下对于设备虚拟化的支持。

4.2QNX设备虚拟化支持

QNX Hypervisor中的设备可以归纳为：

物理设备，包括直通设备和共享设备，

虚拟设备，包括全虚拟化和半虚拟化设备。

如前面所述，QNX Hypervisor在为VM配置和实例化qvm进程时，需要将物理设备和虚拟设备vdev配置给qvm进程和VM。下图为QNX Hypervisor中对于不同种类设备虚拟化的支持。

图9. QNXHypervisor中的设备虚拟化支持 对于直通设备，VM具有直接且独占的访问权限，并且Hypervisor主机操作系统将被绕过。这类直通设备的驱动程序也将由VM直接拥有。对于直通设备，Hypervisor只需要将来自物理设备的中断直接路由到对应的VM，并将来自VM的所有信号直接传递到对应的设备。所有交互都在VM和设备之间，Hypervisor需要识别并允许通过来自设备的中断和来自来VM的信号。直通设备的典型示例是 PCIe、以太网等。 对于共享设备，这些设备可以被多个访客使用，典型示例是共享内存。QNX Hypervisor支持两种不同类型的设备共享，引用共享和中介共享：

引用共享：共享设备作为直通设备分配给一个特定的VM，该VM也管理该设备的驱动程序，其他授权的VM将通过虚拟设备访问该设备。

中介共享：所有授权的VM通过虚拟设备访问该设备，Hypervisor控制该设备并管理驱动程序。

对于虚拟设备，QNX Hypervisor支持全虚拟化和半虚拟化设备，用来隔离系统上物理设备之间的直接通信：

全虚拟化设备/软件模拟虚拟化设备：为VM模拟实际物理设备的虚拟设备。使用此类设备时，VM不需要知道它在虚拟化环境中运行。根据物理设备的类型，全虚拟化设备可以自己处理所有事务，也可以充当VM和实际物理设备之间的中介。典型示例包括中断控制器GIC、计时器Timer等。

半虚拟化设备：与全虚拟化设备相比，半虚拟化设备可以通过单次异常下陷批量处理设备调用，从而提高效率，减少因为虚拟化而额外引入的异常下陷下陷。QNX Hypervisor支持基于VirtIO1.0标准的半虚拟化设备，包括典型的块设备、I/O 设备、控制台、GPU、DPU、ISP等。

4.3ARM设备虚拟化支持

ARM架构中针对设备虚拟化提供了多方位的支持，其中主要的机制包括系统内存管理单元SMMU和支持虚拟化的中断控制器GIC。 对于SoC系统中除处理器以外的设备，尤其是DMA控制器或具有DMA控制器的设备，在虚拟化场景下由VM分配时，可以通过SMMU保证地址转换和OS级别的内存保护。下图左图显示了操作系统视角下不带虚拟化支持的DMA控制器。DMA控制器将通过主机操作系统内核空间中的驱动程序进行编程，该驱动程序将根据MMU单元为DMA配置物理地址。但是在虚拟化环境中，特定VM的视角下，直通DMA只能基于该VM所对应的第一层级MMU做地址翻译，从而只能配置中间物理。因此，下图右图显示了用于该 DMA 控制器的虚拟化支持的系统内存管理单元SMMU，可以在支持VM直接配置直通DMA。所有的内存访问都可以通过管理程序主机编程的SMMU从IPA转换为PA，以确保VM和DMA都是基于IPA进行地址操作而保持统一的视角。

图10. ARM架构中SMMU对设备虚拟化的支持 从Arm GICv2开始，如下图所示，GIC可以通过提供物理CPU接口和虚拟CPU接口来发出物理和虚拟中断信号。从GIC功能来看，这两个接口是相同的，区别是一个发出物理中断信号而另一个发出虚拟中断信号。Hypervisor可以将虚拟CPU接口映射到VM，允许该VM中的软件直接与GIC通信。这个机制的优点是Hypervisor只需要设置虚拟接口，而不需要采用全虚拟化的方式来支持GIC。可以减少中断下陷的次数，从而减少中断虚拟化的开销。

图11. ARM架构中GIC对设备虚拟化的支持

05结语

虚拟化正迅速成为现代车载场景软件架构中的一项关键技术，尤其是座舱SoC当前面临着安全隔离、灵活性和高利用率的挑战。Hypervisor软件与硬件虚拟化扩展的配合，可以让座舱场景中的虚拟化特性更加高效、安全。

审核编辑 ：李倩