SA8397P 软件架构深度拆解：PVM + GVM 怎么在单芯片上共存

• 硬件底子速览
• 软件架构：Gunyah Hypervisor + PVM + GVM
  • 架构全景
  • Android 作为 GVM 是怎么跑起来的
  • PVM 安全域：仪表盘为什么不跑 Android
  • PVM 和 GVM 互不干扰，靠的不是一句"虚拟化"
  • PVM ↔ GVM 怎么通信？
  • 座舱 Android 开发到底跟手机开发差在哪
• 产业棋局：高通的一盘大棋
• 结论

本文首发地址 https://h89.cn/archives/615.html

做了几个月 SA8397P（Snapdragon Cockpit Elite）座舱 Android 开发，最大的感受不是高通这次堆了多少算力，而是：GVM 里的 Android App 旁边，PVM（Protected VM）安全域里跑着另一套随时不能挂掉的操作系统。 搞懂了 PVM 和 GVM 怎么共存，才算真正理解这块平台的软件架构。

！封面

硬件底子速览

先花一点篇幅把硬件交代清楚，后面重点在软件。

这里有个高通很熟的打法：SA8397P（Cockpit Elite）和 SA8797P（Ride Elite）是同一颗物理 Die，通过软件锁核做 SKU 区分。 8397 锁掉部分 ADAS 核心，专注座舱场景；8797 开放全核，支持舱驾融合。当年 SA8255/SA8775 也是类似路数。

锁了一部分核心的 8397 还剩多少资源给座舱？公开资料多称它采用 18 核 Oryon，NPU 算力行业口径约 320 TOPS，并支持 14B 参数级别的端侧大模型。至于大小核划分、内存位宽、R52 核心数这类细节，高通官方披露并不完整，工程上更该关注的是：这些资源怎么分给 PVM 和 GVM（Android），才是软件开发真正要面对的问题。

软件架构：Gunyah Hypervisor + PVM + GVM

架构全景

SA8397P 的标准软件方案是 Gunyah Type-1 Hypervisor + PVM + GVM 异构部署。Gunyah 是高通自研的开源 Type-1 Hypervisor，直接跑在裸金属上，上面挂两个虚拟机：

┌──────────────────────────────────────────────────────────┐
│              SA8397P  座舱域控 软件架构                    │
│                                                           │
│  ┌──────────────────┐  ┌──────────────────┐  ┌─────────┐│
│  │     PVM           │  │    GVM #1        │  │ GVM #2  ││
│  │   (安全域/Linux)  │  │   (Android)       │  │ (可选)  ││
│  │                   │  │                   │  │AI OS   ││
│  │  仪表盘 · HUD     │  │  IVI · 导航       │  │NPU推理 ││
│  │  安全警报 · 360   │  │  语音 · 应用生态  │  │实时    ││
│  └────────┬─────────┘  └────────┬─────────┘  └───┬─────┘│
│           │                     │                  │      │
│           ▼                     ▼                  ▼      │
│  ┌──────────────────────────────────────────────────────┐ │
│  │  Type-1 Hypervisor (Gunyah，高通自研)                     │ │
│  │                                                       │ │
│  │  CPU 核心隔离  │  GPU 虚拟化  │  SMMU  │  VirtIO     │ │
│  └──────────────────────────┬───────────────────────────┘ │
│                              │                             │
│                              ▼                             │
│  ┌──────────────────────────────────────────────────────┐ │
│  │                      物理硬件                         │ │
│  │                                                       │ │
│  │  18核Oryon · Adreno 7 · NPU 320TOPS · R52安全岛      │ │
│  │  LPDDR5X 273GB/s · UFS 4.0 · PCIe 5.0                │ │
│  └──────────────────────────────────────────────────────┘ │
│                                                           │
└──────────────────────────────────────────────────────────┘

量产方案里，通常会把两类负载拆开：
PVM 安全域（Protected VM，运行安全 Linux） 跑仪表盘、HUD/AR-HUD、ADAS 安全警报、360 环视。这些功能的特点是「不能挂」。仪表盘显示车速的延迟抖动超过几十毫秒就是安全事件，所以必须上硬实时或准实时 OS。

