关键场景及需求
场景
汽车电子E/E集中化，线束聚合的趋势下；自动驾驶/OTA等计算中心化的背景下，促使通过Hypervisor技术来支持一芯多系统
在智能座舱方案中，在一个SoC上同时运行包括娱乐，仪表和HUD等系统，存在如下问题，这也要求通过Hypervisor技术来支持一芯多系统
Mixed Criticality：和娱乐相比，仪表和Safety相关，需要实时性和确定性(ASIL-B)
Security：娱乐系统如果被攻击，不能影响仪表的功能
需求
Safety/Security隔离性保证：分为时间隔离/空间隔离；包括故障隔离，授权隔离等
实时性/确定性保证：通过Cache Coloring等手段支持确定性
复用/减少成本：代码复用，认证结果复用等
总结
在一个SoC上运行多系统是核心需求，需要通过Hypervisor来支持；本文目的在于决策自研Hypervisor的基线
一芯多系统 Hypervisor方案
方案：
基于Security Extension/SE：TrustZone-Assisted Hypervisor
VOSYSmonitor / RTZVisor / LTZVisor
基于Virtualization Extension/VE：Hypervisor
对比：后文在基于VE的Hypervisor方案中选择
业界方案 商业方案
车载商用方案包括：QNX / Green Hills(multivisor) / WindRiver / Mentor(Nucleus) / LynxSecure / ElektroBit (corbos / tresos) / VOSyS (VOSYSmonitor) / SYSGO (PikeOS) / Open Synergy (COQOS) / HARMAN(Red Bend) / Kernkonzept(L4Re) / XEN衍生(Perseus / Crucible/...) / ...
基本上是Type I型(可能原因：性能 + Safety认证，攻击面)的Embedded Hypervisor
开源选项 现状
汽车开源组织建议
AGL推荐
XEN / KVM / L4RE / ACRN
GENIVI Hypervisor Project建议
不针对Type I/II等做建议，尝试通过VirtIO等规范来确保Hypervisor能力在不同Hypervisor版本之间实现互操作
其它开源方案
开源选项 对比
目前看到如下的开源项目及其比较：
开源选项 XEN和Hafnium比较
Hafnium Hypervisor典型特征
安全模型：优先保证虚拟机之间内存隔离性；只保证Primary VM而不保证Secondary VM可用
内存虚拟化： Stage 2 Page Table / SMMU for DMA Access
CPU虚拟化：Primary VM的线程作为VM的vCPU，同时假设Linux/Android作为Primary VM，充分重用Linux的调度器(包括电源管理，Big.Little等场景)。缺点是：调度延迟较大
中断虚拟化：中断由Primary VM向Secondary VM注入，因此中断注入的延迟较大
XEN的嵌入式虚拟化改造
代码精简：1) XEN最初支持X86且用于服务器虚拟化，简化了大量代码(~1/6) 2) 消除设备模拟/QEMU相关依赖
Dom0-less支持：1) 支持DomU的快速启动(XEN+DomU的时间) 2) DomU完全脱离Dom0运行
TEE虚拟化支持：协调多虚拟机访问TA的能力(SMC指令的模拟)，实现包括内存共享，IPA到PA转化等工作
功能安全相关认证：1) 2019年成立功能安全工作组(FuSA SIG) 2) 定义了如何达成ASIL-B的路标 3) 定义了XEN需要遵从的MISRA C规则 4) 当前正在梳理安全认证的相关文档和文档维护流程 5) 和Zephyr项目一起开展安全认证工作
自研考虑及建议
技术可获得性风险：中美长期竞合的趋势/无国产替代的背景下，应避免卡脖子
外购成本昂贵：以QNX为例，各种授权费用昂贵导致单车成本高
软硬件方案的灵活性：Hypervisor和SoC基本是绑定关系，长期来看，不利于我司自研芯片的导入
功能定制的时间成本：商业软件功能的定制性较差，周期长
差异化竞争优势不足：商业软件功能稳定且同质化，不利于自研差异化的特色功能
建议
强调功能完整性：基于Hypervisor的成熟度，Safety认证的可能性等因素，建议基于XEN自研
强调分区隔离性：考虑Lisence等因素，建议基于Hafnium自研。但是其调度延迟和中断延迟较大；同时由于Hafnium不保证secondary VMs的可用性，这对于车载场景是较大的风险
综合考虑：基于XEN自研
