Hypervisor / 混合关键度整合深度 — 共核 FFI / 多核干扰 / hypervisor 资质

E/E 架构演进的终点是算力集中:分布式 100+ ECU → 域控(动力/底盘/座舱/ADAS 各一域)→ 区域控制 + 中央计算。把多个 ECU 合到少数高性能多核 SoC(CPU 多核 + GPU/NPU),BOM/线束/重量全降。

代价:不同 ASIL 被逼共享一颗芯片。ISO 26262 的铁律——混合等级共存,要么全按最高 ASIL 开发(QM 的娱乐代码也按 ASIL-D 做,成本爆炸),要么证明 FFI:低 ASIL/QM 失效不污染 ASIL-D。整合的全部工程难点,就是在一颗多核 SoC 上把 FFI 做扎实——比单 ECU 难,因为共享资源多、干扰通道多。

FFI 页 讲的是单核/单 OS 内的分区(MPU 内存分区 + OS 时间切片 + Safety OS 底座)。多核 SoC 上要让多个不同 OS(AUTOSAR Classic 跑 ASIL-D 控制 + Linux 跑 QM 座舱)共存,载体升级为 Hypervisor:

• type-1(裸机)hypervisor 直接跑硬件上,把 SoC 分成多个 VM/partition,各跑各的 OS
• 空间隔离:硬件虚拟化(ARMv8 EL2 + stage-2 二级地址翻译 / SMMU)+ core 静态分配,VM 间内存/外设互不可见
• 时间隔离:hypervisor 调度器分配 core 时间 + 资源配额
• guest 形态:RTOS/AUTOSAR guest 常走 para-virtualization(改 guest 配合 hypervisor,开销小、时序确定);Linux/Android guest 走 full virtualization(不改 guest,开销大)——混合 ASIL 里 ASIL-D guest 偏 paravirt 求时序确定
• 关系:FFI 是 ISO 要求(共存的硬要求在 26262-9 Clause 6「Criteria for coexistence of elements」;26262-6 Annex D[informative] 给软件 FFI 的三类机制:时序-执行 / 内存 / 信息交换;FFI 页 再拆成工程四维);Safety OS 是单 OS 载体;hypervisor 是多 VM 载体,把"OS 内分区"升到"VM 间分区"
• 商用:QNX Hypervisor / Vector / ETAS RTA-HVR / OpenSynergy COQOS / PikeOS(SYSGO)

空间隔离(MMU/SMMU)相对好做。难的是时间隔离——多核共享物理资源会互相拖慢,VM-A 的执行时间被 VM-B 的行为影响:

• 共享 LLC(末级 cache):一个 core 狂刷 cache 把另一 core 的数据挤出 → cache miss 暴涨 → 执行时间膨胀
• DRAM 控制器 + 内存总线:多 core 争 DRAM 带宽,访存排队 → 延迟随其他 core 的负载变
• interconnect / NoC:片上互联争用
• 共享外设 / DMA:DMA 抢总线、外设寄存器争用

这些是时间干扰通道:它们让 ASIL-D 任务的执行时间不再只取决于自己,QM core 一忙就可能饿死(starvation) ASIL-D → 错过 deadline。空间隔离防不住这类**"合法但拖慢"**的干扰。

多核 FFI 的核心思路:别让资源动态争用,改成静态配额,让干扰可界定:

• cache 分区:way-based partitioning / page coloring → 给 ASIL-D VM 独占 cache way,不被 QM 挤出(page coloring 的代价:占用页分配自由度、与大页冲突、需 OS 介入)
• 内存带宽调控:MemGuard / bandwidth regulation → 给每 core 配带宽配额,限 QM core 的访存速率,保 ASIL-D core 的带宽
• DRAM bank 分区:不同 core 用不同 bank,减 row-buffer 冲突
• core 静态独占:ASIL-D VM 独占 core(不与 QM 共 core),消核内抢占干扰
• 外设/DMA 静态分配:每 VM 固定外设,DMA 通道隔离

把"动态争用"变"静态配额"后,ASIL-D 的最坏访存延迟才有上界 → 时间 FFI 才成立。

时间 FFI 要落到 WCET(最坏执行时间) 的可界定上:

• 单核 WCET:静态分析(抽象解释 bound loop/path)或基于测量,假设无外部干扰,能给 sound 上界
• 多核:其他 core 的干扰让任意一次访存延迟不可预测 → WCET 要么暴增到不可用(按全干扰最坏估)、要么无法 sound bound
• 出路:先用 §4 的静态配额把干扰封住上界(cache 独占 + 带宽配额),再做 interference-aware WCET——在"干扰被配额限死"的前提下才能给可用的 WCET。没有配额隔离,多核 WCET 谈不上