GVM（Guest VM/Android） 跑 IVI 信息娱乐、导航、语音助手、第三方应用生态、游戏视频等。这些功能挂了最多被车主骂，不会出人命。

Gunyah 不限制 VM 数量，两个只是默认配置。资源充裕时还可以拉一个 GVM #2（AI OS 专用 VM），跑轻量 Linux + 推理运行时（QNN/SNPE），直接管理 NPU 做多路摄像头实时推理和端侧大模型。独立 VM 隔离 AI 负载，避免跟 Android 抢 GPU/NPU 带宽，推理延迟更可控。

Android 作为 GVM 是怎么跑起来的

我们自己搞座舱 Android 开发，最容易忽略的一个事实是：你写的 App 不是直接跑在硬件上，是跑在 Gunyah Hypervisor 的 GVM（Guest VM）里。

换句话说，Android 看到的「硬件」并不是裸设备——CPU 核心来自 Hypervisor 的分配，内存区域由 SMMU 隔离，GPU 访问也要经过虚拟化层。

但关键点在于，Android Automotive OS 不需要为 Hypervisor 重写整套系统。 Gunyah 实现了 VirtIO 标准接口。VirtIO 是一套半虚拟化 IO 标准，Hypervisor 通过它向前端虚拟机暴露标准化的虚拟设备。Android 内核本身已有 VirtIO 支持，所以 Guest OS 侧不必为了虚拟化从零做一套 IO 驱动。

这件事对 OEM 很现实：不用为了上 Hypervisor 维护一个地狱版 Android Fork。但量产车机还是绕不开 BSP、HAL、显示/音频/相机链路和车载服务适配。高通把 Gunyah Hypervisor 与虚拟设备接口打通，Android 侧才能尽量靠近标准开发体验。

PVM 安全域：仪表盘为什么不跑 Android

这个问题我刚接触座舱开发时也问过。

原因并不复杂：Android 不是硬实时系统。 你调试过 Android 渲染管道就知道，GPU 帧合成、SurfaceFlinger 的调度、甚至 GC 都能让 UI 线程卡住几十毫秒。手机上微信卡一下你忍了，仪表盘上时速 120 时指针卡了半秒——不行。

PVM 里跑的 Safety Linux 带 PREEMPT_RT 内核抢占补丁和功能安全扩展，调度延迟可以控制在亚毫秒级。虽然不是 QNX 那样的微内核 RTOS，但配合 CPU 核心独占或强绑定，中断响应延迟仍然有可控的边界。仪表盘指针刷新、HUD 投影这类东西，要的就是这种确定性。

实操里还有个反直觉的点：仪表盘那套 3D 界面，并不意味着 PVM 必须独占整颗 GPU。 更常见的做法是 Hypervisor 对 GPU 做虚拟化或分区，不同 VM 拿到受控的 GPU 访问能力；安全域的显示路径和关键时序由 PVM 侧保障。

PVM 和 GVM 互不干扰，靠的不是一句"虚拟化"

Hypervisor 只是总开关。PVM 安全域和 GVM（Android）不互相拖死，靠的是下面这几层硬隔离。

第一层是算力资源隔离。PVM 安全域需要确定性，所以 CPU 核心通常会做独占或强绑定，实时任务不会跟 Android 应用抢同一批调度资源。Android 侧就算有 App 把 CPU 打满，也不能把仪表盘刷新拖死。

第二层是内存和设备隔离。SMMU（System Memory Management Unit，系统内存管理单元）相当于硬件级内存防火墙，限制每个 VM 能访问哪段物理内存。GPU 虚拟化也是同一个思路——Hypervisor 给不同 VM 划出可控的渲染通道和带宽边界，避免争抢。

第三层是通信接口收敛。Android 侧不直接碰底层设备，标准 IO 走 VirtIO；跨 VM 的大数据交换走共享内存或 HAB 这类封装好的通信框架。这样做牺牲了一点"裸奔性能"，但换来的是边界清晰、问题可定位。

