一、前言

传统的虚拟化技术中，各个客户OS之间的通信往往依赖于复杂的网络协议或复制操作，这不仅导致了高昂的性能开销，还可能成为系统性能瓶颈。特别是在大规模虚拟化环境中，数据的频繁交换和高吞吐量要求下，传统的通信方式显得力不从心。

嵌入式计算湖南省重点实验室基于新一代Type1.5RTOS虚拟化解决方案ZVM（Zephyr-based Virtual Machine），研发了一套硬件辅助的共享内存通信架构，使得多个客户OS能够直接在内存中交换数据，避免了传统方式中网络传输和数据复制带来的性能开销，通过数据主体的零拷贝技术，直接在共享的内存区域中读写数据，不仅大大提高了通信效率，还减少了CPU和内存的负担。

实测表明，传输64字节数据的通信时延低至9微秒级别，充分展现了其在实时场景下的卓越优势。

本文将从共享内存设备的创建与使用、共享内存通信流程两个方面，解构ZVM中的多客户OS共享内存通信的实现细节，展现嵌入式通信技术的硬核突破。

二、ZVM多客户OS共享内存通信的设计与实现

2.1 共享内存设备的创建与使用

ZVM通过物理内存1对1映射、虚拟设备1对1分配的设计，直接读写物理内存映射的共享主数据单元，无需传统网络协议栈（如TCP/IP）或复杂的序列化/反序列化操作，通信延迟优秀。同时，每个客户OS仅能对主数据单元中属于自己的部分有写权限，对其他部分仅有读权限，天然隔离其他客户OS的写入，保证数据安全。

从下图1中，按照由物理层到客户OS层的顺序，共享内存设备的整体构建过程如下：

第1步：将物理内存划分为主数据区、信息记录区，中断信号区3个区域并1对1映射到ZVM中作为共享内存区域。

第2步：在ZVM中将这3种内存区域分别划分为单元，3种单元聚合后作为1个通信端点并封装为共享内存设备，将共享内存设备1对1分配给不同的客户OS使用。

第3步：客户OS在操作系统内核的支持下通过共享内存设备进行消息读写。下文将按照此顺序依次说明具体实现细节。

图1 共享内存设备的创建与使用

物理内存总占用为连续的128MB内存空间，被划分为3种，按照1对1的方式在ZVM中作为共享内存区域使用。

• 主数据区：用于存储数据主体，即消息或通知的具体内容，共126MB。

• 信息记录区：用于记录实现通信机制所需要的辅助信息，包括发送及接收方客户OS的VM ID以及消息的起始地址和数据长度，共1MB。

• 中断信号区：用于触发通信机制，同时该区域也用于存储信号量，共1MB。

对于ZVM中的3种共享内存区域，需要首先将其划分为小单元，再按照顺序进行聚合作为通信端点，除了主数据单元是客户OS共享的，其余两种单元为每个客户OS使用1个。

• 主数据单元：由主数据区以2MB为单元大小划分而来，所有单元由所有客户OS共享。分为两部分，属于该客户OS的2MB的主数据单元可读可写，用于存储数据主体，即消息/通知的具体内容。剩余124MB的主数据单元集合则以只读形式使用，以便该客户OS读取其他客户OS的消息/通知。在此设计下，由于消息/通知的写入和读出发生在同一个主数据单元，因而实现了数据主体的零拷贝。

• 信息记录单元：由信息记录区以4KB为单元大小划分而来，可读可写，每个客户OS使用1个。发送消息/通知时，该单元用于存储接收方的VM ID以及数据的起始地址和数据长度。接收消息/通知时，该单元用于读取发送方的VM ID以及数据的起始地址和数据长度，用以明确应该去主数据单元的哪个位置读取多长的数据。

• 中断信号单元：由中断信号区以4KB为单元大小划分而来，可读不可写，每个客户OS使用1个。在发送消息/通知时，发送方将向该单元写入接收方数量（此值将作为信号量），由于该单元不可写，会触发异常陷入ZVM进行处理，ZVM会负责将该值写入该单元，发送方检测该值即可知道当前接收者数量，同时ZVM也会用发送中断的方式通知接收方开始读取数据了。当接收方读取完数据后，会向自己的中断信号单元写入（发送方VM ID+100）的数值，触发异常处理后，ZVM会根据其中的发送方VM ID找到发送方，并将发送方的中断信号单元中的数值减1，以实现信号量机制。

对于上述提到的3种单元，ZVM按照“可读可写的主数据单元-信息记录单元-中断信号单元-只读的主数据单元集合”的顺序将其封装为1个通信端点并创建为1个共享内存设备，再将多个这样的共享内存设备按照1:1分配的方式给不同的客户OS使用。

对于传递进客户OS的共享内存设备，我们也提供了设备使用方案，目前实现了Linux以及Zephyr操作系统的解决方案。

Linux客户OS中将共享内存设备封装为标准字符设备，通过VFS（虚拟文件系统）层向用户态提供统一的文件操作接口，以支持用户空间的消息收发。

Zephyr客户OS中通过添加共享内存子系统使用共享内存设备，以提供用户空间的消息收发。

ZVM的共享内存设备设计通过物理资源直通与虚拟化层精细管控的平衡，为客户OS间通信提供了一种接近物理极限性能且符合生产级安全要求的解决方案，尤其适用于实时控制系统等对低延迟与高可靠性敏感的领域。

2.2 共享内存通信流程

ZVM的多客户OS共享内存通信流程有3大突破，包括数据主体零拷贝传输、虚拟中断通知机制、消息信号量机制。

• 数据主体零拷贝传输：基于预先建立的共享主数据单元，通信数据主体在跨OS传输过程中完全规避拷贝操作。发送方客户OS通过内存映射技术直接写入共享主数据单元，接收方直接读取共享主数据单元，在数据主体零拷贝的情况下即可完成通信。

• 虚拟中断通知机制：通过异常触发将消息通知直接传递至ZVM的EL2虚拟化层处理，并使用VM ID定向标识接收方，支持单次操作同时通知多个客户OS，避免逐一手动触发中断的开销。例如，Linux客户OS通过1次写入即可唤醒两台Zephyr客户OS，横向扩展性显著优于轮询或单播模式。

• 消息信号量机制：在发送方客户OS写入主数据单元后，将当前未接收完消息的接收方数量作为信号量写入发送方客户OS的中断信号单元，以便发送方能够实时监控消息是否传输完成，避免发送过快造成消息丢失。接收方客户OS读取完消息后，将该信号量进行减1操作。在保证实时性的情况下，加强了数据可靠性。

以1台Linux客户OS作为发送方，2台Zephyr客户OS作为接收方为例，具体通信流程如图2所示。

图2 共享内存通信流程

整体通信流程主要可分为两个流程，图中红色线为写数据流程，绿色线为通知读数据流程。

• 写数据流程：Linux客户OS中的用户态请求通过内核访问共享内存设备，将消息/通知的具体内容写入主数据单元，将两台Zephyr客户OS的VM ID以及主数据所在的起始地址和长度作为辅助信息写入信息记录单元，向中断信号单元写入想要通信的虚拟机的总数2，此时由于通知单元为可读不可写，会触发异常进入ZVM进行处理。

• 通知读数据流程：ZVM进行处理时，首先将异常处理时接收到的2写入通信端点1的中断信号单元作为此次通信的信号量，然后会将通信端点1中信息记录单元中的数据读取出来，根据其中的接收方VM ID找到两台Zephyr客户OS作为后续处理对象。紧接着将Linux客户OS的VM ID、主数据所在的起始地址和长度写入通信端点2、通信端点3的信息记录单元。随后同时向两台Zephyr客户OS发送中断。两台Zephyr客户OS接收到中断后，通过共享内存设备在各自的信息记录单元中找到辅助信息，由此找到此次要读的数据所在的具体位置，即通信端点1所拥有的主数据单元，最后便可直接从该处读出数据，实现数据主体的零拷贝。数据读取完成后，两台Zephyr客户OS向各自的中断信号单元写入（Linux客户OS的VM ID+100），触发异常进入ZVM处理，分别将通信端点1的中断信号单元中的数值减1，使此次通信的信号量归零。

三、功能演示

此处演示在QEMU平台上启动1台Linux客户OS以及2台Zephyr客户OS，Linux客户OS发送消息给两台Zephyr客户OS，传输64字节消息，通信时延达到9us。