这就是为什么"先隔离、再算 WCET",顺序反了(先按裸多核算)会得到无意义的天文数字。

最关键的一点:Hypervisor 本身是隔离的强制者——所有 partition 的空间/时间 FFI 都由它实施。它一旦失效,全盘隔离失效 = 整个混合关键度论证塌掉 = 单点失效。

• 故 hypervisor 必须按最高共存 ASIL(通常 ASIL-D)开发 + 资质,作为 SEooC(独立于上下文的安全元素)
• 配置也是安全相关:分区表 / 调度参数 / cache 分区 / 带宽配额——配错了 FFI 就破,配置须按 ASIL-D 管控 + 验证
• hypervisor 提供 safety manual(AoU):集成方必须怎么配 cache/带宽/调度/外设分配才保 FFI
• 陷阱:用一个 QM 的开源 hypervisor 跑 ASIL-D 共存 = 隔离没有资质背书 = FFI 论证无效

本节用一个具体的 EV 网关域控制器说明如何落地时间 FFI。目标:证明 ASIL-B 制动扭矩监控任务在 QM 负载最坏情形下仍满足 500 µs deadline;同时保留 QM Linux partition 运行 OTA/连接栈。

平台: 4× ARM Cortex-A55 @ 1.2 GHz,4 MB LLC(8-way 组相联),LPDDR4-3200 单通道 12.8 GB/s
Hypervisor: QNX SDP 7.1 type-1 bare-metal,已认证 ISO 26262 ASIL B(D) SEooC
VM1:Core 0-1 静态独占,QNX Neutrino RTOS para-virt guest,ASIL-B 功能(制动扭矩监控 + EPS 状态上报)
VM2:Core 2-3 静态独占,Linux 6.6 full-virt guest,QM(OTA 客户端 + 以太网连接栈)

混合关键度整合翻车几乎都发生在三类认知盲区:把空间隔离等同于 FFI、把单核 WCET 方法直接套用多核、以及低估 hypervisor 本身的安全要求。

G1 — 以为 MMU/MPU 空间隔离就完成了 FFI。空间隔离阻断的是内存读写越界,与时间干扰正交。共享 LLC/DRAM 控制器/NoC 的时间争用在地址空间完全隔离的情况下依然存在:VM2 大量 cache miss 把 VM1 的工作集挤出 LLC,VM1 的每次访存退回 DRAM,执行时间随 VM2 负载随机膨胀。Step 3 的量化显示膨胀 1.67 倍——不做 cache/带宽分区,空间 FFI 只说明了 26262 三维中的"内存",时间维度和信息交换维度均未覆盖。

G2 — 用单核 WCET 方法直接套多核。单核 WCET 工具(rapitime、aiT、Bound-T 等)假设 cache 状态完全由当前任务决定,miss penalty 是确定值。多核下任何一次访存延迟都依赖其他 core 的实时行为:LLC 命中/未命中不可静态预测 → 工具输出是无意义的天文数字,或者严重低估(把 cache 当全命中)。正确做法:先用 §4 的静态配额(way 分区 + MemGuard)把干扰上界封死,再做 interference-aware WCET——"先隔离再算 WCET"而不是"先算再隔离"。

G3 — page coloring 实现不配套、与大页冲突。page coloring 是 way 分区的软件替代:通过操纵物理地址 bit[n:m] 控制 cache 映射 way,不依赖硬件 way bitmap。但它要求 OS 内存分配器全面参与 → guest OS 须改造(与 full-virt Linux 冲突);使用 hugepages(2 MB/1 GB)时 page color 无法以 4 KB 粒度对齐 → 颜色扩散进错误 way,隔离失效。硬件 way bitmap(本页 Step 4 路径)对 guest OS 透明,是多 OS 共存场景的唯一实用选项。

G4 — 用无资质的开源/QM hypervisor 跑混合 ASIL。AUTOSAR Adaptive、Xen、KVM 等开源 hypervisor 在汽车领域无 ISO 26262 资质证书。Hypervisor 是隔离的单点(§6):它失效则全盘 FFI 塌。按 ISO 26262-9 §6 "Criteria for coexistence of elements",隔离机制本身必须按最高共存 ASIL 开发——即 ASIL-D 环境需要 ASIL-D(D)资质 hypervisor,ASIL-B 环境需要 ASIL-B(D)。把未资质 hypervisor 写进安全案例,FMEA 评审一眼打穿。