外面还有 R52 安全岛兜底。它不是 Android 里的一个服务，也不是 PVM 里的一个进程，而是独立的 Cortex-R52 核心组，负责系统级监控和故障处理。说人话就是：你可以在 Android 侧作死，但别想把仪表盘一起带走。

PVM ↔ GVM 怎么通信？

两套独立 OS 不可能完全各玩各的。比如 Android 的导航路线要投射到仪表盘上显示，用户在中控屏调节空调温度要在仪表盘上同步反馈——这都涉及跨 VM（PVM ↔ GVM）通信。

通信路径通常是两种：

• 共享内存（Shared Memory）：Hypervisor 分配一段两块 VM 都能访问的共享内存区，适合大数据量的低延迟传输（比如导航地图数据）
• 虚拟网络/虚拟串口（VirtIO-net/VirtIO-serial）：通过虚拟设备走标准网络协议栈或串口通信，适合事件、状态变更等轻量消息

高通在共享内存这块提供了自己的方案——HAB（共享内存通信框架）。相比直接用裸共享内存，HAB 封装了通道管理、多路复用、同步原语等，省掉了不少底层协议层的开发工作。对 GVM（Android）侧来说，通过 HAB 的 lib 接口就能跟 PVM 侧通信，不用关心物理内存布局和对齐细节。

实际项目里通常封装一个跨 VM IPC 框架，底层用什么传输对上层应用透明。对 GVM 中的 Android App 开发者来说，调用的是一个 SDK 接口，数据从 AIDL 出去，底层 Hypervisor 帮你路由到 PVM 侧。

座舱 Android 开发到底跟手机开发差在哪

做了几个月，几个体感最明显的差异：

性能预期要先改。 手机 Android 默认整颗 SoC 都是你的，跑分看总分。座舱 Android 不行——部分 CPU、GPU、内存带宽会预留给安全域和系统服务。性能优化不再是你用了多少，而是你被分了多少、你省了多少。

启动时间也不是只看 Android。 车机讲究点火即用，从 Hypervisor 启动、PVM 里的 Safety Linux 起来、Android 起来，到仪表盘和 IVI 全亮，整条链路都要纳入启动预算。具体数据不方便写，但手机 Android 的冷启动优化经验在这里只能复用一部分，Hypervisor 引导和 PVM 先启动的时序会直接影响 Android 的 init 窗口。

HMI 一致性会被低估。 仪表盘是 PVM 渲染的，中控屏是 GVM（Android）渲染的，但用户眼里这是一整套车机——色温、字体、动效、交互反馈都得一致。Android 侧的设计语言要配合 PVM 侧，连过渡动画的缓动曲线都得对齐。这个对齐不是设计师出张图就能解决的，两个渲染管线底层的差异会让同一段动画在两端看起来不一样。

调试链路会变长。 手机开发 debug 大多先看 adb logcat，座舱 Android 问题排查要多绕好几层——GVM Android App 层、Framework 层、VirtIO 驱动层、Hypervisor 层、PVM 端应用层，问题可能在任一环节。一个仪表盘不更新的 bug，根因可能只是跨 VM 共享内存没配对。

一个实战案例：端侧大模型集成。 我们项目接入过第三方端侧大模型，跑在 Android 侧，做车内感知和用户身份校验这类场景。

看起来就是个 App 内调用模型推理的事对吧？一跑就踩坑。

第一坑是模型加载时机。端侧模型加载需要几秒钟，如果在 Android 系统还没完全就绪就触发加载，容易和系统初始化抢 IO 导致 ANR（应用无响应）。后来改成 Android 启动后期异步加载，前台配一个加载状态屏——但问题来了，这个状态屏的工期评估里，我们一开始根本没算 Hypervisor 层和 PVM 的启机时间对 Android 侧启动窗口的影响。

