问题引入：

Hypervisor是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？

没有MMU就做不了虚拟化？

1.为什么要提汽车ECU的虚拟化？

要讲汽车ECU的虚拟化，首先要从汽车电子电气架构的演进roadmap开始说起。汽车行业领头羊博世将整车电子电气架构定义成了六个主要发展阶段，如下：

模块化阶段：汽车上每个 ECU 负责特定的功能，比如车灯控制器，制动控制器等，这些控制器像叶子一样挂在CAN总线上，随着汽车功能增多这种架构日益复杂，无法持续。

集成化阶段，单个 ECU 负责多个功能，ECU 数量较上一阶段减少。在这两个阶段，汽车电子电气架构仍处于分布式阶段，ECU 功能集成度较低。

集中化阶段，即现在比较主流的功能域控阶段。功能域即根据功能划分的域控制器，最常见的是如博世划分的五个功能域（动力域、底盘域、车身域、 座舱域、自动驾驶域）。域控制器间通过以太网和 CANFD（CAN with Flexible Data-Rate）相连，其中座舱域和自动驾 驶域由于要处理大量数据，算力需求逐步增长。动力总成域、底盘域、车身域主要涉及控制指令计算及通讯资源，算力要求较低。

域融合阶段。在功能域基础上，为进一步降低成本和增强协同，出现了跨域融合，即将多个域融合到一起，由跨域控制单元进行控制。比如将动力域、底盘域、车身域合并为整车控制域，从而将五个功能域（自动驾驶域、动力域、 底盘域、座舱域、车身域）过渡到三个功能域（自动驾驶域、智能座舱域、车控域）。

车载电脑阶段，随着功能域的深度融合，功能域逐步升级为更加通用的计算平台，从功能域跨入位置域（如特斯拉的前域、左域、右域）。区域控制器平台（Zonal Control Unit，ZCU）是整车计算系统中某个局部的感知、数据处理、控制与执行单元。它负责连接车上某一个区域内的传感器、执行器以及 ECU等，并负责该位置域内的传感器数据的初步计算和处理，还负责本区域内的网络协议转换。

车云阶段，将汽车部分功能转移至云端，车内架构进一步简化。车的各种传感器和执行器可被软件定义和控制， 汽车的零部件逐步变成标准件，彻底实现软件定义汽车功能。

可以看到，随着电子电气架构的更新，整车所需的ECU数量更少，但每个ECU功能更加丰富，例如将制动、转向、动力控制的功能全部集中到一个ECU。这种功能的集中对控制器所采用芯片的资源保护提出了巨大的挑战。

因此，借鉴座舱域控将QNX、Android集中到一块SOC的经验，在MCU上实现虚拟化技术，将不同功能安全等级的系统部署到同一个硬件平台上。如下图：

2.虚拟化技术分类

虚拟化技术按照虚拟化层次通常可以分为硬件虚拟化和操作系统虚拟化两类。

2.1 硬件虚拟化

进一步的，硬件虚拟化可细分为 Type1 和 Type2 两类；

Type1类型的虚拟化

虚拟化管理程序直接运行在裸硬件上，因此也叫作裸机虚拟化；如下图，Hypervisor一般是一个嵌入在Host OS内核里面的一部分，能够直接操作控制硬件并管理多个虚拟机（Guest VM）。每个虚拟机都有自己的操作系统和应用程序（下图的APP+Guest OS），可以完全独立运行。

Tpye2类型的虚拟化。

与Type1类型的虚拟机不一样，Type2类型虚拟化是指在已经装载好OS的的硬件上运行一个Hypervisor软件，这个软件作为应用程序管理多个Guest VM。

可以看到，Type 1 和 Type2的虚拟化最大区别在于Type 1的Hypervisor可以直接操作硬件，没有多余的开销，性能相对比较高；Type2的Hyperviosr访问硬件资源，还必须经过Host OS。可以看到座舱域仪表和中控使用的就是Type1类型的虚拟化技术。

因此在汽车领域，由于对功能安全等级、实时性有较高要求，一般均使用 Type1的Hypervisor，Hypervisor 之上直接运行多个客户操作系统 (GuestOS)；那么这里就出现了今天的首个问题，Hypervisor是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？这个我们稍后再谈。

2.2 操作系统虚拟化

操作系统虚拟化一般就是指容器技术，由操作系统内核提供的资源隔离和控制功能，创建出多个相互隔离但共享系统内核的用户空间实例，从而实现对多系统运行能力的支持。

进一步讲，容器技术就是将操作系统所管理的计算机资源，包括进程、文件、设备、网络等分组，然后交给不同的容器使用。容器中运行的进程只能看到分配给该容器的资源。从而达到隔离与虚拟化的目的。实现容器技术需要用到Namespace及cgroups技术。

典型代表就是Docker公司在2013推出的轻量级虚拟化技术--Docker。结构如下图：

在这种虚拟化机制下，操作系统内核被每个容器共享，每个容器使用相同的OS，由OS来分配资源，不过正是因为这种多个App共享内核的机制，可能存在漏洞或攻击风险。因此目前容器化场景在汽车中还没看到实际应用。

2.3 硬件虚拟化的资源安全

回到我们的问题一，Hypervisor是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？

以常见的Type 1 的Hypervisor安全架构为例，资源安全需要从vCPU调度隔离、内存隔离、存储隔离以及网络隔离四个方面来保证安全，如下图：