G5 — 把 hypervisor 配置当运行时参数、不纳入安全相关管理。way bitmap、MemGuard cap、CPU affinity 是 FFI 论证的数学前提——改了 way bitmap 就改变了 Step 3 中 $h_{\text{iso}}$ 的值,整个 WCET 分析需要重算。配置须版本控制 + ASIL-B review + ASIL-B 工具链编译 → buildfile 是安全工作产品(safety element),不是运维参数。发现量产项目把 hypervisor buildfile 放在 QM repo、没有变更影响分析的情况相当常见。

G6 — 共享外设/DMA 通道不显式分配给 VM。PCIe 控制器、Ethernet MAC、USB host 等外设即便已被 SMMU 做了 IO 地址隔离,DMA 控制器依然争占 DRAM 总线带宽。VM2 中 Linux 的 OTA 下载(峰值 80 MB/s)会在 MemGuard 窗口内占用 DMA 带宽,等效于提高 $t_{\text{DRAM}}$、降低 MemGuard 的有效保障。正确做法:把 DMA 带宽估算计入 MemGuard QM cap 的计算(将 DMA 带宽与 VM2 CPU 访存带宽合并核算)。

G7 — ASIL-B VM 接受 QM VM 的 IPC 消息而不做 E2E 校验。当 VM2 向 VM1 传递数据(如路由更新、标定参数),VM1 直接读 QM 的消息相当于引入了"信息交换干扰通道"——ISO 26262-6 Annex D 分类的第三维。QM 软件 bug 或被攻击后可注入非法帧,污染 VM1 的计算输入。FFI 要求:VM1 只允许接收按 E2E profile 保护(CRC + 计数器)的消息,并在上层软件校验 counter 连续性;任何跳帧、超时或校验错 → VM1 忽略并上报 DTC。

混合关键度整合的边界工况多数在动态事件下出现:QM 突发、冷启时序、OTA 大流量。

C1 — QM OTA 下载峰值导致 MemGuard 窗口对齐抖动。MemGuard PMU 窗口 1 ms 与 OTA TCP 接收 burst 不对齐:OTA 突发发生在窗口的前 200 µs,带宽峰值远超 4.0 GB/s cap。PMU 在 200 µs 内触发 throttle → QM core 被 stall → OTA throughput 下降(可接受);但 throttle 中断路径经 hypervisor 执行,若中断延迟 > 100 µs 则 QM 在窗口首尾获得短暂超额带宽 → VM1 DRAM 延迟出现脉冲性上升。缓解:窗口缩短到 250 µs(4 ms 内 16 个窗口),cap 同比缩至 1 GB/s/窗口;或者调整 TCP receive buffer 把 OTA 突发平滑到 <3.5 GB/s 持续带宽。

C2 — 冷启阶段 hypervisor 初始化期间 ASIL-B VM 上电延迟与 FTTI 约束。Hypervisor 完成 partition 初始化(加载 VM 映像、配置 MMU/SMMU/MemGuard)约需 350–500 ms。这段时间 VM1 未运行 → ASIL-B 功能不可用。如果 FTTI = 20 ms(制动 torque monitor 的典型值),cold-start 初始化 500 ms 期间 HV 已上电并可能收到驾驶指令 → 违反 FTTI。正确做法:安全架构应定义 "ASIL-B 功能可用 deadline" 早于 HV 上电使能;hypervisor 平台须支持 VM1 优先快启(fast-path boot,典型 < 50 ms),把 OTA/connectivity 的 VM2 留在后台慢启。

C3 — EOL 阶段 QM VM 运行内存压力测试导致时间 FFI 破坏。EOL(end-of-line)工厂测试常在 QM partition 中运行内存密集型诊断脚本,LLC way 4–7 被 diagnostic 频繁刷新 → way-coloring 和 way bitmap 的完整性前提被动态压力测试破坏,等效于 Step 3 中 $h_{\text{iso}}$ 短暂降回 80%。如果此时 ASIL-B VM 恰在运行安全关键监控任务,WCET 瞬间超出 deadline。缓解:EOL 测试 profile 中 ASIL-B VM 须 hold(暂停监控任务)或 EOL 脚本写入 way bitmap 必须限制在 VM2 分区(way 4–7)内,不得越界访问 VM1 的 way 0–3。