虚拟化：提升座舱算力效率

注：英文原文附在中文翻译版本后

一、虚拟化概述

1.1 驱动力和优势

虚拟化是一种广泛使用的技术，支撑了几乎所有现代云计算和企业基础设施。开发人员基于虚拟化功能可以在单台机器上运行多个操作系统，从而完成软件测试而不会存在破坏主计算环境的风险。虚拟化为芯片和基础设施带来了许多特性，包括良好的隔离性、不同资源的可及性、同一资源的工作负载平衡、隔离保护等。

对于汽车芯片，尤其是座舱域SoC，当前的发展趋势是通过提高集成度来节省成本，因此在同一个SoC芯片上会集成多个操作系统对应的物理资源，这些资源需要在虚拟化环境中安全隔离的情况下共存。具体而言，车载SoC虚拟化需要面临的要求和挑战有：

1.2 Hypervisor简介

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

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

二、CPU虚拟化

2.1 CPU虚拟化概述

CPU或处理器可以为VM提供虚拟处理器的抽象，并执行特定VM的相应指令。通常来说，Hypervisor管理程序直接在物理CPU上执行，占用物理资源并直接使用物理CPU的ISA。而虚拟机操作系统基于虚拟处理器的抽象占用相关资源并执行相关指令，除了需要更高权限的动作外，大部分场景也可以直接使用物理CPU资源和物理CPU的ISA。

Hypervisor和VM的协同管理是通过虚拟机下陷机制实现的，通常这种下陷是VM或应用需要更高的权限才能执行的时候会产生。在ARM架构中，上面介绍的对虚拟化的异常处理等级，VM和应用程序最多可以拥有EL1权限，因此对于不允许执行的指令，将触发虚拟机陷阱。详细流程如下：

图2. 虚拟机下陷机制和处理流程

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

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

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

图3. QNX Hypervisor资源层级示意图

在Hypervisor正常运行期间，qvm 进程实例需要执行以下操作：

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

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

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虚拟机和虚拟处理器层级关系

三、内存虚拟化

3.1 内存虚拟化概述

内存虚拟化配合CPU虚拟化，可以保证所有VM都有独立的内存空间，并严格按照权限进行隔离。而内存虚拟化的关键要求是地址管理，根据上下文配置和控制各个VM对物理内存的访问。

内存虚拟化通常是与通过内存分配和释放的管理相结合来实现的。从硬件实现视角，通常的内存虚拟化是通过控制两级地址翻译来实现的。Hypervisor和VM的内存分配和释放机制都和典型的操作系统内部内存分配和释放的机制类似，使用基于分级页表实现内存管理。

3.2 ARM内存管理体系

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

图6. 两级地址翻译机制

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

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

图7. ARMv8典型的两级地址空间

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

四、设备虚拟化

4.1 设备虚拟化概述

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

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

4.2 QNX设备虚拟化支持

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

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

图9. QNX Hypervisor中的设备虚拟化支持

对于直通设备，VM具有直接且独占的访问权限，并且Hypervisor主机操作系统将被绕过。这类直通设备的驱动程序也将由VM直接拥有。对于直通设备，Hypervisor只需要将来自物理设备的中断直接路由到对应的VM，并将来自VM的所有信 直接传递到对应的设备。所有交互都在VM和设备之间，Hypervisor需要识别并允许通过来自设备的中断和来自来VM的信 。直通设备的典型示例是 PCIe、以太 等。

对于共享设备，这些设备可以被多个访客使用，典型示例是共享内存。QNX Hypervisor支持两种不同类型的设备共享，引用共享和中介共享：

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

4.3 ARM设备虚拟化支持

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对设备虚拟化的支持

五、结语

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

英文原文：

1. Virtualization overview

1.1 Motivation and Benefits

Virtualization is a widely used technology and traditionally underpins almost all modern cloud computing and enterprise infrastructure, which is used by developers to run multiple operating systems on a single machine, and to test software without the risk of damaging the main computing environment. Virtualization brings many features to chip and infrastructure, including isolation, high availability, workload balancing, sandboxing, etc.

As for automotive chips, especially the cockpit SoCs, cost savings via high levels of integration are driving the need for safe and secure co-existence of multiple operating environments on the same SoC chip. More specifically, the requirements and challenges of virtualization are:

1.2 Hypervisor Introduction

Hypervisor is the key part for virtualization to handle the virtual trap and manage the physical resources. Hypervisors can be divided into two broad categories:

Corresponding to the ARM trust zone exception level, typically, the applications or the user spaces of the guest OSes are on the EL0 level. And the kernel spaces of the guest OSes (VM for shorted) are on the EL1 level. To support the virtualization extension, the EL2 level has been introduced for hypervisor. More specifically:

Figure 1. Hypervisor Types Corresponding to ARM Exception Level

In the following chapters, the QNX hypervisor related software implementation and ARMv8.0 based hardware implementation will be used as the typical example for easier explanation. Based on the functionalities, the virtualization of modern on chip systems can be classified as the CPU virtualization for VMs’ management and execution, the memory virtualization for memory space separation and management, and the device virtualization for the device configuration and management. All these three types of virtualization will be introduced in next chapters.

2. CPU Virtualization

2.1 CPU Virtualization overview

CPUs or processors can provide the abstraction of the virtual processors for the VMs and execute the corresponding instructions of specific VM.

