4. 资源分区与隔离：CPU/GPU/内存分区、中断虚拟化、IOMMU/SMMU配置
资源分区与隔离，说白了就是让多个虚拟机（VM）在同一个硬件平台上“和平共处”，互不干扰。你想想看，智能座舱里既要跑仪表盘（安全关键），又要跑中控娱乐（非安全关键），还得让它们共享一颗SoC。如果隔离没做好，中控卡顿一下，仪表盘也跟着黑屏——那可就出大事了。
我个人习惯把资源隔离分成三个层次：计算资源（CPU/GPU）、内存资源、设备访问资源（中断、DMA）。下面我们一层层拆开讲。
4.1 CPU分区：别让VM抢核
CPU分区是最基础的隔离手段。Hypervisor通过虚拟CPU（vCPU）的调度策略，把物理核固定分配给某个VM。我建议的做法是：安全域（仪表盘、ADAS）用独占核，非安全域（娱乐、导航）用共享核。
| 分区策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 独占核（Pinning） | 仪表盘、ADAS | 零调度延迟，性能可预测 | 核利用率低，浪费算力 |
| 共享核（负载均衡） | 娱乐、导航 | 核利用率高，灵活 | 存在调度抖动，不适合硬实时 |
| 混合分区 | 多域共存 | 兼顾安全与效率 | 配置复杂，需精细调优 |
4.2 GPU分区：虚拟化图形管线
GPU分区比CPU麻烦得多。GPU本身是个“大黑盒”，内部有几百个着色器核心，传统虚拟化很难做到硬隔离。目前主流方案有两种：
- GPU直通（Passthrough）：把整个GPU物理设备直接分配给一个VM。优点是性能最好，缺点是一个GPU只能给一个VM用——座舱里仪表和中控都要用GPU，怎么办？
- GPU虚拟化（SR-IOV / Mediated Passthrough）：通过硬件辅助，把GPU切分成多个虚拟功能（VF），每个VM拿一个VF。Intel GVT-g、NVIDIA vGPU都是这个路子。
我在项目中遇到过一个问题：用GPU直通给仪表VM后，中控VM想用GPU做导航渲染，结果只能走软件渲染，帧率惨不忍睹。后来改用Mediated Passthrough，两个VM各拿一部分GPU资源，才把问题解决。
4.3 内存分区：硬件级的“防火墙”
内存隔离是安全的基础。Hypervisor通过第二阶段地址转换（Stage-2 Translation）来实现——每个VM看到的“物理地址”其实是中间物理地址（IPA），Hypervisor再把它映射到真正的物理地址（PA）。
我建议的内存分区策略：
- 静态预留：安全域的内存区域在启动时就固定下来，不允许动态调整。
- 动态分配：非安全域的内存可以从一个共享池里按需分配，但必须保证不超过上限。
- 内存气球（Ballooning）：通过Guest内部的驱动，把空闲内存“借”给Hypervisor，再分配给其他VM。但要注意——安全域绝对不能参与气球操作，否则可能被恶意Guest“饿死”。
// 伪代码：内存分区配置示例
struct mem_partition_config {
vm_id_t vm_id;
uint64_t base_pa; // 物理基地址
uint64_t size; // 分区大小
bool is_secure; // 是否安全域
bool allow_balloon; // 是否允许气球操作
};
// 仪表盘VM：静态预留，不允许气球
mem_partition_config dash_vm = {
.vm_id = 0,
.base_pa = 0x80000000,
.size = 0x20000000, // 512MB
.is_secure = true,
.allow_balloon = false
};
// 中控VM：动态分配，允许气球
mem_partition_config infotain_vm = {
.vm_id = 1,
.base_pa = 0xA0000000,
.size = 0x40000000, // 1GB
.is_secure = false,
.allow_balloon = true
};
4.4 中断虚拟化：别让中断“串门”
中断虚拟化是资源隔离里最容易出坑的地方。我曾经遇到过一个Bug：中控VM的触摸屏中断，莫名其妙地触发到了仪表VM的看门狗定时器——结果仪表盘直接复位了。排查了三天，才发现是中断路由表配置错了。
中断虚拟化的核心机制：
- 中断控制器虚拟化（vGIC/vAPIC）：Hypervisor截获Guest对中断控制器的访问，把物理中断映射到虚拟中断。
- 中断路由表：每个物理中断都要明确指定它应该被路由到哪个VM的哪个vCPU。
- 中断注入：Hypervisor通过写vCPU的寄存器，把虚拟中断“注入”给Guest。
4.5 IOMMU/SMMU配置：DMA的“交通警察”
IOMMU（或ARM体系下的SMMU）是设备DMA访问内存的“交通警察”。没有它，一个恶意的设备驱动可以直接读写任意物理内存——那隔离就形同虚设了。
IOMMU的工作原理：
- 设备发起DMA请求，带上设备ID（如PCIe的BDF号）。
- IOMMU根据设备ID查找对应的页表，把设备看到的“设备地址”翻译成物理地址。
- 如果翻译失败（比如设备试图访问不属于它的内存区域），IOMMU直接阻断DMA，并上报错误。
我建议的SMMU配置要点：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Stream ID | 每个设备一个唯一ID | 用于区分不同设备的DMA请求 |
| 页表粒度 | 4KB 或 64KB | 4KB粒度更灵活，64KB TLB命中率更高 |
| 安全域设备 | 静态映射 | 启动时固定，不动态修改 |
| 非安全域设备 | 动态映射 | 按需分配，用完回收 |
| 错误处理 | Fault上报 + VM复位 | 一旦检测到非法DMA，立即隔离 |
4.6 整体架构图：资源隔离的“全景视图”
下面这张图展示了CPU、GPU、内存、中断、IOMMU五个维度的隔离关系。你可以把它当作一个“检查清单”——做资源分区时，每个维度都要覆盖到。
嗯，这张图把整个资源隔离的层次关系讲清楚了。从上往下看：VM通过Hypervisor访问资源，Hypervisor负责调度和映射，IOMMU/SMMU在底层做DMA保护。每一层都不可或缺。
4.7 实战建议：从配置到验证
最后，我总结几条实战中的建议：
- 先做静态分区，再做动态调整：安全域的资源在项目初期就固定下来，不要等到集成测试时再改。
- 中断路由表要“白名单”思维：只允许明确授权的设备中断路由到安全域，其他一律阻断。
- IOMMU/SMMU配置要写进启动脚本：不要手动配置，否则一次重启就全丢了。
- 做压力测试：让非安全域跑满CPU、GPU、内存带宽，观察安全域的响应时间是否还在容忍范围内。