ADAS与IVI的虚拟化：Hypervisor硬件基础与主流软件方案

用户9732312

发布于 2026-03-18 21:08:40

460

为什么需要Hypervisor

虚拟化是一项广泛应用的技术，几乎支撑着所有现代云计算与企业基础设施。利用该技术，可在单台机器上运行多个操作系统，互不影响。虚拟化在服务器系统中备受青睐，因此大多数服务器级处理器都将其列为必备功能。这项技术能为数据中心带来以下核心优势：

•隔离性：虚拟化的核心价值在于实现同台物理设备上各虚拟机之间的相互隔离。这种隔离机制使得互不信任的计算环境能够共享物理资源。例如，两个竞争企业可以共用数据中心的同一台物理服务器，但无法访问彼此的数据。

•高可用性：虚拟化支持工作负载在物理服务器间实现无缝透明迁移。该技术常用于将工作负载从需要维护或更换的故障硬件平台转移至正常设备。

•负载均衡：为优化数据中心的硬件与能效预算，必须充分利用每台硬件设备的性能。通过虚拟机迁移或在物理服务器上协同托管适配的工作负载，可最大限度提升硬件资源利用率，既帮助数据中心运营商实现最佳能效管理，又为租户提供最优性能体验。

•沙盒环境：虚拟机可为可能影响主机系统稳定性的应用程序提供沙盒环境。典型应用场景包括遗留系统程序或尚在开发中的软件。将这些程序运行于虚拟机内，可有效防止因程序缺陷或恶意代码对物理设备上其他应用及数据造成影响。

而在汽车的EE架构中，其中央计算平台成为汽车的计算中心，该计算中心运行多种应用，如ADAS/ 智能座舱，信息娱乐、底盘/车身控制和动力系统。这些子系统对实时性，对功能安全，对计算资源的要求都不相同，而且计算中心的硬件正在向集中式单soc发展，所以在汽车的中央计算平台往往需要对硬件进行虚拟化。既是技术发展的结果也是对汽车安全性保障的需要。

Hypervisor分类

Hypervisor可为两大类别： Type 1和Type 2。

Type 1

该架构中Hypervisor不存在操作系统。Hypervisor直接运行在硬件层面上，全面掌控硬件平台及所有资源。Hypervisor之上运行虚拟机，这些虚拟机能够运行单个或多个完整的客户操作系统。如Xen/sel4等

Type 2

在该架构中，Hypervisor有操作系统，Hypervisor和其操作系统对硬件平台及其所有资源具有完全控制权。其架构示意图如下：

Hypervisor运行于Host OS系统环境内，Hypervisor通过Host OS管理硬件资源。同样Hypervisor之上运行虚拟机，这些虚拟机被称为guest操作系统。如果QNX/KVM等。

全虚拟化/半虚拟化/混合虚拟化

虚拟机的经典定义是一个独立、隔离的计算环境，且与真实物理机无从区分。虽然在基于Arm的系统上完全模拟真实机器是可行的，但这种方式通常效率低下。因此，这类完整模拟并不常用。例如，模拟真实以太网设备的性能很低，因为Guest OS对模拟寄存器的每次访问都必须由Hypervisor在软件层面处理。这种处理操作的成本远高于直接访问物理设备上的寄存器。

一种更优的替代方案是使能半虚拟化，这通常被用来提升性能。通过让Guest OS感知其运行在虚拟机中，通过修改Guest OS内核，使其与Hypervisor协同工作，使用一套专为虚拟化设计的高效抽象接口（API）进行通信。

当前主流模式：得益于CPU硬件虚拟化扩展，现代解决方案采用了一种混合架构：CPU与内存虚拟化：Guest OS内核无需修改即可高效运行，由硬件直接处理多数敏感指令，实现了近乎原生的性能。I/O虚拟化：为了达到极致的I/O性能，普遍采用半虚拟化驱动（如Virtio）。Guest OS开发专用驱动，与Hypervisor中的对应后端设备通过共享内存等优化机制通信，从而大幅降低延迟和开销。全虚拟化提供兼容性，半虚拟化追求性能。现代虚拟化技术在硬件辅助的基础上，融合了二者优势：允许未修改的Guest OS运行，同时对性能关键的I/O路径采用半虚拟化驱动，从而在保证兼容性的同时，实现了高性能的I/O。