在vCPU的调度中，常见的ARM-v8架构提供了EL0-EL3的等级，每个等级可运行的指令不一样，通常EL0运行APP，EL1运行Guest OS，EL2运行Hypervisor(负责vCPU的上下文切换)，实现Guest OS和Hypervisor的隔离；

在内存隔离中，一般要用到我经常谈到但是没有深入研究的MMU--内存管理单元。MMU主要是包含以下几个功能：

虚拟地址和物理地址的翻译

访问权限控制

对硬件资源物理内存进行管理

GuestOS 虚拟地址到物理地址的映射由 Hypervisor 来实现，Hypervisor 可以使GuestOS的虚拟地址映射到不同的物理内存段上，保证了 GuestOS 间的内存隔离。如下：

这就引出第二个问题：没有MMU的芯片是不是就不能做虚拟化了呢？答案是否定的，请继续看。

在前面，我们聊到虚拟化技术比较关键的就是vECU的虚拟地址翻译问题，例如Cortex-A77就使用MMU来进行虚实地址的转换；实际上，在汽车MCU中，还很少看到带MMU硬件的芯片，那么是否他们就不能使用虚拟化技术呢？

为此，我查阅了目前来说应该是有虚拟化方案支持的量产芯片RH850 U2A的datasheet，现抛砖引玉，希望大家共同探讨这项变革汽车域控的技术。

3.U2A虚拟化方案概述

废话不多说，首先来看U2A的整体资源，该芯片有4个采用双核锁步的 400 MHz CPU 。每个CPU都集成了基于硬件的虚拟化辅助功能，允许满足不同 ISO26262 功能安全级别的多种软件系统在高性能模式下独立运行且不受干扰。此外，还可减少虚拟化占用的资源，以保障实时执行。这使用户能够将多个 ECU 功能集成到单个 ECU 中，同时保持功能安全、信息安全以及实时操作要求。

U2B在U2A的基础上新增了QoS、FXU，扩容了Flash以满足未来架构的需求，同时成本仍旧低于与SOC相比。由于没有看到U2B的片子，这里还是从U2A分析。

光有硬件虚拟化辅助其实不够，还需要hypervisor软件，因此瑞萨和ETAS进行合作，瑞萨搞硬件，ETAS干软件，结合了U2A 硬件 （HW） 关键功能（例如虚拟化管理程序、QoS服务质量、功能安全和网络安全等）以及ETAS出色的软件产品组合和软件能力，提供软件优先的解决方案，可将多个应用程序集成到单个 ECU 中，从而以安全可靠的方式彼此分离，最大程度地确保相互之间不受干扰。其产品示例架构如下：

可以看到，在上述产品示例中，仍旧采用了之前讨论的 硬件type1虚拟化方案，其hypervisor软件叫做RTA-HVR；

它总共分成了4个大的Partition：A、B、C、D

Partition A：在1个物理CPU里运行单个VM(虚拟机)，即VM A；

Partition B：在2个物理CPU里运行多个VM，VMB 0，VM B1；

Partition C\D：2个单个VM共享 1个物理CPU。

在上述VM之上，运行着不同的Guest SW，即不同的vECU，实现不同功能聚合到一个MCU上。

我们这里首先来看看，U2A为虚拟化提供了哪些硬件辅助功能。

4.U2A的虚拟化功能概述

在U2A中，瑞萨使用的是自研内核G4MH2来支持虚拟化功能。当使用虚拟化功能时，瑞萨称这个系统为虚拟系统，没有使用叫做常规系统。如下：

在常规系统中，OS几乎可以使用CPU的所有功能；而在虚拟系统中，OS仅能使用由虚拟软件管理下的VM分配的资源，虽然运行在VM上的软件以为它在独享整个CPU的资源，但实际上从CPU视角，有可能它只用了很少一部分资源。这样的好处就是即使运行在VM上的软件出现了风险，也不至于导致整个硬件系统的崩溃。换句话说，就是不用硬件去Reset整个系统，只需要重启VM，把风险控到最低。

Ps:该种虚拟化也叫作半虚拟化，详见全虚拟化与半虚拟化-阿里云开发者社区

5.虚拟化辅助功能的使能

U2A的CPU G4MH2，在原来运行模式(Supervisor mode和User Mode)的基础上新增了两种模式，叫做Host Mode和Guest Mode；当CPU使能虚拟化辅助功能后，可以使用上述两种模式作为新的CPU运行模式。这几种模式对应不同特权，它们关系如下：

Hypervisor privilege(HV)：构建、管理VM和CPU资源的模式，仅在虚拟化辅助功能开启且进入Host Mode，CPU可使用HV特权；主要是给虚拟化软件使用。

Supervisor Privilege(SV)：异常、重要系统资源分配、致命错误处理等需要在此特权等级下处理，在常规模式和虚拟模式下均支持，例如在虚拟系统里运行在VM上APP出现了异常，此时需从UM进到SM，使用SV对该异常进行处理。

上面两个是个人认为比较关键的，此外还有User Mode Authority、 协处理器使用权限，这里还没有研究到，后面再谈。

6.留坑

在U2A没有找到关于MMU的描述，那它是如何实现虚拟化的呢？我准备留下这几个方向进一步研究

U2A整体架构分析

U2A 硬件硬件虚拟化辅助功能详解

两个使用相同芯片的vECU集成到U2A时，二者链接文件一样（即Code、Data均放在原MCU相同位置），U2A如何保证在不修改原工程的情况完成Flash的地址隔离（即vECU A使用相同地址，但在VMM翻译地址时映射到物理BankA；vECU B同理）