第二坑是NPU 推理的实际表现。SA8397P 的 Hexagon NPU 纸面算力很高，模型做 INT8 量化后，单次推理延迟可以压到可用范围内。但车内摄像头多路并发输入一上来，NPU 的上下文切换开销就比预期大很多——不是算力不够，是调度策略不够细。后来靠供应商工具链做算子融合和模型剪枝，才把延迟压下来。

最意外的是跨 VM 通信延迟。身份校验场景需要 Android 侧的模型推理结果同步给 PVM 侧的仪表盘做状态提示，走共享内存。看上去就是一次数据拷贝，但 PVM 和 Android 两边对 cache、内存屏障和共享内存映射的处理方式不同，第一次跨 VM 读取经常多出十多毫秒。后面只能把共享内存区提前映射、提前预热，再显式处理 cache flush/invalidate 和内存屏障。

你看，一个「调用端侧大模型」的需求，实际落地时要面对的是 Android 启机时序、NPU 调度策略、跨 VM 内存一致性问题——这三个东西分属三个不同技术域，但任何一环出问题你的功能就是跑不稳。

产业棋局：高通的一盘大棋

SA8397P 的软件生态体现了高通的垂直整合野心：

• 高通提供全栈：Gunyah Hypervisor（开源，自研）+ Qualcomm Safety Linux（PVM 内的安全 OS）+ BSP + AI 工具链
• Android Automotive 作为 GVM 仍然是第三方的（谷歌提供）
• Tier-1 方案商在此基础上做集成：

Tier-1 方案商已经跑在前面的：

• 中科创达：滴水 AIOS 2.1，原生 AI 座舱 OS，14B 端侧大模型
• 斑马智行：全模态端侧大模型方案，主动智能、情景对话
• 博泰（PATEO）：基于 QAM8397P 的新一代座舱方案，已获头部车企定点
• 哈曼（Harman）：CCU 平台研发中，2026 下半年量产就绪

车型进展可以先按公开信息看：奇瑞捷豹路虎 FREELANDER 神行者 CONCEPT 97、零跑 D19/D99 已经有至尊版平台展示或搭载信息，哈曼、华勤、元戎启行也在推量产方案。据称奔驰、宝马、上汽通用、蔚来、理想也在筹备相关量产方案。能确定的是，SA8397P/8797 的生态推进比上代更快。

结论

回到标题：一块芯片上同时跑 PVM 和 GVM（Android），靠的是 Gunyah Type-1 Hypervisor 做硬隔离，PVM 作为安全域运行 Safety Linux，GVM 运行 Android，再用标准化通信接口把该连的地方连起来。把两个系统塞进同一个 SoC 只是第一步，隔离和通信这两件事缺一件，车机都会变成灾难现场。

如果你是做座舱 Android 的，别只盯着 App 层：

• 别按手机 Android 的假设写。CPU 核数、GPU 带宽、内存带宽都不是全给你的
• 先问清楚跨 VM 通信怎么走。SHM 还是 VirtIO，延迟和带宽天花板在哪，会直接影响交互设计
• 性能优化别只看 Android 指标。有时候瓶颈不在 App，也不在 Framework，而是 Hypervisor 层的资源分配

SA8397P 的 NPU 很诱人，端侧大模型也确实能跑。但在车上，跑起来只是第一关。更难的是别抢 PVM 资源、别拖慢启机、别让跨 VM 通信偶发抖动。端侧大模型这条路能走，只是别被 TOPS 数字骗了，真正的坑都在系统边界上。

本文硬件规格数据来源：高通官方产品页 [1]、Gunyah Hypervisor 文档 [2]、2026 北京车展多家 Tier-1 公布的适配进展 [3]。高通官方主要披露性能提升比例和平台能力，具体 CPU 核心划分、NPU TOPS 口径、内存带宽、安全岛核心数等来自行业分析交叉验证，非高通官方完整规格表。

[1] https://www.qualcomm.com/automotive/products/elite
[2] https://github.com/quic/gunyah-hypervisor
[3] https://i.gasgoo.com/news/70455382.html