Hypervisor的硬件解决方案

从系统架构来看虚拟化似乎是OS level的方案，然而OS是运行在HW之上，如果没有HW的支持，那么OS也无能为力。那么HW为虚拟化准备了什么？怎样设计HW，才能满足虚拟化的需求？我们以ARM64架构来说明以HW架构对虚拟化的支持。虚拟化的作用是让VM看起来运行在一个独立的硬件之上，VM相互独立，而又能使用所有的硬件资源。

Exception 架构

ARM虚拟化扩展基于其安全扩展（通常称为TrustZone）实现。ARM架构通过不同的异常级别来处理对硬件的访问。当前的特权级别只有在处理器捕获异常或从异常返回时才能改变。ARM有四个异常级别：EL0、EL1、EL2和EL3。架构并未规定什么软件使用哪个异常级别。一个常见的应用模型是：应用程序代码运行在EL0，操作系统运行在EL1。虚拟化程序运行在EL2，安全相关程序运行在EL3。

其分层设计的原则是特权与隔离。异常级别切换规只能通过特定事件改变：特权级别不是随意变化的，只有发生异常（如系统调用、中断、页错误）、异常返回或复位等事件时才会改变。捕获异常（如发生中断或执行SVC指令）：程序流从低特权级跳转到相同或更高的特权级代码执行（例如，从EL0的应用程序通过系统调用进入EL1的内核）。返回异常（如执行ERET指令）：程序流从高特权级返回到相同或更低的特权级（例如，从EL1的内核处理完系统调用后返回到EL0的应用程序）。

在arm的架构中，程序在同一个时刻只能运行在一个异常级。如果要完成异常的跃迁，就需要通过特定的function all，trap到下一级。User space/kernel space就是常见的例子，User space(EL0)的程序（App）通过SVC调用（Supervisor Call）也称为系统调用，陷入到kernel space（EL1），使用kernel的service或API为APP服务。相似的，kernel space通过 HVC（Hypervisor Call）调用Hypervisor(EL2)的service为自己服务。而Hypervisor（EL2）和APP(EL0)通过SMC(Secure Monitor Call) 使用TEE（EL3）的service。

Stage 2 translation

为什么在ARM64的Hypervisor架构中需要Stage 2 translation？我们知道现代的OS为每个应用程序提供一个独立的、私有的虚拟地址空间。在程序访问数据时是通过虚拟地址访问物理地址来访问物理内存的内容。而虚拟地址是通过操作系统内核（在ARM架构中运行于EL1）进行虚拟地址和物理地址的转换来获取相关的物理地址。而这个虚拟地址到物理地址的转换称为Stage 1 translation，由OS 负责。在有Hypervisor和多gest OS的情况下，还需要对 stage 1 translation转换后的IPA进行第二阶段转换。这样确保一个虚拟机只能看到分配给它的资源，而不能看到分配给其他虚拟机或超级管理器本身的资源。

操作系统控制着stage 1 转换。Stage1 转换时将虚拟地址空间映射到它所以为的物理地址空间。然而，这个转换过程还会经历第二次转换，才进入真实的物理地址空间。这第二次转换由超级管理器控制。

每个虚拟机都被分配一个虚拟机标识符。该VMID用于标记转译后备缓冲器中的表项，以标识每个表项属于哪个虚拟机。这种标记允许多个不同虚拟机的转换表项同时存在于TLB中。

VMID存储于VTTBR_EL2寄存器中，其长度可以是8位或16位。VMID的长度由VTCR_EL2.VS位控制。对16位VMID的支持是可选的，并在Armv8.1-A架构中引入。

第二阶段地址转换使得超级管理器能够控制虚拟机中的内存视图。具体来说，它允许超级管理器控制虚拟机可以访问哪些内存映射的系统资源，以及这些资源出现在虚拟机地址空间中的位置。这种控制内存访问的能力对于隔离和沙箱至关重要。

System Memory Management Units

在虚拟化中，当虚拟机中的驱动程序试图直接访问一个物理设备时，会带来两个严重问题：

隔离性被破坏：物理设备（如DMA控制器）通常拥有直接访问物理内存的能力。如果虚拟机可以随意操控DMA，它就可以指令DMA读取或写入任何物理内存地址，包括其他虚拟机或Hypervisor的内存，从而攻破沙箱。
内存视图不一致：虚拟机操作系统使用中间物理地址，而物理设备默认操作的是真实物理地址。驱动程序在虚拟机中准备了一个位于

