本文主要是介绍虚拟化 (Hypervisor) 技术详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
随着 ICT 技术的发展，单 SOC 算力可以承担更多业务，网络带宽拓展及低时延、区分服务等特性使得业务部署、功能分配更加灵活，比如 : 感知、融合、规划、控制、执行可分离解耦，汽车业务功能可分可合、可软件定义。
电子电气架构从分布式架构到域集中式架构，再到中央集中式架构转变，分散的 ECU功能集成到域控制器甚至车载中央计算机，这就是多域融合。
汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。
但是多域业务具有不同的技术需求，
- 比如座舱域 IVI 业务强调交互体验、应用生态丰富，比较适合的操作系统是 Android；
- 仪表盘、辅助驾驶有实时性、可靠性要求，操作系统倾向于 RTLinux、RTOS；
- 智驾域强调大算力融合感知、推演规划，也有实时性、可靠性要求，也会选择 RTLinux、RTOS。
在域融合的同时，要保证关键业务的安全可靠，也要考虑应用生态的可持续性兼容，这就需要有资源隔离技术来支撑在同一 SOC 上切分资源，可并发运行多种操作系统，保障互不干扰。
资源隔离技术有多种，从硬件底层逐层向上包括
- 硬件隔离、
- 虚拟化隔离、
- 容器隔离、
- 进程隔离等。
硬件隔离的隔离性最好，单隔离域的性能、安全可靠性最好，但灵活性、可配置性差，不能实现硬件共享，导致整个系统的资源利用率差，不能充分达到软件定义汽车的目标。
容器隔离、进程隔离可以更轻量级地实现业务隔离，但还是在同一个操作系统内，存在着资源干扰、相互安全攻击的隐患，并且无法支持异构操作系统业务域融合，影响传统业务继承，不利于生态发展。
在众多的资源隔离技术中，虚拟化是安全可靠、弹性灵活的优选方案，是软件定义汽车的重要支撑技术。典型应用场景如图 1 所示：
一、技术形态
Hypervisor 直译即 “超级监督者” ，也称为虚拟机监控程序（VMM）。如图 2 所示，Hypervisor处于 SoC 硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源，按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。
Hypervisor 实现了硬件资源的整合和隔离，使应用程序既能共享 CPU 等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域多元化应用场景需求。
在汽车领域，Hypervisior 主要完成以下任务：
- CPU 虚拟化：为虚拟机提供 VCPU 资源和运行环境；
- 内存虚拟化：负责为其自身和虚拟机分配和管理硬件内存资源；
- 中断虚拟化：发生中断和异常时，按需将中断和异常路由到虚拟机进行处理；
- 虚拟机设备模拟：根据需求创建虚拟机可以访问的虚拟硬件组件；
- 硬件支持 BSP：提供 Hypervisor 在 SoC 上运行的板级支持包，如串口驱动；
- 虚拟机资源配置：对虚拟机的 CPU，内存，IO 外设等资源进行配置和管理；
- 虚拟机通信：为虚拟机提供 IPC，共享内存等通信机制。
- 虚拟机调度：为虚拟机提供优先级和时间片等调度算法；
- 虚拟机生命周期管理：创建，启动和停止虚拟机；
- 虚拟机调测服务：提供控制台，日志等调试功能；
在汽车领域，Hypervisior 还面临如下挑战：
- 轻量高效。Hypervisor 在带来软件定义的灵活性的同时，也导致了软件栈层次增加，不可避免会有性能损耗。汽车领域的成本敏感特性，注定了降低 CPU、存储、网络、GPU 等外设性能损耗的需求贯穿整车项目始终，因此 Hypervisor 的轻量和高效十分重要；
- 安全可靠。相较于互联网领域看重的资源动态分配和闲置利用，汽车领域更看重 Hypervisor 的实时性、可靠性、安全性；
- 便捷适配。在汽车领域，芯片类型和操作系统丰富多样，嵌入式虚拟化的一大特点就是异构，Hypervisor 必须具备快速适配不同的底层硬件和上层操作系统的能力。
二、技术发展趋势
2.1 云边端虚拟化关键技术差异化
虚拟化技术最早可以追溯到 20 世纪 60 年代，IBM 开发了虚拟机监视器软件，将计算机硬件虚拟分割成一个或多个虚拟机，可支持多名用户对大型计算机的同时、交互的访问。
随着 21 世纪通用服务器算力的提升，云计算蓬勃发展，作为底层支撑技术的云虚拟化也快速迭代演进。
后来算力从云、边、端逐步下沉，也就伴随着出现了边缘虚拟化、端侧嵌入式虚拟化。它们的典型架构、关键技术需求如图 3 所示。
（1） 云侧虚拟化
其特点是硬件平台基本同构，大量节点构成集群，架构设计以吞吐能力优先，要支持多业务并发，虚拟化要满足集群负载均衡、节能降耗的资源调度策略，在进行跨节点虚拟机调配过程中，要保证业务无中断迁移。虚拟机故障时，要能保证从检查点恢复，减少业务损失，虚拟机要能支持 CPU 算力、内存、存储空间、网络、GPU、外设等能力的弹性扩展，还要能超分配，以便提升数据中心的运营收益。
（2） 边侧虚拟化
是在某些特定业务的边缘节点上，采用通用 ICT 架构，支持多种业务的动态部署，典型如 SDN、NFV。其技术特点是：基于通用硬件平台、行业定制的管理部署平台，实现软硬解耦、软件定义，多功能节点按需部署、弹性组网，一般会采用 1+1 或者 N+1 冗余方式保证业务高可用，在 5G 电信网元中需要考虑 5G 业务端到端实时性，Hypervisor、虚拟机、通信协议栈都需要设计考虑。
（3） 端侧虚拟化
端侧典型特点是异构，其芯片架构、处理能力都差异较大。一般是单芯片方案，不存在着集群、主备间的虚拟机迁移，因此比较强调高安全、单节点高可靠，比如会有功能安全 ASIL 等级要求，同时对于实时性、确定性有更强的要求。另外，端侧资源更加有限、成本更敏感，因此要求 Hypervisor 轻量化、高性能。
2.2 虚拟化模型趋势
Hypervisor 可以划分为两大类，
-
一类是 Type1 裸机型，Hypervisor 直接运行在硬件设备上的，也叫做 Bare-Metal Hardware Virtualization（裸机虚拟化环境）；
-
一类是 Type2 主机托管型，也叫做 Hosted Virtualization （主机虚拟化环境）。
图 4 展示了两种 Hypervisor 的分层架构。
Type2 型 Hypervisor 需要借助宿主操作系统来管理 CPU、内存、网络等资源，由于 Hypervisor 和硬件之间存在一个宿主操作系统，Hypervisor 及 VM 的所有操作都要经过宿主操作系统，所以就不可避免地会存在延迟、性能损耗，同时宿主操作系统的安全缺陷及稳定性问题都会影响到运行在之上的 VM（虚拟机），所以 , Type-2 型 Hypervisor 主要用于对性能和安全要求不高的场合，比如 : 个人 PC 系统。
Type1 型的 Hypervisor 不依赖主机操作系统，其自身具备操作系统的基础功能。设计上更简洁，直接运行于硬件之上，整体代码量和架构更为精简，对内存和存储资源要求更少，可满足自动驾驶车控系统功能安全等级要求，也具备进行形式化验证的条件**。所以汽车操作系统更适合使用 Type 1 型 Hypervisor。**
随着微内核操作系统技术的发展，很多基于微内核操作系统设计的 Hypervisor 依赖的 Host OS 已经非常精简，只包括基本的、不变的功能，如 : CPU 调度和内存管理，设备驱动和其他可变组件处于内核之外，这类 Hypervisor 应当归于 Type1、还是 Type2，业内存在分歧。总体来说，微内核 Hypervisor 更小、更稳定、扩展性更好，更适合用于嵌入式虚拟化场合。
2.3 Hypervisor 与虚拟机协作技术路线
（1） 全虚拟化
最初的虚拟化是通过软件模拟具有完整硬件系统功能的、运行在一个隔离环境中的计算机系统，即通过软件虚拟硬件设备提供给 GuestOS 使用，优点是 GuestOS 不感知外部真实硬件环境、不用改动。
由于 Guest OS 中每次访问全虚拟化硬件都要陷入到 Hypervisor 中，直接导致该方式虚拟的硬件性能较差，一般只用来模拟如串口等比较简单的硬件。
对硬件的模拟可以在 Hypervisor 中直接模拟，也可以将请求传递到其他 VM 中进行模拟，如在某一 VM 中通过 QEMU 进行模拟。
（2） 硬件辅助虚拟化
Intel 最早提出硬件辅助虚拟化技术，由硬件直接提供共享功能，支持多 GuestOS 的访问，减少软件虚拟技术带来的延时和性能损耗。
Intel 提出了分别针对处理器 & 内存、IO、网络的 Intel VT-x、Intel VT-d 和 Intel VT-c 技术等。随着 ARM 算力提升，从移动端向边缘、甚至云算力中心发展，ARM 也在不断增强其硬件辅助虚拟化技术，比如 stage 2 页表转换、虚拟异常等。
（3） 半虚拟化
在硬件辅助虚拟化技术不完善、不强大的发展阶段，或者对于某些复杂外设的共享复用，为避免全虚拟化的性能问题，可以采用 GuestOS 与 Hypervisor 协作的半虚拟化技术。
这种技术一般应用于 IO 设备虚拟化，采用前后端的方式来实现 IO 设备虚拟化，在 Guest OS 中实现前端驱动，在 Hypervisor 或 Host OS 中实现后端驱动，前后端一般按照 VirtIO 标准来实现，后端驱动作为硬件的实际访问方。
Guest OS 中前端驱动通过 Virt Queue 等通信机制与后端驱动进行通信，前端驱动将 Guest OS 的请求传递给后端驱动，后端驱动将请求发送给硬件驱动，处理完后将结果再传回给前端驱动。半虚拟化相对全虚拟化实现的硬件性能较好，且可实现相对比较复杂的硬件，比如 : 块设备，网卡，显示设备等。具体如图 5 所示。
Hypervisor 支持将硬件资源直接分配给其上虚拟机中 Guest OS 使用，无需通过 Hypervisor 进行地址和指令翻译。例如 : 串口资源、USB 资源等接口比较丰富的资源可以通过 Pass-through 直接分配给某虚拟机使用。
设备控制器一般都是以 MMIO 方式来访问的，所以只需要将控制器地址区域映射到 VM 就可实现设备控制器的分配，同时还需要分配一个设备硬件中断对应的虚拟中断到该 VM，直接透传的方式就是 VM 独占访问该硬件，所以在性能上是最好的。
三、关键技术解读
3.1 CPU 虚拟化和节能降耗技术
车载高性能处理器一般采用多核 CPU 架构。在 SMP（Symmetric Multi-Processing 对称多处理）架构下，Hypervisor 调度器会根据 CPU 的亲和性配置让客户机操作系统在指定的 CPU 上运行，虚拟机的操作系统可按照自己的调度方式，比如:优先级方式在 CPU 上进行任务调度。
为了最大化地利用系统资源，Hypervisor 也支持多个虚拟机对某个 CPU 的共享使用。在共享核上，Hypervisor 可通过优先级或时间分区方式对虚拟机进行调度，确保虚拟机运行时间和调度策略是确定的。
Hypervisor 的调度算法需要确保不能够出现分区内某个虚拟机出现死循环或故障而长期占用处理器资源，导致其他虚拟机的业务无法得到合理时间配额的问题。
虚拟机调度还需要考虑节能降耗问题，在工作负载较高的情况下系统提升主频提升用户体验，在工作负载较低的情况下系统自动节能降频提升续航。
车载高性能处理器本身为了节能降耗需求设计为大小核架构，CPU 以及之上运行的复杂操作系统需要支持大小核调度，动态调频，低功耗设置，关闭 CPU 核，休眠（Suspend to RAM/Suspend to Disk）等节能降耗功能。系统虚拟化后，CPU 等物理资源都需要Hypervisor 才能直接访问，Hypervisor 调度算法也需要完成对虚拟机节能降耗的支持。
3.2 IO 设备虚拟化
出于性能考虑，一般嵌入式领域多使用半虚拟化技术。半虚拟化技术需要 Guest OS 中的前端驱动与Hypervisor 中的后端驱动配合实现。前端驱动将 Guest OS 的请求通过 Hypervisor 提供的通信机制发送给后端驱动，后端驱动通过调用物理驱动实现对设备的访问。这就涉及到不同厂商的 Guest OS 与不同厂商的 Hypervisor 生态对接问题。
Virtio 是目前最流行的一种 I/O 半虚拟化解决方案。Virtio 是 OASIS 标准组管理的开放协议和接口，以使得虚拟机能够标准化方式访问 IO 设备。
Virtio 于 2016 年 3 月正式标准化，2020 发布 V1.1 版本。Virtio 标准采用通用和标准化的抽象模型，支持设备类型不断增加，性能高效，在云计算领域广泛应用，开源活跃度高，Linux 等操作系统已有稳定的前端驱动代码。大部分商业和开源 Hypervisor 都已经支持Virtio 标准。
Virtio 是车载行业比较常用的半虚拟化技术的实现，如图 6 所示，在 Guest OS 内部虚拟一条设备总线 Virtio-bus，通过 Virtio Ring 双向通信机制，前端驱动与挂载在 Virtio-bus 上遵循 Virtio 标准的后端虚拟设备，进行访问与通信。Virtio 提供了全面的 Virtio 总线和设备控制接口，包括 virtio-net， virtio-blk， virtio-console， virtio-input 等。
-
利用 virtio-blk 技术实现块设备共享
块设备是使用缓存机制读写的存储设备，分配给 Hypervisor 所在的操作系统进行管理。virtio-blk driver 是符合 virtio 标准的块设备驱动，vdev virtio block 是后端的虚拟块设备，virtio blk driver 通过该vdev 设备完成对物理块设备的读写，并获取执行结果。 -
利用 virtio-net 技术实现跨系统通信
Virtio-net 实现了多系统间点对点的通信，Guest 系统内部的 virtio-net driver 通过 virtqueue 与Hypervisor 所在系统的 virtio-net 设备进行全双工通信，实现多系统之间的控制类、配置类的指令、数据的交互。适合音视频流以外的数据传输，稳定性较好，因 virtqueue 的控制逻辑复杂，对实时性有一定影响。 -
利用 virtio 技术实现触摸共享
触摸设备是字符型设备，通过 virtio-input driver、vdev-input 实现前端驱动和后端设备。设备端通过 virtqueue 向驱动上报触摸坐标数据。
3.3 实时性技术
实时性是嵌入式实时操作系统的关键性能指标。Hypervisor 的实时性是整个系统实时性的基础，如果 Hypervisor 无法及时调度到客户机操作系统运行，客户机操作系统也不能取得较好的实时性指标。衡量 Hypervisor 实时性主要指标包括中断延迟和调度延迟。
中断延迟以硬件发生中断时刻为起始时间，以虚拟机收到 Hypervisor 注入的中断时刻为截止时间，在各种压力情况下最长延时时间即为中断延时。调度延迟是指以高优先级的虚拟机进程就绪为起始时刻，以该高优先的虚拟机进程得到调度运行为截止时刻，在系统各种压力情况下最长的延时时间即为调度延迟。
中断虚拟化后，当外界中断产生时，Hypervisor 收到并以最快的速度注入到虚拟机，使得 Hypervisor 对虚拟机中断处理时间足够少。Hypervisor 优化虚拟机的切换时间，尽量减少 Hypervisor 上关中断和关抢占的时间，尽量少使用内核锁，当高优先级的虚拟机需要切换运行时，能最快速度切换至高优先级虚拟机上运行。
3.4 安全和可靠性技术
功能安全、信息安全和可靠性是车控操作系统产品可靠安全运行的必要组成部分。Hypervisor 为智能汽车域控制器提供基础运行环境，其安全性和可靠性是保证整个系统功能安全和可靠的基础和核心。Hypervisor 需按照汽车功能安全 ISO26262 ASIL-D 最高标准进行设计，开发和测试，其功能安全需求由域控制器产品的安全需求分解产生。
Hypervisor 上运行了多个虚拟机，一个虚拟机的异常不能传递至其他虚拟机。Hypervisor 能获取到当前系统整体健康状态，当虚拟机发生异常时，Hypervisor 应实时监控系统健康状态，有效地隔离故障，并在最小波及范围内修复异常，保障系统持续可用。
Hypervisor 加入汽车软件栈，会导致纵向上软件栈层次增加，横向上业务软件复杂度增加，而汽车的安全可靠要求强于既有的云侧虚拟化、边缘虚拟化，因此虚拟化安全性正日益得到行业的关注。这些安全性包括：
- 虚拟机管理器和虚拟机之间的信任链问题。利用虚拟化技术在一个可信物理平台上创建出多个虚拟机，并将从硬件可信根开始构建的信任链传递到每一个虚拟机，从而在一个可信物理平台上构建多个虚拟的可信计算平台，有些解决方案缺乏虚拟机管理器到虚拟机之间的信任链验证；
- 虚拟机间的攻击：恶意入侵者可以通过利用虚拟机管理程序中的漏洞，通过同一物理主机上存在的另一个虚拟机来获得对虚拟机的控制，从而破坏目标虚拟机；
- 虚拟机逃逸：利用虚拟机软件或者虚拟机中运行的软件的漏洞进行攻击，以达到攻击或控制虚拟机宿主操作系统的目的。
为了提高 Hypervisor 的安全性，建立相应的安全性目标很重要，下表简要列出相关要求：
Hypervisor 的安全性能力可以从三个维度进行提升。
（1） 需要建立安全边界
如图 7 所示，这个边界由 Hypervisor 严格定义并且实施。Hypervisor 安全边界的保密性、完整性和可用性需要得到保证。边界能防御一系列攻击，包括侧向通道信息泄漏、拒绝服务和特权提升。
虚拟机监控程序安全边界还提供网络流量、虚拟设备、存储、计算资源和所有其他虚拟机资源的隔离能力。
整体虚拟化安全架构如图 8 所示。安全边界的保密性可以通过传统的密码学方法来实施。完整性通过可信度量机制来保障，可信报告机制实现不同虚拟环境的可信互通，监控机制动态度量实体的行为，发现和排除非预期的互相干扰。虚拟技术提供的隔离机制将实体运行空间分开。
安全边界的隔离通过Hypervisor的vCPU调度隔离安全、内存隔离、网络隔离和存储隔离技术来支持，实现了同一物理机上 Hypervisor 和虚拟机、虚拟机之间的隔离。
（2） 需要建立深度防御漏洞的缓解机制
对于安全边界存在的潜在漏洞，Hypervisor 需要有一定的技术手段进行主动防御，这些技术手段包括地址空间布局随机化（ASLR）、数据执行保护（DEP）、任意代码保护、控制流保护和数据损坏保护等。
（3） 建立强大的安全保障流程
与 Hypervisor 相关的攻击面包括虚拟网络、虚拟设备和所有跨虚拟机表面，所有虚拟机攻击面都建议实施威胁建模、代码审核、模糊（fuzzed）测试，通过建立自动化构建及环境，触发定期安全检查。
虚拟化技术作为云计算场景的重要技术，在 10 多年的生产实践中已经积累了很多安全范式，这些经验也可被汽车场景借鉴。
但是与云场景相比，汽车场景的虚拟化技术也有其特殊性，如虚拟机不需要动态迁移 / 创建，Hypervisor 有功能安全等级的要求等等，其安全性手段需要在实践中不断丰富和完善。
四、 典型应用案例
在汽车智能化发展历程中，虚拟化主要应用于智能座舱、智能驾驶、智能网关等融合场景。智能驾驶受技术成熟度、政策法规所限，基本处于预研、方案原型阶段。智能网关业务功能相对同构，并且有可能进一步融合到其他场景方案中。因此，目前主要的应用案例集中在智能座舱中。
智能座舱域融合也是在近几年启动，正在不断迭代演进中。受芯片算力、虚拟化技术成熟度、生态链对于虚拟化解决方案的掌控能力等因素影响，有些厂商同时采用了硬隔离方案来实现域融合，一方面最大程度地沿用既有技术能力，有确定性保障，但是缺少了软件定义的灵活性，智能化程度有限，是域融合的一种可选方案。
在嵌入式虚拟化技术方面，国外的 QNX、OpenSynergy、PikeOS 等有先发优势，尤其在汽车领域已耕耘多年，因此在这两年涌现了较多的应用案例。在智能本土化发展的趋势带动下，国内这几年也出现了不少芯片厂商、独立软件厂商研发嵌入式虚拟化技术、产品、解决方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中兴 GoldenOS、斑马智行的 AliOS Hypervisor、中汽创智 CAIC Hypervisor 等。
4.1 智能座舱域控制器产品
某厂家智能座舱域控制器产品，如图 9 和图 10 所示，基于高通 8155、瑞萨 R-Car H3 处理器，采用 QNX Hypervisor，搭载 QNX Host、 Android P/R/S Guest OS, 可配置输出最多 6 块高清大屏独立显示，集成了娱乐系统、液晶仪表、车身控制、DMS、APA 等功能，支持独立四音区、多屏互动和音视频分享，集成度高，在长城、长安、宇通客车等多款车型上适配量产。
另外，国产化方案芯驰 X9HP+ 平台，采用硬分区、Hypervisor 两种方案灵活配置实现中低端智能座舱域控制器产品。
4.2 RHOS 智能座舱域控制器平台
（1） NXP I.MX8QM 座舱域控制器
某厂家基于自研的 Type-1 型虚拟化软件 RHOS(Raite Hypervisor OS)，适配支持了 NXP I.MX8QM，提供一个轻量、灵活的汽车智能座舱虚拟化解决方案，已在东风车型量产上市。其系统架构如图 11所示：
在 SoC 上运行 Hypervisor 后可支持同时运行多个操作系统，比如 Linux 系统可以运行实时性和安全性较高的业务，如全液晶仪表等，可以扩展运行 DMS、HUD 等业务。另外一个虚拟机运行 Android 操作系统，上面部署信息娱乐等安全性和实时性要求较低的业务。为保证系统具备良好的市场竞争力，域控制器兼容 TBOX 功能需求，系统能够支持休眠唤醒和快速启动。
Linux 和 Android 虚拟机可按需进行资源的配置，包括内存、CPU、存储空间、外设等。该架构支持系统升级，包括对虚拟机和 Hypervisor 的升级，支持异常日志记录，包括虚拟机内核和 Hypervisor 日志。
多屏交互是智能座舱重要的应用场景，Android 的 APP 应用程序可以通过 Hypervisor 推送到 Linux仪表进行显示。
Android 和 Linux 仪表交互的方案如图 12 所示。NXP I.MX8QM 芯片有两个以上显示接口，每个显示接口可以接 2 个显示屏，当 Android 系统需要投射信息到仪表屏幕时，仪表显示屏的 Overlay 图层可以进行投屏内容的显示。
系统交互零延迟、零拷贝，多系统交互不额外占用 CPU 和 GPU 资源。通过Hypervisor 虚拟化技术实现跨系统多屏交互，有效提高了行车安全性，并降低智能座舱的硬件成本。
（2） MT8675 座舱域控制器
RHOS 通过适配支持MT8675，形成一个功能丰富、性价比高的一机多屏智能座舱域控制器解决方案，已获得多个车厂量产项目。其总体系统架构如图 13 所示：
MT8675 只提供了一个 GPU，座舱域需要在仪表和中控上共享使用 GPU 资源。RHOS 实现了 GPU虚拟化共享，并通过性能优化，达到业界领先的虚拟化效果（损耗 < 6%）。RHOS 支持 Suspend to RAM 功能，MT8675 A 核完全下电，满足智能座舱待机静态功耗小于 4mA 要求。
4.3 KCS 3.0 智能座舱虚拟化平台
某厂家基于 Renesas H3/M3 + QNX Hypervisor2.x 开发了支持 “一芯多屏” 的 KSC3.0 智能座舱虚拟化平台 , 可实现在一颗 SOC 上同时运行 QNX 仪表、Android 中控及副驾等多个系统，并支持以下特性：
- 4 个屏幕同时输出
- 多系统实时 3D 渲染
- 多屏共享
- 仪表和 IVI 间音乐、地图应用的多屏互动，
- 快速启动：<2s
- 人脸及情绪识别等
平台展示如图 14 所示：
此外，该厂家还基于 X86+KVM+QEMU 开发了数字孪生平台，通过虚拟化技术来模拟硬件开发平台，包括支持多路 Camera、多路显示输出、多系统音频混音，屏幕共享以及多路 CAN 信号等，能够很好地解决 SOA 平台开发过程中开发人员对于真实硬件平台的依赖。
本文节选自《中国汽车基础软件发展白皮书3.0》，本白皮书3.0以“汽车基础软件平台”为主题，围绕其技术形态和关键技术进行深入探讨，共享知识成果。
作者：AUTOSEMO
来源：汽车电子与软件
这篇关于虚拟化 (Hypervisor) 技术详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
