上篇文章：汽车电子架构演进（五）-三域融合之“三国杀”，随着EEA（汽车电子电气架构）的发展，关于域融合的话题也比较多，其中除了硬件芯片集成的发展，另一方面就是Hypervisor虚拟机。

目前在分散的三域中有很多OS，例如，汽车仪表系统与信息娱乐系统：汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，如QNX操作系统；而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，如Linux和Android操作系统。所以在未来集中式架构中，不同处理优先级和不同安全等级要求的应用程序将被高度集成在中央计算单元中，软件复杂度比传统车载软件要超出1-2个量级，对汽车安全性的要求也大大提升。

虚拟化（Hypervisor）解决方案提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。

之前有一篇文章：电源管理入门-20 Hypervisor中的电源管理基本把Hypervisor讲清楚了，这里我们再回顾下其基础知识，然后再进行补充一下在汽车域融合中的应用。

1. Hypervisor介绍

1.1 Hypervisor分类

虚拟机管理器，又称Hypervisor ，也称为虚拟机监控程序（VMM）,其处于SoC 硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源，按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。

Hypervisor实现了硬件资源的整合和隔离，使应用程序既能共享CPU等物理硬件，也能依托不同的内核环境和驱动运行，从而满足现代复杂软硬件系统多元化应用场景需求。目前，通常使用两种类型的管理程序：

Type 1 :裸机虚拟机管理程序：一种在硬件上本机运行的管理程序。

Type 2 :托管虚拟机监控程序：此类型的虚拟机监控程序必须由另一个操作系统托管，并且仅负责使用主机操作系统可用的资源来虚拟化客户操作系统。

我们在大SoC+域融合场景下使用的就是Type 1的模式，Hypervisor直接运行是硬件上，向上层OS提供服务。

VMM首先需要对CPU、内存、中断等资源进行管理，并提供对应虚拟化功能；按照I/O设备驱动的布局，又可以分为Hypervisor模型和混合模型；

Hypervisor模型： VMM设备驱动提供物理设备驱动管理，并向上提供服务；

混合模型： VMM只提供必要的CPU资源管理，由Guest Server OS提供设备管理和虚拟化服务。

参考Hypervisor模型：QNX

参考混合模型：代表有

Xen，

Intel的Acrn，

以及国内的minos，

和bao-hypervisor

1.2 ARM上的位置

Type 1的Hypervisor向上面的OS提供服务，但是OS之下是各种固件，那么Hypervisor在这一堆固件中的位置在哪里，这涉及到具体的代码实现。首先参考上图中ARM异常等级，及安全世界和非安全世界的划分：

EL0：非安全态的Apps，安全态的Trusted Apps，EL0是无特权模式，所有APP应用都在EL0。

EL1：非安全态的Normal world OS，安全态的Trusted OS ，EL1是一个特权模式，能够执行一些特权指令，用于运行各类操作系统：

EL2：Hypervisor虚拟层：

EL3：Secure Monitor，Arm trusted firmware安全固件，EL3具有最高管理权限，负责安全监测和Secure World和Normal World之间的切换。

EL0 => EL1: SVC (system call)

EL1 => EL2: HVC (hypervisor call)

EL2 => EL3: SMC (secure monitor call)

在ATF（ARM底层固件）中，Hypervisor的位置如下：

可见Hypervisor在BL31（ATF）之上，所以OS的SMC系统调用请求是先陷入Hypervisor，如果Hypervisor处理不了再去BL31的。

2. 汽车中的应用

为什么汽车中迫切需求Hypervisor？

汽车上有三个域：车身域、座舱域、智驾域。也就是说有三个OS运行在复杂的SoC上。在域融合的同时，要保证关键业务的安全可靠，也要考虑应用生态的可持续性兼容，这就需要有资源隔离技术来支撑在同一 SOC 上切分资源，可并发运行多种操作系统，保障互不干扰。基于安全和资源隔离的需求需要Hypervisor。

