作者 | 辉羲智能-刘杰威
导读
本文主要探讨虚拟化技术对智驾芯片设计的需求和影响，以应对汽车芯片市场的大算力、高集成度和功能安全需求。作者基于对车载芯片发展趋势的一点思考，希望可以抛砖引玉，一起推动智驾芯片的技术发展。
HUIXI TECH
一、智驾芯片需要虚拟化
智驾系统不是一个单一的简单任务。
从功能维度看，其中必须使用多种典型功能，例如传感器的驱动，输入信息的融合和感知，路径的规划和实车控制，以及贯穿其中的功能安全和信息安全等等。
从生态维度来看，智驾解决方案的实现依靠于生态链多个合作伙伴的配合，例如硬件和驱动供应商，操作系统供应商，规控算法供应商等。这些独立的产品要求不同方向的技术栈，适合“术业有专攻”，同时也带来了不同产品间的集成难度。
从成本和效率维度看，高度集成的方案往往能带来成本优势，对效率一般会产生正面影响，对功能耦合性一般会提出更高要求。
为了给用户提供综合性能最好的产品，每一个维度都需要被考虑。于是从架构上就进化出了一种趋势来满足智驾系统的多维度要求：硬件通过高度集成化来降低成本，软件通过虚拟化来降低功能耦合性以及提高安全性。虚拟化技术就是目前业界比较成熟的、可以提供独立运行环境的技术手段。当然，为了做到在单一SoC上实现多个OS，除了虚拟化，也有其他方法，比如硬隔离。我们在下文对比说明。
HUIXI TECH
二、虚拟化技术特色
本文所述虚拟化以ARMv8-A核体系为案例，虚拟化技术原理说明主要以操作系统公开资料为例，相通思路很容易应用于其他Hypervisor方案。
硬隔离与虚拟化
隔离是虚拟化技术最主要的需求之一。实现手段可以是“硬隔离”，即从芯片设计的角度对功能进行分域，每个域分配特定的资源，然后通过特定的总线实现域间通信。也可以“软隔离”，即通过虚拟化的方式将同一个域内的资源隔开，让这些应用在各自独立的环境中运行，既保持一定的安全距离，又能彼此联系。
硬隔离和虚拟化分别有其特点和应用场景，下表列出了硬隔离和虚拟化技术不同之处和优劣对比。
硬隔离对于中断处理、共享非易失存储和错误检测和处理较难实现，虚拟化则有比较成熟的方案。虚拟化方案总体上较优，主要优势在于灵活性和扩展性。
对于复杂芯片设计，往往需要在不同场景分别使用不同的方案以达到综合效果最优。如对灵活性的要求较低，而更注重隔离性，则硬隔离可能更为适用。在智驾域常见的SoC中经常能看到MCU岛、信息安全岛等，即是硬隔离机制的典型案例。当然，这要求SoC设计中对每个“岛”所需的运算和存储资源进行精确的预计，如果因资源不足而导致跨过“岛”的界限来获取，那么系统性能将明显低于纸面参数。
在灵活性和隔离性都需要兼顾的场景中，例如多个A核构成的CPU集群需要被安全监控、规控、驱动等共用，虚拟化将为功能开发和运行提供明显助益。
内核系统虚拟化
内核系统虚拟化主要关注如下几个核心功能：
1. CPU
2. 内存
3. 中断
这几个方面ARMv8已经支持的相对完善，当前主流的Cortex-A系列CPU都含2层MMU功能，已经可以运行虚拟化的基础功能。当然，为了更好地获得安全隔离的需求，一般还会使用SMMU，给访问外设提供一个虚拟化的实现方式。
MMU和SMMU是地址虚拟化的经典解决方案。MMU协助CPU处理地址访问（操作系统，内核，进程）；SMMU协助外设处理地址访问（DMA，PCIe，GPU等）。MMU以及SMMU解决了3种地址空间的转换问题，从而为应用提供了独立的虚拟地址空间。
三种地址空间
1. 虚拟地址VirtualMemory，VA，在一个OS内，根据EL级别
- 又分成用户态和内核态VA，他们是不同的
- 用户态地址空间布局，是由OS内核营造的
- 每个进程地址空间总体结构都差不多，内容千差万别
- 进程认为它是在独占整个系统内存
2. 中间物理地址Intermediate PA，IPA
- 这是虚拟机认为的物理地址
- 这种物理地址的空间布局，是由虚拟机管理器营造
3. 实际物理地址PA
- 对于SoC芯片来说，这才是真正全局唯一的
虚拟地址的核心意义
长久以来，虚拟地址是现代大型操作系统的基本特征，目的之一是支持多用户，且用户之间保持独立。在ARMv8-A架构下，MMU是A核CPU的标准配置，但支持虚拟地址的DMA设备并不多。在虚拟化技术出现之前，地址翻译就是指从虚拟地址到物理地址的转换。引入了虚拟化技术后，翻译的过程变得更复杂，为方便理解，先不考虑虚拟化，下文就把经过这一步骤之后的地址称为物理内存地址，地址翻译是虚拟地址VA到物理地址PA。
通常，支持虚拟地址翻译的单元称为MMU，每个Cortex-A系列CPU核心都带一个MMU单元。而外设就不一定了，有2种方法支持地址翻译，一般一些复杂外设内置了MMU单元，对于普通外设我们使用SMMU。可以一个外设独占一个SMMU实例，也可以多个外设共享一个SMMU实例，这就是SMMU设计得如此复杂的一个原因。
当引入内存虚拟化后，地址翻译就需要分成Stage1，Stage2。
上述虚拟地址是Stage1，是操作系统用来隔离不同用户进程的，而Stage2是用来隔离不同虚拟机的。
其中Stage1和非虚拟化时的翻译过程是一样的。对于驱动开发人员来说，Stage2地址翻译过程是隐性的，大部分的驱动功能可以完全不用考虑这一过程，简化了对内存模型的理解。但是，如果需要处理多虚拟机之间，以及SoC异构系统之间的内存共享时，情况就会比较复杂。
设备虚拟化
设备的丰富性我们不能面面俱到所有实现，本文仅讨论比较关键的几个模块，希望可以举一反三，应用到其他设备上。
存储虚拟化
系统中存储器eMMC或UFS，存在多系统使用共享存储问题
1. 假如使用2个UFS存储器，各自用于一个虚拟机
2. 存储器不足分配时，Host作为后端，而Linux和Android使用前端虚拟设备
目前行业对此处理方式比较分化，有些整车公司倾向于使用单一存储器，给多个系统共享使用，有利于降低成本，但是增加了单一失效风险，且前后端模式对存储性能影响很大。也有一些整车公司坚持使用双存储器，以保证数据存储的安全可靠性和读写性能，但是会导致成本上升。这是一个技术、经济和安全性上需要权衡的问题。也许在不远的将来，支持虚拟化的存储控制器就会出现，可以较好地解决这个问题。
多媒体设备虚拟化
多媒体设备特点是多个设备组成pipeline，数据流在pipeline间依次处理，传递帧缓冲区handle，而不是多次拷贝数据。以下要求：
1. 多设备地址空间一致，通常统一使用物理地址
2. 帧缓冲区跨进程流动，需要考虑引用计数和安全回收问题
3. 内存管理不是模块级的，而是系统性设计
4. 需要使用全局的内存池，处理申请、释放请求，检查使用者等
尤其是视频设备，通常由多个处理单元组成管道，传递帧缓冲，隐性决定了这些多媒体处理单元要在一个OS中统一管理，如果跨多个虚拟机的话，无论从实现的难度，还是实时性和安全性上讲，都有较高的设计难度。
同时，从应用视角，多媒体设备一般不会被各子系统分时复用，往往是多个通道静态的被分配给不同子系统。因此比较适合选择使用多实例直通外设，或者硬件虚拟化外设。
加速引擎虚拟化
智驾系统对加速引擎的需求非常直接，例如ISP计算加速、AI加速。如果仅用于自驾的某一特定场景，则可以选择使用直通方式给智驾操作系统专用。
而ChatGPT的普及带来了新的可能性：AI可能在非智驾领域产生更多的应用场景。则AI处理能力的需求在整车中将更加多样化，对AI运算能力被“分拆”的需求可能加强。考虑到AI处理同样对数据流有较高要求，可能会朝“多媒体设备”类似的虚拟化方向发展。
HUIXI TECH
三、总结
在汽车智能化的驱动下，智驾系统芯片设计的思路是以前若干行业的综合：需要借鉴手机消费类芯片的多媒体处理能力和对运行模式和功耗等的精确控制；需要借鉴服务器芯片的对运算资源和数据带宽的合理规划和实现；需要满足汽车行业的功能安全等特性要求以及软件生态。这是一个规模和难度都巨大的技术方向。
引入虚拟化技术，对于自动驾驶芯片SoC设计是一个系统性的考量。为了实现安全的目标，以及多供应商、多技术维度的功能可以在资源获取上既保持灵活性，又保持隔离性，虚拟化是必备方案。
—END—
添加下方信加入汽专业交流群
（仅限专业人士，添加备注单位+姓名）