IPA的缓冲区，但直接告诉DMA控制器后，DMA会找不到正确的数据，因为它在不同的PA空间里操作。

“陷入并模拟”是一种解决方案，即Hypervisor拦截虚拟机对设备的每一次访问，然后由软件模拟该操作。但这种方法性能开销很大。

SMMU提供了一种更高效、根本的解决方案。其核心思想是：将CPU的虚拟内存保护机制扩展到系统的其他主设备上。SMMU是一个硬件单元，位于系统总线上，它就像一个“设备的MMU”。当设备（发起者）试图访问内存时，它发出的地址（通常是IPA或VA）会先经过SMMU。SMMU查阅由Hypervisor配置的转换表（Stage 2 表），将这个设备发出的地址转换为正确的物理地址。同时，SMMU会检查该设备是否有权限访问该内存区域（例如，是否是只读的），如果没有权限，则阻止访问并报告错误。

Hypervisor为每个虚拟机维护独立的SMMU转换表。当分配给VM1的DMA控制器发起访问时，SMMU使用VM1的转换表。这张表规定DMA只能访问映射给VM1的那部分物理内存。即使VM1中的恶意驱动程序指令DMA去访问一个属于VM2的IPA，SMMU在查询VM1的转换表后，要么将其转换为VM1自己的物理内存范围，要么因找不到有效映射/权限不足而拒绝访问。Hypervisor为SMMU编程的转换表，与为对应虚拟机的CPU编程的Stage 2转换表是协调一致的。这意味着，虚拟机内的CPU 和分配给它的DMA控制器看到的是同一个IPA -> PA的映射关系。

virtual interrupts

在没有虚拟化的情况下，物理中断会直接发送到操作系统内核（EL1）。在虚拟化的情况下，如果物理中断直接发送给虚拟机，Hypervisor就失去了对设备的控制，并且虚拟机可能看到不应该它访问的硬件信息。在ARM虚拟化中，Hypervisor如何向虚拟机注入中断有两种技术路径，其核心是在性能和实现复杂度之间的权衡。

软件模拟方式

所有物理IRQ都将被重定向到Hypervisor (EL2)。Hypervisor 成为了中断的“总调度”，它可以决定是否将一个物理中断转化为虚拟中断传递给特定的虚拟机。

通过 HCR_EL2 寄存器来控制IRQ的行为。HCR_EL2寄存器是Hypervisor寄存器主要是定义trap到EL2的各种操作。

Hypervisor通过设置 HCR_EL2 中的 VI（虚拟IRQ）、VF（虚拟FIQ）或 VSE（虚拟系统错误）位来“拉高”一个虚拟中断信号。当一个物理中断发生，陷入到 EL2 的 Hypervisor后，Hypervisor判断这个中断应该由哪个虚拟机处理。

Hypervisor设置目标虚拟机的 HCR_EL2.VI、VF 或 VSE 位。 ARM硬件自动检查该虚拟机的PSTATE 中的中断掩码位（如 I 位用于 IRQ），如果未被屏蔽，则将中断交付给虚拟机内核（EL1）。当vCPU 在 EL1 运行时，这些位会导致虚拟中断被触发。该方案实现简单、灵活，无需特定硬件支持。致命缺点：性能开销大。Hypervisor 需要为虚拟机完整地模拟一个中断控制器。虚拟机操作系统对中断控制器的每一次访问（如读取中断ID、确认中断结束EOI）都可能是一次“陷入”，需要 Hypervisor 用软件来模拟，这导致了频繁的上下文切换和大量的软件开销。

GIC HW

从GICv2开始，中断控制器在硬件上提供了两套独立的 CPU 接口：一套给物理机，一套给虚拟机。这两个接口功能完全相同，但虚拟CPU接口是专门用于向虚拟机注入虚拟中断的。Hypervisor 启动时，将虚拟CPU接口的寄存器映射到虚拟机的地址空间。当需要向虚拟机注入一个虚拟中断时，Hypervisor通过配置 GIC 的列表寄存器等结构，将中断信息（如ID）写入硬件GIC。

GIC硬件会通过其虚拟CPU接口，直接将这个虚拟中断信号发送给对应的虚拟CPU。虚拟机中的操作系统可以直接访问这个映射过来的虚拟CPU接口，进行读取中断ID、发送EOI等操作，而完全不需要 Hypervisor 的介入。虚拟机对中断的大部分操作现在都是与硬件直接交互，避免了陷入到 EL2。Hypervisor 不再需要模拟中断控制器的行为，只需进行初始的配置和管理。这极大地降低了中断虚拟化的延迟和CPU开销,大幅提升性能。

virtual timer

我们知道，在SoC级别有一个系统计数器，所有CPU核心共享的公共、持续递增的硬件计数器。它像一個永不停止的挂钟，记录着自系统启动以来的物理时间（纳秒或时钟周期数）。每个CPU都有自己的一套比较器。当软件（如操作系统）设置一个未来的时间点（例如，当前系统计数值 + 1000000），当系统计数器的值达到或超过这个设定值时，比较器就会产生一个计时器中断给对应的CPU。

在虚拟化环境中，多个vCPU可能分时共享同一个物理CPU。如果一个vCPU设置了其物理计时器在3毫秒后中断，但它只在物理CPU上累计运行了2毫秒就被调度出去了，那么当中断发生时，它可能并不在运行状态。这会导致：计时不准：vCPU感知到的时间流是不连续的。中断丢失或延迟：中断可能在不恰当的时机被触发，影响虚拟机内操作系统的正确性和性能。为了解决这个问题，ARM架构为vCPU提供了两种不同的计时器:EL1 物理计时器, 反映真实的、不间断的挂钟时间。适用于需要与真实世界时间同步的任务（例如，网络协议栈中的超时处理）；EL1 虚拟计时器,反映vCPU实际消耗的CPU时间。这是实现时间虚拟化的核心机制。

Hypervisor为每个vCPU维护一个软件状态，记录其“虚拟时间”的进度。当调度一个vCPU到物理CPU上运行时，Hypervisor会计算并设置该物理CPU的偏移量寄存器。Hypervisor通过动态调整这个偏移量，可以“欺骗”vCPU，让它看到的虚拟时间只在自己被调度运行时才递增。

ARM通用计时器的虚拟化通过引入虚拟计时器和偏移量寄存器，巧妙地解决了虚拟化环境中的时间问题。它允许Hypervisor向每个vCPU呈现一个独立的、只反映其自身CPU消耗的虚拟时间流，从而确保了虚拟机内操作系统的计时准确性和系统稳定性。这是构建高性能、可预测的虚拟化系统的重要组成部分。

Hypervisor的软件解决方案

汽车行业正在经历其历史上最快速的转型。消费者需求、法规要求、技术进步以及电动和联网汽车的普及交汇融合，带来了对该领域的全面重塑。开发真正自动驾驶汽车正在推动行业采用云、人工智能和高性能计算等领域的技术，这些技术将在短期内乃至未来赋能创新的驾驶功能。软件将继续成为行业最大的游戏规则改变者，因为它定义了车辆及其背后的品牌。然而，所有汽车细分领域向软件定义汽车的迈进既带来了挑战，也带来了机遇。虚拟化正迅速成为现代车辆软件架构中的一项关键技术。通过高度集成实现成本节约，推动了在同一片上系统上安全可靠地共存多个操作环境的需求。这通过虚拟化来实现。

宏内核与微内核

对内核而言，可以分为宏内核和微内核。

宏内核

上图左边展示宏内核的架构（Linux）。黄色部分是操作系统内核，它为应用程序提供文件存储/网络/内存管理等服务。实现这些服务的所有代码都在特权模式下执行，也称为内核模式或超级用户模式——这种执行模式对系统中的所有资源具有无限制的访问和控制权。相比之下，应用程序在非特权的用户模式下运行，没有对许多硬件资源的直接访问权，这些资源必须通过操作系统访问。对linux而言就是user space和kernel space。操作系统在内部由多个层次构成，每一层提供由下层实现的抽象。

对宏内核而言，特权模式代码是危险的：如果特权代码出了问题，对系统的损害无疑是巨大的，如果在linux kernel中运行的代码，经常发生kernel panic。另外，如果此代码存在一个可以被攻击者利用来在特权模式下运行攻击者代码的缺陷，那么攻击者就可以对系统为所欲为。此类缺陷是我们在主流系统中经历的许多系统被攻破的根本问题。如大家所熟知的CVE，需要不断在linux系统中打上CVE的patch。

微内核

微内核设计的初衷是"最小特权原则"——内核只做最基础、最必要的事情，其他所有功能都作为独立的用户态服务运行。微内核本身只包含：进程调度 - 决定哪个进程运行；进程间通信 - 服务的通信机制（微内核的生命线）；虚拟内存管理 - 地址空间和页面管理；基本的线程/进程管理 - 创建、销毁、切换；最小的硬件抽象 - 少数必要的设备驱动。移出内核的功能（作为用户态服务）：文件系统 - ext4/f2fs/ NTFS 等作为独立服务;网络协议栈 - TCP/IP 实现作为服务;设备驱动 - 显卡、声卡、USB 等驱动;安全管理器 - 权限控制策略;GUI显示服务等。

这样的设计减少对系统的攻击和提高系统的健壮性。上图右侧展示了微内核架构示意，其在特权模式下执行的部分，要小得多。在一个设计良好的微内核中，例如seL4，它大约是一万行源代码的量级。这比Linux内核小了整整三个数量级，攻击面也相应缩小。

微内核几乎不提供服务：它只是硬件的一个薄包装层，刚好足够安全地复用硬件资源。微内核主要提供的是隔离，即沙箱，程序可以在其中执行而不受其他程序干扰。

微内核系统使用PPC（protected procedure call）机制来提供宏内核操作系统在内核中实现的服务。PPC机制允许一个程序安全地调用另一个不同程序中的函数，其中微内核在程序之间传递函数输入和输出，并且，重要的是，强制执行接口：只有被授权的客户端（已获得相应能力）才能在导出的入口点调用“远程”（位于不同沙箱中）函数。

在微内核世界中，这些服务只是程序，与应用程序无异，它们运行在自己的沙箱中，并提供一个PPC接口供应用程序调用。如果某个服务器被攻破，该攻破被限制在该服务器内，其沙箱保护系统的其余部分。这与宏内核情况形成鲜明对比，在宏内核中，一个操作系统服务的攻破会导致整个系统的攻破。

在type1 的Hypervisor架构中，大都选择微内核作为Hypervisor。

在微内核base虚拟化的方案中，其软件架构通常分为如下部分：

VM 监控和基础serivce。一个VMM（VM监控）对应一个VM，基础service包含系统的基础服务和Hypervisor相关的service。理想情况下，在 Hyp 模式下运行的核心进程部分仅包含Hypervisor程序特定的代码。这包括在不同虚拟机之间切换的代码。为了尽可能保持低复杂度，Hypervisor应当避免包含任何设备模拟代码。如果可能，其功能应仅限于重载通用寄存器和系统寄存器，以及管理客户物理地址到主机物理地址的内存转换。VMM 是一个运行在非特权模式下的普通应用程序，并且为每个虚拟机单独实例化。通过为每个VM 实例化一个 VMM，不同的 VM 之间可以很好地隔离。即使一个 VMM 出现故障，其他 VM 也不会受到影响。当然，一个普通的用户态应用程序不能直接使用硬件虚拟化扩展。这些扩展仅在 Hyp 模式下可用，而该模式是内核独占的。
VM.VM运行在EL0/EL1

VM创建和启动

中断虚拟化

Device Passthrough

QNX

QNX Hypervisor 利用最新的 AArch64（包括 ARMv8 和 ARMv9）和x86-64 硬件虚拟化扩展，使开发人员能够将不同的操作系统（例如 QNX、Linux 和 Android）和混合关键性功能集成到单个 SoC 上，同时保持性能、分离和隔离。

QNX Hypervisor 特性

Type 1 虚拟机管理程序
安全认证血统
虚拟 CPU 模型
基于优先级绑定核心或共享核心
自适应分区。保证客户机运行时的 CPU 资源
支持 64 位和 32 位客户机：QNX、Linux、Android、RTOS
带触发功能的共享内存
VirtIO (1.0) 设备共享
TAP 和对等网络（支持桥接）
客户机故障检测与重启
用于客户机完整性检查的虚拟看门狗
低开销（通常 < 2%）
用于分析和调试的图形化工具

QNX Hypervisor 遵循基于优先级的虚拟 CPU 共享模型。每个 vCPU 都有优先级和调度策略，确保当共享一个物理 CPU 时，优先级更高的客户机操作系统将始终抢占优先级较低的客户机操作系统。vCPU 的过额订阅允许系统设计者最大化利用所有核心。此外，可以将一个 vCPU 绑定到一个 pCPU，并赋予对该核心的独占访问权。可以使用 QNX Adaptive Partitioning 为 vCPU 分配 CPU 预算。这种分区机制即使在系统完全繁忙时，也能为一组 vCPU 强制执行有保证的 CPU 时间。vCPU 绑定和浮动的这种灵活性使系统设计者能够构建可靠的系统，而不会浪费硬件资源。

在使用虚拟机管理程序的嵌入式系统中，通常期望对某些设备拥有独占访问权，同时在客户机之间共享其他设备。共享可以节省成本、减少开发时间并提高运营效率。客户机操作系统可以混合使用多种硬件接口：模拟设备（如定时器和串行端口）、硬件直通驱动程序（例如 CAN 总线驱动程序）以及用于共享以太网和基于块的文件系统设备的行业标准 VirtIO驱动程序。客户机操作系统通过共享内存和对等以太网连接进行通信。客户机操作系统按需启动、移除、暂停和重启，并通过内置的监控和故障处理服务进行管理。

Sel4

seL4是一个世界上首个被形式化验证的、基于微内核架构的高安全实时操作系统。其名称源自 “secure embedded L4”，意指其作为L4微内核家族的一员，专为对安全性和可靠性有极端要求的嵌入式及关键任务系统而设计。

形式化验证是seL4最根本的革命性特征。它不仅仅通过了传统测试，而是通过机器检查的数学定理证明了其内核实现（C和汇编代码）完全符合其高层抽象规范。这意味着：

功能正确性证明：内核行为严格且完全符合其设计规范，无未定义行为。

安全属性证明：内核强制实施了完整性（防止未授权信息篡改）和机密性（防止未授权信息泄露）的安全模型。具体而言，它证明了基于能力的访问控制系统是完备且不可绕过的。

不存在经典软件缺陷：在已验证的代码范围内，理论上不存在缓冲区溢出、空指针解引用、竞态条件等可能导致崩溃或漏洞的经典编程错误。

信任根极小化：系统的可信计算基被缩减到经过数学证明的微内核本身，极大降低了受攻击面和验证成本。

高性能微内核

最小化内核：seL4内核仅提供最基础的原语，如线程管理、进程间通信、虚拟内存管理和中断处理。所有其他服务（文件系统、网络协议栈、设备驱动等）均作为独立的、运行在用户态的服务进程实现。

基于能力的访问控制：系统的所有资源（内存页、IPC端点等）均封装为能力。任何组件要访问资源，必须持有对应的能力，且内核是唯一能创建和授权能力的实体。这为构建强隔离的组件提供了坚实的基础。

实时性：其设计确保可预测的、确定性的响应时间，满足硬实时系统的要求。

关键优势

无与伦比的保证级别：为系统核心提供了目前最高级别的正确性与安全保障。

强大的安全隔离：能够将不同关键等级或可信等级的组件严格隔离，防止一个组件的故障或被入侵波及其他组件。

高可靠性：内核本身的极高正确性为整个系统提供了稳定基石。

适用于安全苛求领域：是航空航天、国防、汽车（尤其是自动驾驶）、医疗设备、工业控制等生命攸关或高价值系统的理想基础。

AGL Xen Hypervisor

ACRN

EB tresos Embedded Hypervisor

EB tresos Embedded Hypervisor是一个用于实时应用的分离内核。它在单个微控制器上执行多个虚拟机，并利用现代微控制器的虚拟化特性，允许多个操作系统和AUTOSAR软件栈实例在单个MCU上并行执行。EB tresos Embedded Hypervisor专为部署混合关键性应用而设计。主

要特性包括：

混合关键性应用：在隔离的VM中整合质量管理应用和安全关键应用，确保虚拟机间的免于干扰。

高效通信：通过共享内存提供虚拟机间的受控通信，独立于客户机操作系统。

资源优化：通过将具有实时性要求的VM分配给专用核心，同时与其他VM共享其他核心，充分利用Arm Armv8-R架构核心的计算能力。

成本与资源节约：在单个ECU上部署多个应用，可降低成本、线束、重量和能耗。