2.1 资源分配隔离

Hypervisor处于 SoC 硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源，按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。

Hypervisor 实现了硬件资源的整合和隔离，使应用程序既能共享 CPU 等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域多元化应用场景需求。

资源隔离技术有很多，为什么是Hypervisor？

资源隔离技术有多种，从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好，单隔离域的性能、安全可靠性最好，但灵活性、可配置性差，不能实现硬件共享，导致整个系统的资源利用率差，不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离，但还是在同一个操作系统内，存在着资源干扰、相互安全攻击的隐患，并且无法支持异构操作系统业务域融合，影响传统业务继承，不利于生态发展。在众多的资源隔离技术中，虚拟化是安全可靠、弹性灵活的优选方案，是软件定义汽车的重要支撑技术。

Hypervisor的特点：

隔离：VM之间资源隔离

资源共享：VM间资源更新

负载均衡：根据VM对资源使用情况，动态调配供给

高可用：VM与硬件解绑，硬件出问题时，VM可以迅速迁移到其他硬件

弹性伸缩：根据业务情况，开关不同的VM

这里汽车上，主要使用隔离和资源共享功能。

在汽车领域，Hypervisior 主要完成以下任务：

CPU虚拟化：为虚拟机提供 VCPU 资源和运行环境；

内存虚拟化：负责为其自身和虚拟机分配和管理硬件内存资源；

中断虚拟化：发生中断和异常时，按需将中断和异常路由到虚拟机进行处理；

虚拟机设备模拟：根据需求创建虚拟机可以访问的虚拟硬件组件；

硬件支持 BSP：提供 Hypervisor 在 SoC上运行的板级支持包，如串口驱动；

虚拟机资源配置：对虚拟机的 CPU，内存，IO 外设等资源进行配置和管理；

虚拟机通信：为虚拟机提供 IPC，共享内存等通信机制。

虚拟机调度：为虚拟机提供优先级和时间片等调度算法；

虚拟机生命周期管理：创建，启动和停止虚拟机；

虚拟机调测服务：提供控制台，日志等调试功能；

2.1.1 CPU虚拟化

VM管理：VM都是运行在CPU上的，所以Hypervisor对vCPU的管理就可以管理VM的生命周期了。一个VM在Hypervisor中类似一个进程，有自己的页表空间和IPA空间，其可以有别的VM创建，也可系统启动静态配置拉起。

vCPU的管理：首先就是虚拟CPU和物理CPU的绑定策略。对于车控这种安全要求高的系统，在Hypervisor上尽量分配静态的资源，例如进行绑核处理，这样就有了专用核硬件，保证资源专用充足，从而实现实时性需求。

Hypervisor的陷入管理: VM主动HVC、SMC trap进入Hypervisor，或者异常缺页、特权寄存器访问的情况陷入

vCPU上下文：主要就是CPU的寄存器

例如，正常我们在执行WFI指令时会使CPU进入一个低功耗的状态，但是对于HOST OS来说，如果让CPU真正进入低功耗状态，显然会影响其他VM的运行。如果我们配置了HCR_EL2.TWI==1时，那么Guest OS在执行WFI时就会触发EL2的异常，然后陷入Hypervisor，那么此时Hypervisor就可以将对应VCPU所处的线程调出出去，将CPU让给其他的VCPU线程使用。

2.1.2 内存虚拟化

内存虚拟化的目的是给虚拟客户机操作系统提供一个从0开始的连续的地址空间，同时在多个客户机之间实现隔离与调度。

arm主要通过Stage 2转换来提供对内存虚拟化的支持，其允许Hypervisor控制虚拟机的内存视图，而在这之前则是使用及其复杂的影子页表技术来实现。Stage 2转换可以控制虚拟机是否可以访问特定的某一块物理内存，以及该内存块出现在虚拟机内存空间的位置。这种能力对于虚拟机的隔离和沙箱功能来说至关重要。这使得虚拟机只能看到分配给它自己的物理内存。为了支持Stage 2 转换， 需要增加一个页表，我们称之为Stage 2页表。操作系统控制的页表转换称之为stage 1转换，负责将虚拟机视角的虚拟地址转换为虚拟机视角的物理地址。而stage 2页表由Hypervisor控制，负责将虚拟机视角的物理地址转换为真实的物理地址。虚拟机视角的物理地址在Armv8中有特定的词描述，叫中间物理地址(intermediate Physical Address, IPA)。

stage 2转换表的格式和stage 1的类似，但也有些属性的处理不太一样，例如,判断内存类型 是normal 还是 device的信息被直接编码进了表里，而不是通过查询MAIR_ELx寄存器。

2.1.3 中断虚拟化

中断从设备发送到CPU需要经过中断控制器，现代x86架构采用的中断控制器被称为APIC(Advanced Programmable Interrupt Controller)。APIC是伴随多核处理器产生的，所有的核共用一个I/O APIC，用于统一接收来自外部I/O设备的中断，而后根据软件的设定，格式化出一条包含该中断所有信息的Interrupt Message，发送给对应的CPU。

每个核有一个Local APIC，用于接收来自I/O APIC的Interrupt Message，内部的时钟和温控中断，以及来自其他核的中断，也就是IPI(Inter-Processor Interrupt)。

在虚拟化环境中，VMM需要为guest VM展现一个与物理中断架构类似的虚拟中断架构。每个虚拟CPU都对应一个虚拟的Local APIC，多个虚拟CPU共享一个虚拟的I/O APIC。

和虚拟CPU一样，虚拟的Local APIC和虚拟的I/O APIC都是VMM维护的软件实体（以下统称虚拟中断控制器）。中断虚拟化的主要任务就是实现下图描述的虚拟中断架构，包括虚拟中断控制器的创建，中断采集和中断注入。

2.1.4 IO虚拟化

I/O设备作为一种外部设备，其虚拟化的实现相较于前面的CPU虚拟化及内存虚拟化有些不同，其目前主要有以下四种虚拟化方案。

1、 设备模拟：

在虚拟机监控器中模拟具体的I/O设备的特性，例如qemu。在KVM和qemu的组合中通过Hypervisor捕获Guest OS的I/O请求交给用户空间的qemu进行模拟，然后将结果再通过Hypervisor传递给Guest OS。这种方式能够提供非常好的兼容性但是性能太差，同时模拟设备的功能特性支持不够多。

2、 前后端驱动接口

在Hypervisor和Guest OS之间定义一种权限的适用于虚拟机的交互接口，比如virtio技术。这个方案相较于设备模拟在性能上有所提高，但是兼容性较差，而且在高I/O负载场景，后端驱动的CPU占用较高。

3、 设备直接分配

将一个物理设备直接分配给Guest OS使用。此方式的性能显而易见，要比上面两种好很多，但是需要硬件设备支持，且无法共享和动态迁移。

4、 设备共享分配

此方式是设备直接分配的一个扩展，其主要就是让一个物理设备可以支持多个虚拟机功能接口，将不同的接口地址独立分配给不同的Guest OS使用。如SR-IOV协议。

2.2 OS间通信

Hypervisor中有很多技术，例如CPU 虚拟化和节能降耗技术、IO 设备虚拟化、实时性技术、安全和可靠性技术等，大家可以自己查资料去学习，特别是参考国内的minos，bao-hypervisor开源软件去学习，修改，使用（大家懂的）。

这里主要介绍下多OS的通信技术，后面在介绍多OS电源管理时会用到。

Hypervisor（虚拟化管理程序）是一种软件或硬件层面的虚拟化技术，用于在物理计算机上运行多个虚拟操作系统（OS）。Hypervisor需要提供一种有效的机制，以便不同虚拟机（VM）之间以及虚拟机与宿主机（host）之间进行通信。以下是几种常见的Hypervisor的OS间通信机制：

1. 虚拟网络：Hypervisor可以创建虚拟网络，为虚拟机提供网络连接和通信功能。虚拟网络允许虚拟机之间进行网络通信，就像它们连接在同一物理网络上一样。这种通信机制基于网络协议和虚拟网络设备的实现。

2. 共享内存：Hypervisor可以在物理内存中创建共享区域，允许不同的虚拟机共享内存数据。通过在共享内存区域中读取和写入数据，虚拟机可以进行相互通信。这种通信机制可以在虚拟机之间高效地传递数据，但需要适当的同步和互斥机制来处理并发访问。

3. 虚拟设备和驱动程序：Hypervisor可以为虚拟机提供虚拟设备和驱动程序，使得虚拟机可以与宿主机和其他虚拟机进行通信。通过虚拟设备接口和相关驱动程序，虚拟机可以发送和接收数据包、访问存储资源和执行其他设备相关的操作。

4. 信号和事件：Hypervisor可以使用信号和事件机制来实现虚拟机之间的通信。例如，一个虚拟机可以向Hypervisor发送信号，通知其他虚拟机发生了特定事件或状态变化。这些信号可以在虚拟机之间进行同步或触发相应的处理逻辑。

5. 宿主机通道：有些Hypervisor提供了特定的宿主机通道，允许虚拟机与宿主机之间进行通信。这些通道可以用于传递命令、状态信息、性能指标等。通常，宿主机通道是通过特定的API或驱动程序提供的。

其实就是：

要么共享内存+中断，

要么寄存在某个程序上（驱网络动、虚拟设备驱动）

要么Hypervisor加一套消息处理通道机制（事件、信号、通道）。

2.3 OS间电源管理

例如司机不开车时对整车进行关机，那么这个命令如何在三个OS直接传递执行，这里必须有一个次序，并且有一个代理人。比如司机（上帝）发送了一个指令给汽车，汽车里面的车控OS最先接收到指令（教皇），然后教皇下令给座舱OS（大主教），大主教继续给智驾OS（主教）传达命令，然后各自去完成指令。

教皇就是Host OS，其他的都是Guest OS。Host OS和Guest OS的通信0就是上面3章说的一种方法即可。例如采用中断+共享内存，那么两个OS都需要注册对应的中断处理函数，映射好共享内存，Guest OS一旦接受到中断，读取共享内存中的命令后就去执行。

不管是Host OS或者Guest OS执行电源命令都是通过HVC命令陷入到Hypervisor去处理。

2.4 计算资源模拟

一般运行AUTOSAR系统的核计算能力比较弱，那么如果能采用便宜又计算能力强的核，利用Hypervisor技术去模拟一个M核运行AUTOSAR就比较经济了。

例如ARM A核计算能力强，搞上几十个，通过Hypervisor统一对外提供计算能力，这样就可以模拟上百个M核的计算能力。

3. 车载Hypervisor

3.1 技术要求

Hypervisor虽在互联网领域大放异彩，但汽车领域的特殊性，决定了不可能完全照搬互联网的成熟经验。Hypervisor在汽车领域适配的过程中，必须正视和尊重以下和互联网领域的差别：

（1）物理硬件层面。 互联网的集群服务器模式，可以让其拥有灵活可扩展的高计算能力和大存储能力，Hypervisor完全不用操心自己需要消耗多少计算和存储资源的问题。而在成本极其敏感的汽车领域，不管是当下的域控制器还是后面的高性能中央计算单元中的主芯片，其计算能力和存储能力就显得捉襟见肘。降低CPU占用、AI算力消耗和存储需求将会是贯穿整车项目开发始终的工作。Hypervisor自身的轻量化能力，成为衡量其能否在汽车领域大规模应用的一个关键指标；

（2）安全冗余层面。互联网领域面对的是动态的用户任务，互联网大佬期望Hypervisor可以动态分配物理硬件资源，有效利用闲置资源，从而实现降本增效的作用；汽车领域面对的是相对固定的用户计算任务，任务所需硬件资源在出厂前已由工程师设计分配好。汽车大佬们期望Hypervisor在实时性、可靠性、安全性等方面可以更加出众；

（3）适配开发层面。在汽车领域，MCU/MPU/SOC类型丰富的你无法想象，操作系统多的也让你数不胜数，如何减少Hypervisor在适配底层不同硬件和上层不同操作系统的工作量，是横亘在Hypervisor面前的另外一座高山。

汽车领域和互联网领域的差别，决定了Hypervisor要想在汽车领域继续攻城拔寨，必须继续修炼直至拥有如下能力：

（1）安全冗余层面。Hypervisor必须具备通过资源分区技术严格隔离和分配资源的能力。当一个虚拟机中的应用程序出现故障时，只可以影响分配给它的内存，而不会影响其它虚拟机的内存池。当然前提是开发人员提前规划好应用的内存需求。

（2）通用开发框架层面。汽车领域需要一种权威的Hypervisor通用框架和标准接口，以减少适配底层不同硬件和上层不同操作系统时的开发工作量。目前VirtIO标准已得到汽车行业一众巨头的支持，未来有希望脱颖而出，实现大一统；

（3）任务调度机制。汽车领域存在大量实时任务和非实时任务，而这两种系统对于任务的时间响应要求有着本质的不同。Hypervisor应该具备灵活的时间调度机制，既能支持基于优先级的任务调度方式，又能支持基于时间片的任务调度方式；

（4）进程间通信机制。Hypervisor在对虚拟机进行严格安全隔离的同时，也需要支持不同虚拟机进程之间以受控方式进行相互通信。而最基本的进程间通信包括同步消息传递和共享内存两种方式。

3.2 三域应用

车控：使用主要注重资源的独占，例如独占核，甚至其某个主要程序需要独占一个核心，强调实时性

智驾：需要AI大量计算，可能需要80%以上的计算资源分配。另外摄像头等设备的虚拟化也有需求。

座舱：注重响应，还有外设的使用，例如支持多个屏幕的显示，资源动态分配，安全隔离

3.3 在AUTOSAR上的使用

依赖硬件虚拟化扩展：AUTOSAR CP（Classic Platform）通常运行在MCU（如NXP S32K、瑞萨RH850）上，需Hypervisor支持ARM TrustZone或Intel VT-x等硬件虚拟化技术，以实现安全关键系统（如动力控制）与非安全系统（如诊断服务）的隔离。

EB tresos Hypervisor案例：该Hypervisor专为实时应用设计，支持在单个MCU上并行运行多个AUTOSAR协议栈实例，通过硬件虚拟化扩展降低上下文切换开销，确保实时任务（如CAN通信）在微秒级时间内完成。

强实时性要求：AUTOSAR CP需满足ISO 26262 ASIL-D功能安全等级，Hypervisor需采用静态分区调度，确保关键任务（如制动控制）优先占用CPU资源，防止非关键任务（如日志记录）干扰。

Mentor嵌入式Hypervisor案例：该Hypervisor通过优先级抢占调度算法，使AUTOSAR实时任务在10ms内完成响应，同时通过内存保护机制防止缓冲区溢出攻击。

静态资源分配：AUTOSAR CP需严格分配CPU核心、内存带宽等资源，防止任务间竞争。例如，为安全关键系统预留专用CPU核心，确保其不受其他任务影响。

Bao Hypervisor案例：Bao采用静态分区设计，通过形式化验证确保资源分配的确定性，满足车规级功能安全要求。

强隔离性要求：AUTOSAR CP需防止非安全系统（如娱乐系统）故障影响安全关键系统（如动力控制），Hypervisor需通过硬件隔离（如ARM TrustZone）或软件隔离（如内存保护单元MPU）实现。