Typically, the hypervisor executes on the physical CPUs, occupying the physical resources and using the physical ISA directly. While the VMs occupy related resources and execute related instructions based on the abstraction of virtual processors, which can also use the physical CPUs directly in most of the scenarios, except for the actions that need higher authority.

And the cooperation and management of hypervisor and VMs are achieved through the trap mechanism, where the VMs or applications need higher authority for execution. In ARM architecture, exception level support for virtualization introduced above, the VMs and applications can on have up to EL1 authority, thus for instruction not permitted to execute, the trap mechanism will be used. Detailed procedures are:

Figure 2. Trap Mechanism for CPU Virtualization

The detailed support for the virtual machine abstraction and trap mechanism in the QNX hypervisor and ARM architecture will be introduced below.

2.2 QNX VM and vCPU Support

The detailed hierarchy of resources and components in QNX Hypervisor environment are listed in the below figure, from the point of view of the hypervisor itself, a VM is implemented as a qvm process, which is an OS process running in the hypervisor host, outside the kernel space. When configuring this VM, a qvm process will be created and configured according to specifications to specify the virtual components of the machine, including the virtual CPUs (vCPUs), virtual devices, memory management configurations etc.

Figure 3. Resource Hierarchy of QNX Hypervisor

During operation a qvm process instance does the following:

Inside a qvm process, multiple vCPU threads are instanced for application thread abstraction, the list of pass-through devices, virtual devices and stage2 page table are used for device virtualization and memory virtualization, which will be introduced later.

For the vCPU abstraction, the QNX Hypervisor follows a priority-based vCPU sharing model, where the priorities consist of the qvm process priority and vCPU thread priority. In the hypervisor host domain, the relative priorities of qvm processes and the priorities of vCPU scheduling threads inside the qvm process determine which vCPU gets access to the physical CPU.

However, the hypervisor host has no knowledge of what is running in its VMs, or how guests schedule their own internal software. The hypervisor host only ensures that a higher priority guest OS will always preempt a lower priority guest OS when sharing a physical CPU based on the priority and scheduling policy of vCPUs.

2.3 ARM VM and vCPU Support

The trap mechanism in the ARM architecture is achieved through the exception handling. As descripted above, the applications or the user spaces of the guest OS are on the EL0 level. The VMs are on the EL1 level. The hypervisor runs in the EL2 level. When an exception caused by sensitive instructions beyond the authority of the VM in EL1 level happens, the trap to the hypervisor in EL2 level will be emitted. The hypervisor handles the exception and then returns to the VM in EL1 level by context switch.

Here has an example of trapping WFIs for CPU. Executing a Wait For Interrupt (WFI) instruction usually puts the CPU into a low power state. By asserting the TWI bit, if HCR_EL2.TWI==1, then executing WFI at EL0 or EL1 will instead cause an exception to EL2. In this example, the VM would usually execute a WFI as part of an idle loop. And the hypervisor can trap this operation and schedule a different vCPU instead

Figure 4. Trap Mechanism and Example of Trapping WFIs from EL1 to EL2

And in the ARM architecture, vCPU refers to virtual processing element, corresponding to vCPU thread instance for every vCPU. And virtual machine refers to the qvm process instance, which will contain one or more vCPUs.

Figure 5. ARM Virtual Machine and Virtual CPUs

3. Memory Virtualization

3.1 Memory Virtualization overview

Cooperating with CPU virtualization, the memory virtualization can ensure all the VMs have independent memory space and isolated strictly according to the authority. Therefore, the key requirement is the address management, controlling the access to physical memory by various system masters depending on contexts.

The memory virtualization is typically achieved through the combination of the memory allocation and free of hypervisor and VMs form software side with the 2-stage address translation mechanism from hardware side. The memory allocation and free mechanisms of hypervisor and VMs are both similar to this mechanism inside the typical operating system, using the page-based memory management.

3.2 ARM 2-Stage Address Translation

The 2-stage address translation mechanism is used in the ARM architecture. Typically, stage-1 translation converts virtual address (VA) to intermediate physical address (IPA), which is usually managed by the operating system. While Stage-2 translations convert the intermediate physical address (IPA) to physical address (PA), which is usually managed by the hypervisor. And the translation of these two stages is independently each other, and this can be found in the following figure, where the continuous virtual addresses can be mapped to the discrete addresses in intermediate physical pages, and discrete intermediate physical addresses can be mapped to the continuous physical addresses.

Figure 6. 2-stage Address Translation Mechanism

The following diagram shows the typical 2-stage address space of ARMv8 architecture. The three virtual address spaces include the guest OS virtual memory map in Non-secure EL0/EL1, the hypervisor virtual memory map in No-secure EL2, and the secure monitor virtual memory map in EL3. Each of these virtual address spaces is independent and has its own settings and tables. The 2-stage address translation is typically used in the virtualization, where the Stage1 guest OS tables translate virtual addresses to intermediate physical addresses, including the peripherals, memories, and storages and the Stage2 virtualization tables translate the intermediate physical addresses to physical addresses.

Figure 7. ARMv8 Typical 2-stage Address Space

In AArch64 architecture, 4-level page tables with typical 4KB/64KB page size are used in MMU to support address translation introduced above. The detailed procedure of address translation will not be introduced further in this paper.

Figure 8. AArch64 4-level Page Table & 1-stage Address Translation Example

4. Device Virtualization

4.1 Device Virtualization overview

The concept of the devices in the virtualization can be concluded as the accessible devices in the system except the processors running the hypervisor and VMs. The typical types of devices in automotive chips can be concluded as: