ZVM官方网站

01 引言

在多客户 OS 并发运行的场景下，通信机制不仅需要满足高吞吐与低时延，还必须具备可预期的时序行为。ZSHM (ZVM Shared Memory) 是 ZVM 内部提供的一套多客户 OS 共享内存通信框架。其设计核心是围绕嵌入式与实时系统的诉求，提供一条最短、最轻量、最确定的跨域通信路径。

为什么不直接采用 IVSHMEM？

IVSHMEM 是业界常见机制（如 KVM、Jailhouse 使用），但在嵌入式场景面临结构性问题：

总线依赖限制

嵌入式 SoC 通常不具备 PCI 控制器，强行引入虚拟 PCI 会增加不必要的架构复杂度。

中断路径抖动

MSI 的映射与转发路径冗长，会引入实时系统难以容忍的时延抖动。

代码规模冗余

虚拟设备语义与 ZVM 追求的轻量化、可验证设计目标不匹配。

02 总体设计思想

最小化 Hypervisor 介入路径：Hypervisor 仅负责通知转发，不参与消息数据搬运。
为高并发与确定性而设计：在多发送者、多接收者并发场景下，保证无死锁表现。

03 Zshm内存逻辑结构

消息组群 (Message Groups)

每个客户 OS 对应一个连续的消息组；

每个消息组由16个固定大小的消息槽（slot）组成;

消息槽用于存放该客户OS向ZVM或其他客户OS发送的消息数据

槽位标记环群 (Tag Rings)

每个客户OS对应一个槽位标记环；

槽位标记环记录：消息来源的客户OS，对应的消息组，具体的槽号；

该结构用于指示“从哪里读取下一条消息”，槽位标记环本质上是一种多生产者、多消费者的环形队列实现，用于在并发场景下维持消息的可达性与顺序性

04 通信流程示例

图1. ZSHM 通信交互流程

以 Guest OS0 向 OS1/OS2 发送消息为例：

1. 写入：客户 OS0 将消息写入消息组0的空闲消息槽9，向触发器0发送信号9。

2. 标记：ZVM响应信号9生成槽位标记，分别插入客户 OS1 的槽位标记环1与客户 OS2 槽位标记环2，更新其尾指针。

3. 通知：ZVM向客户 OS1 与客户 OS2 发送中断，客户 OS1 与客户 OS2 分别从槽位标记环1与槽位标记环2的头指针处取出标记。

4. 读取：客户 OS1 与客户 OS2 分别根据标记在消息组0的槽位9处读出消息，并将该槽释放以供重用。

05 性能表现测试

开启 Cache (高性能模式)

平均时延：8.28 μs
最小时延：7.87 μs
最大时延：18.95 μs

关闭 Cache (高可靠模式)

平均时延：3.81 μs
最小时延：3.50 μs
最大时延：11.66 μs

* 测试环境：ZVM 官方发行版参考硬件平台。

“ZSHM 并非 IVSHMEM 的简单替代，而是专为嵌入式实时场景定制的基础设施。通过摒弃 PCI 路径，它缩短了通信链路，保留了 ZVM 一贯的代码简洁性与实时确定性，为多 OS 并发提供了高性能的通信底座。”

ZVM特性：共享内存通信框架Zshm