AUTOSAR与Hypervisor整合案例：东软NeuSAR DS平台将AUTOSAR CP与Hypervisor融合，通过静态分区隔离安全关键任务，同时提供工具链支持特定平台（如瑞萨R-Car H3）的配置与编译。

跟A核使用的差异点：

4. 使用举例

首先有了多核大芯片，然后去兼容汽车里面的多个软硬件系统，这个是目标。

4.1 Bao-Hypervisor

那么起步怎么做？为了安全起见，在多核芯片里面，例如20个核，分出来4个核绑定一个Linux，其他OS不能用这4个核，这样对Linux来说好像是完全运行在自己的芯片硬件上，比较稳定。外设也搞成自己专用的。所以这一阶段只是多个OS都挪到一个芯片上运行，OS之间不共享资源。

Bao-Hypervisor开源项目就是一个简单些的虚拟机，可以实现虚拟CPU和物理CPU的一对一绑定：

参考：https://d-nb.info/1365343391/34

代码：bao-project/bao-hypervisor.git

目录结构及其简要说明：

src: 包含核心的Hypervisor源代码，针对Armv8架构实现了静态分区功能。

arch: 架构相关代码，特别是针对Arm体系结构的实现。 drivers: 设备驱动程序，用于Hypervisor与硬件交互。 include: 头文件，定义了接口和数据结构。 libbaohyp: 库函数，提供给Hypervisor内部使用的通用功能。 scripts: 启动脚本和构建工具链，帮助编译和部署Hypervisor。

docs: 文档资料，包括设计文档和技术白皮书。

examples: 示例配置和演示案例，展示如何设置不同的客机操作系统。

tools: 辅助工具，可能包括调试或配置辅助程序

那么再进一步就可以发挥Hypervisor的优势了，这就是静态到动态的转变，共享可以大大的节省成本。

4.2 QNX Hypervisor

QNX Hypervisor是一款用于实时互联嵌入式系统的实时 1 类虚拟化解决方案，QNX Hypervisor充分利用了硬件虚拟化功能来执行内存，CPU内核，PCI配置以及虚拟机之间的中断隔离。将硬件设备分配给特定的虚拟机，从而将这些设备从所有其他虚拟机中隐藏。还支持基于VirtIO的块设备，控制台和网络以及其他用于设备共享的半虚拟化驱动程序。

通过QNX Hypervisor，可以安全地整合多个操作系统，使其在同一SoC上共存，使用独特的QNX OS微内核体系结构构建，并将安全关键组件与非安全关键组件分开。与安全相关的组件在一个操作系统上运行，而非安全相关的组件则在虚拟机上的另一个操作系统上运行。通过具有最高安全合规性和预认证水平的管理程序技术，可以减少安全认证时间和成本。

安全隔离

利用POSIX和VirtIO等标准，QNX Hypervisor提供了将安全关键组件与非安全关键组件分离和隔离的功能。使用QNX Hypervisor根据系统要求混合虚拟和主机环境。主机环境是支持虚拟机的服务域。独立的隔离客户操作系统。

设备共享

开发功能齐全的虚拟机管理程序环境，在来宾和主机之间共享图形，音频，触摸屏等支持未修改的Android，Linux，QNX和其他OS的安全共存和控制，通过遵循具有自适应分区的基于优先级的虚拟CPU（vCPU）共享模型以最大化计算吞吐量，QNX Hypervisor提供了高性能的虚拟化环境。建立可靠的系统而不会浪费资源，确保共享CPU时，较高优先级的来宾OS将抢占较低优先级的来宾OS，满足嵌入式零停机生产系统的精度要求。

QNX 技术支持客户操作系统共享 GPU 设备，由此可以允许虚拟机（客户操作系统）渲染图形输出，输出到远程独立和专用外部显示器。

虚拟机间通信

