引言
汽车、航天、交通、电力等安全攸关的多OS混合部署场景对“确定性时延、强隔离、安全可靠、快速启动与可管理性”提出了高要求。以Linux为特权域（Domain0）的虚拟化架构常因跨特权级控制路径、上下文切换与I/O转发链路过长而引入额外开销与抖动，难以保证实时性。ZVM是一款以“RTOS原生虚拟化”为核心设计理念的Type 1 Hypervisor，将实时内核与虚拟化核心融合并运行于EL2层，以更短的控制路径、更少的代码规模与可预期的调度/中断行为，为嵌入式实时系统提供面向工程落地的多OS混合部署底座。本文对ZVM的关键系统设计进行解析，并与Xen、Xvisor、Jailhouse、QNX Hypervisor等典型Hypervisor方案从架构设计、内核隔离方式、外设虚拟化、工具链及测试系统等维度进行对比，最后给出ZVM-RK3588发行版运行RTOS时的性能指标数据。
一、ZVM系统设计解析
1. 架构：RTOS原生虚拟化架构
Xen与Jailhouse等Hypervisor在启动与管理流程中通常需要依赖运行于EL1层的Linux（特权域/Domain0）完成硬件与系统初始化，Hypervisor运行于EL2层，二者跨特权级交互会引入额外的上下文切换与控制路径开销，从而限制性能上界并放大时延抖动。
ZVM采用了完全抛弃Domain0的“RTOS内核 + 原生虚拟化”的融合设计，由实时内核自身完成硬件与系统初始化并启动ZVM及客户OS。无论处理器支持VHE还是nVHE，实时内核与虚拟化核心均统一集成并运行于EL2 层，这正是依靠ZVM中自研的HyperVHE（超级VHE）统一了VHE与nVHE。相比之下，QNX Hypervisor与KVM仅在支持VHE的处理器上才能实现全栈 EL2 运行，在 nVHE 模式下的初始化内核仍需运行于EL1层。ZVM所采用的RTOS原生虚拟化一体化架构具备如下优势：
-
代码规模小：ZVM实时内核与虚拟化核心代码量＜4万行（支持对进行实时内核深度裁剪）；包含BSP等子系统总代码量＜10万行。
-
启动快：上电到ZVM启动＜600 ms；上电到ZVM启动再到客户RTOS启动＜3秒。
-
性能优：相较业界公认性能优异的Jailhouse，ZVM整体性能提升＞30%，显著改善ARMv8.0虚拟化性能瓶颈。
-
高效通信：自研Zshm共享内存框架，支持客户OS多对多并发发送与接收消息，且共享的读写区域无需加锁，在高并发下保持可预期性能；客户RTOS间端到端通信时延＜10 µs。
-
高精度同步：基于Zshm实现客户OS间时间同步，同步耗时＜200 µs，同步精度＜10 ns。
图1 RTOS原生虚拟化架构
2. 内核：独占核心的隔离多内核形态
Xen、Xvisor等Hypervisor与客户OS内核共享物理CPU，调度与中断处理在同一核心上交替执行，在高负载或异常场景下可能引发抖动甚至异常传播：1）客户OS内核崩溃后CPU进入异常状态，Hypervisor仍可能被调度到该CPU核心而功能受损；2）客户OS也可能被Hypervisor抢占，导致实时性能下降；3）Xen通过Domain0管理客户OS的全生命周期，管理路径横跨EL1（Linux）和EL2（Hypervisor）两个特权层，导致路径过长、频繁上下文切换和实时性下降。
ZVM为自身分配独立的物理CPU核心，各客户OS默认采用1V1静态绑核机制（每个客户OS独占一颗物理CPU核心）。由于各内核独占不同物理CPU，避免了调度竞争，从而保障内核隔离性与时间确定性。当某一客户OS内核崩溃时，异常仅被限制在其所属CPU核心内，不影响ZVM及其他客户OS的正常运行。此外，客户OS全生命周期管理内聚于EL2层的ZVM内部，控制路径无需经过EL1层，从而缩短管理链路并提升系统可预期性。
图2 ZVM绑核与多内核隔离
3. 外设：内置外设虚拟化框架
在Xen、Jailhouse等方案中，用于外设共享服务的外设虚拟化框架（例如VirtIO后端）常依赖Domain0协同实现。外设初始化、数据转发与中断处理通常沿“物理外设 → Domain0 → Hypervisor → 客户OS”的多级链路传递（如图3 (a)），链路跨越EL1与EL2两层，增加了端到端时延，并放大抖动。
ZVM将外设后端集成在自身内部（如图3 (b)），使外设管理、数据处理与中断处理均在EL2层完成，I/O与中断路径不再经过位于EL1层的Domain0，从而显著缩短关键路径并消除对Linux的依赖。此外，ZVM在外设虚拟化框架中引入中断同步与冗余等机制，即使在外设高频中断触发场景下也能保证中断不漏发。测试结果表明，内置VirtIO后端的性能损耗小于5%，端到端中断响应时间小于10微秒。
图3 VirtIO后端处于Domain0与内置于Hypervisor的对比
4. 工具：可视化管理工具VisualZVM
VisualZVM是ZVM配套的可视化管理工具，集烧录、交互、调试与测试于一体。VisualZVM运行于PC端，ZVM运行于嵌入式板卡端，二者在功能上紧密协同、在体系结构上相互独立。为兼顾管理效率与可靠性，两者采用以太网与串口双通道通信：以太网用于传输ZVM的状态数据与控制指令（资源管理、性能监控等），串口用于ZVM日志输出与异常调试的兜底保障。VisualZVM不参与ZVM执行路径，即便管理工具崩溃或通信中断，ZVM仍可独立稳定运行。主要能力如下：
-
客户OS内核的可视化管理：包括创建、启动、暂停到删除的全生命周期管理，支持对客户OS的SMP与AMP等多核分配模式。
-
客户OS外设的可视化管理：呈现外设类型及其虚拟化方式（完全虚拟化、半虚拟化等）。
-
客户OS的状态实时监控：实时展示客户OS的资源分配（CPU核、内存、虚拟外设）与运行指标（CPU利用率、中断数量、缓存命中率、时间同步精度等），实现配置与状态统一展示。
图4 可视化管理工具VisualZVM
5. 测试：自动化测试系统
ZVM通过VisualZVM提供自动化测试支持。测试程序集成于ZVM内部，并向VisualZVM开放标准化测试命令接口。测试程序基于预定义执行序列模拟典型运行场景，对关键模块进行白盒测试与验证。VisualZVM通过交互按钮向ZVM发送测试指令触发测试流程，ZVM按指令调用内部对应的测试程序执行并统计结果，再通过串口输出并在VisualZVM端展示统计结果。测试覆盖VirtIO、Zshm通信、vCPU调度、客户OS生命周期管理、中断处理、系统性能与自恢复机制等（见表1）。
表1 ZVM支持的自动化测试项
| 测试项 | 测试能力 | 场景覆盖 | 可视化 |
|---|---|---|---|
| VirtIO | VirtIO-blk吞吐量测试/VirtIO-net连通性测试 | — | √ |
| Zshm | 客户OS间共享内存通信测试 | √ | √ |
| vCPU | vCPU映射关系展示及调度时间片统计 | √ | √ |
| 客户OS生命周期管理 | 客户OS生命周期操作覆盖性测试 | √ | √ |
| 中断 | 多类型中断测试与时延统计 | √ | √ |
| 系统性能 | 客户OS性能与压力测试 | — | √ |
| 自恢复 | 验证客户OS自恢复机制并统计恢复时间 | √ | √ |
二、ZVM与典型Hypervisor能力对照
表2从系统依赖、隔离方式、外设虚拟化与工程化能力等维度对比多种Hypervisor方案。图中可以看出ZVM与QNX Hypervisor在系统设计上的理念是一致的。
表2 ZVM与典型Hypervisor能力对照
| 对比项 | Xen | Xvisor | Jailhouse | QNX Hypervisor | ZVM |
|---|---|---|---|---|---|
| 是否依赖Linux完成初始化？ | 是 | 否 | 是 | 否 | 否 |
| 是否依赖Linux管理内核生命周期？ | 是 | 否 | 是 | 否 | 否 |
| Hypervisor与Guest OS内核是否共享物理CPU？ | 是 | 是 | 否 | 否 | 否 |
| 是否依赖Linux管理外设虚拟化？ | 是 | 否 | 是 | 否 | 否 |
| 是否具备专门的可视化管理工具？ | 否 | 否 | 否 | 是 | 是 |
| 是否具备自动化测试系统？ | 否 | 否 | 否 | 是 | 是 |
三、ZVM-RK3588发行版性能测试结果
表3给出了ZVM-RK3588发行版承载运行客户RTOS时的性能测试结果。该结果用于表征客户RTOS在虚拟化运行环境下的中断响应、任务切换与抢占等关键实时性指标,且不受负载变化影响，稳定性很好。
表3 RTOS实时性指标测试结果
| 序号 | 性能项 | 测试方法 | 最小值 | 最大值 | 平均值 |
|---|---|---|---|---|---|
| 1 | 中断响应时间（RTOS） | RTOS主动触发中断。采集触发点与ISR内结束点差值；循环10万次取统计值。 | 2.9 µs | 9.9 µs | 3.4 µs |
| 2 | 任务切换时间（RTOS） | 两任务并发。高优先级任务挂起触发切换；循环1000次取统计值。 | 0.58 µs | 0.87 µs | 0.86 µs |
| 3 | 任务抢占时间（RTOS） | 创建更高优先级任务。采集唤醒点到开始执行差值；循环1000次取统计值。 | 0.87 µs | 1.45 µs | 0.97 µs |
结语
ZVM通过RTOS内核与虚拟化核心的EL2融合、独占核心隔离机制与内置化外设后端，在嵌入式实时场景下兼顾性能与功能；配套的VisualZVM与自动化测试系统进一步提升了工程可用性与可维护性。
原文转自：公众号【嵌入式计算湖南省重点实验室】