遗留应用集成：将遗留ECU迁移到虚拟机中所需改动极小。

此外，为确保虚拟机间的免于干扰，EB tresos Embedded Hypervisor还通过共享内存技术提供虚拟机间受控、高效的通信，同时保持独立于客户机操作系统和裸机应用。

图1展示了EB tresos Embedded Hypervisor如何允许将VM分配给Arm Cortex-R52+核心。集成者可以选择是否将VM固定分配给核心（左侧两个虚线框），或者是否让其与其他VM共享核心（右侧虚线框）。固定分配的核心避免了调度开销，因此有利于包含实时性要求应用的VM，这些应用不容许有VM调度开销。

共享核心的VM以时分复用的方式最大化核心利用率，前提是所有VM的利用率加上调度开销不超过核心可用的计算能力。

A diagram showing Independent binaries and controlled communication.

图2显示每个VM都是一个独立的二进制文件，可以独立地进行刷写和覆盖。以前，更新一个应用软件簇需要为整个ECU上传一个巨大的二进制文件。而现在，使用实时嵌入式虚拟机管理程序后，只需上传包含该软件簇的VM即可。此外，这些VM可以由不同的团队独立构建和集成，减少了位于不同时区和地点的软件团队之间协调的开销。

Elektrobit集成HSM

许多实时软件应用依赖于密码学扩展，例如密钥管理。这些密码服务通过硬件安全模块提供，Elektrobit有一个名为EB zentur的专用产品来支持和提供这些服务。当需要在运行于EB tresos Embedded Hypervisor之上的多个VM中集成多个应用时，需要协调对HSM的访问。

A diagram showing Static & Dedicated ACM

图3展示了两个共享HSM的VM及其应用软件簇。该图经过简化，显示了应用通过代理模块和与HSM的共享内存区域进行通信的路径。EB tresos Embedded Hypervisor的总线分离模块由集成者以静态方式配置，从而以隔离的方式授予VM对HSM模块的读写权限。

虚拟机vs. AUTOSAR CP软件簇

不要被一个常见的误解所误导，即认为AUTOSAR CP软件簇和基于虚拟机管理程序的虚拟化是竞争技术。它们是互补的，服务于不同的用例。看到AUTOSAR CP软件簇实现被部署在EB Embedded Hypervisor之上的VM内部，并不令人惊讶。

在下表中，我们总结了两项技术的对比

QCOM和NVDIA solution

QCOM solution

高通在其座舱使用QNX作为虚拟机，在开源社区我们看到高通也在开发Type-1的虚拟机Gunyah™。

Gunyah 是高通推出的开源 Type-1 虚拟机管理程序，其构建在电池受限设备上高度关注安全与性能。它被设计成一个轻量级、通用的微内核，仅包含管理虚拟机所需的最基本功能。可以在汽车、移动宽带、物联网和可穿戴设备等多种用例中使用同一虚拟机管理程序。

该架构支持多个操作系统，并包含一个资源管理器：

资源管理器（RM）是一个运行在执行等级1中的虚拟机，与 EL2 中的核心Gunyah 虚拟机管理程序紧密协作。RM 实现了管理虚拟机所需的部分策略，例如创建和启动虚拟机的繁重工作。它是虚拟机管理程序在不同执行级别中的一个集成组件。

受保护与未受保护的虚拟机，承载某些机密/敏感工作负载的受保护虚拟机一直是 Gunyah 从开始以来的主要关注点。我们不希望移动设备上的 Android 处理诸如人脸认证或移动银行凭据验证等敏感任务。因此，在应用程序的该阶段，对显示屏、触摸屏或摄像头的控制可以转移至一个受保护虚拟机中，在该虚拟机内验证敏感信息。之后，应用程序的其余部分可以在 Android 中运行。

Gunyah 支持两种主要类型的 VM：

受保护型：主机无法访问该VM 的内存。

未受保护型：主机可以完全访问该VM 的内存。

此外，还有两种类型的受保护 VM：

高通可信虚拟机 – 其主要执行映像使用高通工具签名的VM。虚拟机管理程序确保在允许VM 启动之前，加载到内存中的 VM 映像会由高通的安全软件 Trustzone 进行验证。除了内核和可能的初始内存盘外，VM 的执行映像包含一个设备树，该设备树可以指定 VM 需要访问的设备。这种静态 DT 意味着 VM 的某些资源（如内存量和 VCPU 数量）本质上是静态的。