在多个虚拟机中运行的应用程序必须协同工作才能交付嵌入式设备的服务。QNX Hypervisor支持虚拟机之间的共享内存访问，共享文件访问以及高速TCP / IP / UDP网络连接，以允许在多个虚拟机中运行的应用程序进行高效通信。

QNX客户机

QNX Hypervisor支持QNXNeutrino®OS，Linux和Android操作系统，以及其他未修改的操作系统，RTOS和实时执行程序。

QNX Hypervisor实现为经过业界验证的基于QNX Neutrino微内核的RTOS的虚拟化扩展，继承QNX操作系统的所有实时性和稳定性。通过使用QNX Hyperviosr简化系统配置和资源分配，提高开发效率，有效减少产品开发周期，并能通过硬件集成来降低成本。

4.3 ACRN

ACRN是linux针对IOT网络开源的type 1 hypervisor项目。ACRN 是一种灵活、轻量级的虚拟机管理程序，在构建时考虑到了实时性和安全性，并经过优化。 ACRN 定义了一个设备管理程序参考堆栈和一个体系结构，用于在使用虚拟机管理器 (VMM) 的整合系统上运行多个安全管理的软件子系统。 它还定义了虚拟设备仿真的参考框架实现，称为“ACRN 设备模型”。

上图左侧所示，资源由预启动的用户虚拟机 (VM) 进行分区和使用。 预启动意味着它由hypervisor直接启动，甚至在服务 VM 启动之前。 预启动的 VM 独立于其他虚拟机运行，并拥有专用的硬件资源，例如 CPU 内核、内存和 I/O 设备。 其他虚拟机甚至可能不知道预启动的 VM 的存在。 因此，它可以用作安全操作系统虚拟机。 比如平台硬件故障检测代码在这个预先启动的 VM 中运行，并在发生系统严重故障时采取紧急措施。

上图右侧所示，剩余的硬件资源在服务虚拟机和用户虚拟机之间共享。 服务VM类似于Xen的Dom0，用户VM类似于Xen的DomU。 如果没有预先启动的虚拟机，服务虚拟机是 ACRN 启动的第一个虚拟机。 服务虚拟机可以通过运行原生驱动程序直接访问硬件资源，并通过设备模型为用户虚拟机提供设备共享服务。 目前服务VM是基于Linux的，但也可以使用其他操作系统，只要移植ACRN Device Model即可。

使用场景：

ACRN 管理程序可用于构建汽车软件定义驾舱 (SDC) 和车载体验 (IVE) 解决方案。在此场景中，汽车 SDC 系统由运行在服务 VM 中的仪表盘 (IC) 系统和运行后启动用户 VM 的车载信息娱乐 (IVI) 系统组成。 此外，可以修改 SDC 场景以添加更多可托管后座娱乐 (RSE) 系统（图中未显示）的发post-launched用户虚拟机。

仪表盘 (IC) 系统用于向驾驶员显示有关车辆的操作信息，例如：

汽车的速度、油位、行驶里程和其他驾驶信息；

在挡风玻璃上投射平视图像，并在燃油或轮胎压力低时发出警报；

显示用于停车辅助的后视和环视摄像头。

车载信息娱乐 (IVI) 系统的功能包括：

导航系统、收音机和其他娱乐系统；

通过语音识别连接到移动设备以进行电话、音乐和应用程序；

通过手势识别或触摸控制交互。

后座娱乐 (RSE) 系统可以运行：

娱乐系统；

虚拟办公室;

连接到前座 IVI 系统和移动设备（云连接）；

通过语音识别连接到移动设备以进行电话、音乐和应用程序；

通过手势识别或触摸控制交互。

后记：

整体来说Hypervisor跟OS一样开源的众多，已经不是有技术门槛的事情了。但是其靠近硬件，如果使用开源自研，还是需要人力的投入去修改适配代码，特别是业务新加虚拟设备用于VM间通信的场景。