Google VM – 由 Android 虚拟化框架定义的 VM。在这种情况下，虚拟机管理程序不强制执行 VM 映像身份验证。相反，身份验证由 PVM 固件执行，该固件是在 VM 内核接管之前在 VM 中运行的软件二进制文件。在这种情况下，VM 使用的 DT 是动态的；即在运行时生成。

Gunyah 特性

受保护 VM 的内存是其私有的，其主机无法访问。这是通过虚拟机管理程序利用 CPU 基于页表的内存保护功能实现的。虚拟机管理程序会修改与主机操作系统关联的第二阶段页表，从而使主机失去对 VM 内存的访问权限。当然，在某些情况下，可能需要在受保护VM 与其主机之间共享内存。但截至目前，Gunyah 尚未向受保护 VM 提供任何 API 来将其部分私有内存与主机共享。相反，主机可以分配其部分内存供 VM 在共享或私有模式下使用，这需要在 VM 开始执行之前完成。例如，作为 VM 创建过程的一部分，主机可以分配 500 MB 的内存供 VM 私有使用，并分配 100 MB 的内存供共享使用。

利用系统内存管理单元来防范恶意设备。例如，分配给主机的设备无法使用直接内存访问来访问受保护 VM 的内存。与设备关联的 SMMU 中的第二阶段页表将被设置，使得设备在访问受保护 VM 的内存时会产生故障。

通用中断控制器在虚拟机管理程序层 EL2 实现了虚拟化。

支持 VCPU 的代理调度和本机调度两种方案。在代理方案中，主机调度器智能地处理 VCPU 调度。主机调度器可能拥有高级算法，可以同时改善 VM 的性能和功耗。在本机方案中，虚拟机管理程序调度器直接处理 VCPU 调度，这对于某些关键 VM 可能是可取的。

VM 中间物理地址空间的第一个 GB 可用作内存映射 I/O 区域，可以被捕获和模拟。

在系统热复位后，受保护 VM 的内存会被清理。热复位可能因各种原因触发，例如主机操作系统发生死锁时。在某些平台上，热复位后，内存内容会保留，其中可能包括复位时处于活动状态的受保护 VM 的数据。为了防止主机操作系统在重新启动时访问此类数据，Gunyah 会安排由 Trustzone 软件（在热复位后早期运行）来清理 VM 的内存。

Gunyah 支持预主机VM，这些 VM 可以在启动序列的早期由 UEFI 固件启动（甚至在主机操作系统开始启动之前）。这对于需要在启动早期就具备功能且不能等到主机启动完成的 VM 非常有用。

为了允许 VM 之间相互通信，虚拟机管理程序支持共享内存、门铃和消息队列。

Gunyah 现在支持按需分页。以前，如果你想启动一个需要 500 MB 内存的 VM，在Gunyah 开始执行 VM 之前，必须分配并锁定全部 500 MB。但如果 VM 只需要 100 MB 就能良好运行，那么内存就被浪费了。因此，我们在虚拟机管理程序中添加了对按需分页的支持，以实现更好的内存管理。现在，当 VM 访问一个尚未分配的有效页面时，会产生一个故障并通知主机，主机会分配一个大小不等的页面，并由虚拟机管理程序映射到 VM 中。设备直通允许将某些设备分配给 VM 并直接访问。我们正在针对汽车、物联网和移动设备用例优化 Gunyah。

高通正在积极开发的 Gunyah 驱动已接近被上游 Linux 内核社区接受。如下图所示，该驱动旨在使像 CrosVM 和 QEMU 这样的VMM 能够管理 Gunyah 虚拟机管理程序上的虚拟机：

NVDIA solution

NVDIA DRIVE AGX X平台的基础服务运行时软件栈为平台所有组件提供了底层支撑架构。依托此架构，客户操作系统得以在硬件上运行，并由虚拟机监控程序统一管理硬件资源的使用。其软件架构如上图所示。其软件架构分为Guest OS/Foundation/Hypervisor/bootloader TOS/SOC.

Hypervisor

Hypervisor是微内核架构，系统划分为多个分区，每个分区可运行独立操作系统（Guest OS）或裸机应用程序（Foundation service）。Hypervisor负责管理：