ZVM技术解读·外设篇①｜VirtIO内置
01 什么是VirtIO
VirtIO（Virtual I/O）是一套面向虚拟化环境的标准化半虚拟化I/O接口。它为客户OS提供统一的虚拟设备访问方式，避免完整硬件模拟带来的额外开销，广泛应用于虚拟网络、块设备等场景。VirtIO主要包括以下三部分：
- • VirtIO前端（Frontend）：位于客户OS，负责将客户OS发起的I/O请求写入共享队列；
- • VirtIO后端（Backend）：从共享队列中读取并处理前端请求，调用物理设备驱动完成实际I/O；
- • Virtqueue：前后端共享的队列，用于传递描述符、数据位置和完成状态。
处理一次I/O时，VirtIO前端将请求描述符写入Virtqueue并通知后端；VirtIO后端完成设备访问后更新队列状态，再向客户OS发送完成通知。
所谓VirtIO内置，是指在保持客户OS中的VirtIO前端接口及Virtqueue通信机制不变的前提下，将VirtIO后端作为模块化虚拟I/O服务内置于ZVM统一RTOS底座。客户OS发起I/O请求后，由ZVM内置后端完成描述符解析、队列处理和状态回写，并通过底座内部调用直接访问ZVM设备驱动，无需额外依赖Host OS、Domain 0或独立用户态VMM承担VirtIO后端服务。
02 主流虚拟化方案对比
不同虚拟化方案的差别主要体现在VirtIO后端部署方式和I/O处理路径等方面，具体对比如表1所示。
表1：不同虚拟化方案的VirtIO框架对比
| 方案 | 主要参与组件 | 一次I/O跨执行环境切换次数 | 后端与设备驱动是否同EL层 | 主要特点 |
|---|---|---|---|---|
| KVM | KVM + Host Linux + QEMU / vhost-kernel + Host设备驱动 | QEMU：8次 vhost-kernel：4次 |
QEMU：否 vhost-kernel：是 |
依赖Host Linux；QEMU后端位于用户态，I/O需在QEMU与Host内核间往返 |
| Xen | Xen Hypervisor + Domain 0 + QEMU VirtIO后端 + Domain 0设备驱动 | 8次 | 否 | 依赖Domain 0中QEMU，I/O需跨域并经过用户态处理 |
| Jailhouse | Jailhouse + Linux Root Cell + VirtIO-over-IVSHMEM用户态后端 + Root Cell设备驱动 | 8次 | 否 | VirtIO依赖Root Cell提供后端，I/O需跨Cell并经过用户态处理 |
| ZVM | ZVM | 2次 | 是 | VirtIO后端与设备驱动均内置于ZVM，同EL完成I/O处理 |
KVM通常依赖Host Linux、KVM及QEMU或vhost等组件协同提供VirtIO能力，在采用用户态设备模型时，I/O请求需要在内核态与用户态之间往返；Xen由Hypervisor与Domain 0或后端域协作完成I/O服务，I/O请求涉及跨Domain转发；Jailhouse以静态资源分区和设备直通为主，若需支持VirtIO等共享设备能力，则需额外引入后端服务，架构也会相应演化为类似Domain 0的模式。
因此，ZVM的VirtIO内置并不只是将后端置于ZVM内部，其更关注：在保持标准VirtIO接口的前提下，一次I/O请求需要经过多少软件层级和独立组件、跨越多少执行环境，以及后端与设备驱动能否在同一实时内核中完成协同处理。
03 ZVM方案：VirtIO后端内置
ZVM采用RTOS原生虚拟化架构，将VirtIO后端作为模块化虚拟I/O服务内置于统一RTOS底座。后端服务直接复用ZVM已有的内存、设备、中断等内核机制完成请求处理，并通过底座内部接口访问设备驱动，无需额外设置独立特权OS、管理域或用户态VMM承载后端功能。
客户OS仍使用标准VirtIO前端和Virtqueue提交请求。请求进入ZVM后，后端服务完成描述符解析、地址映射和状态回写，通过底座内部接口调用设备驱动完成实际I/O，并由ZVM统一中断机制向客户OS返回虚拟中断。这样，传统需要跨OS、跨Domain或跨用户态/内核态协同的设备服务链路，被收敛为统一RTOS底座内部的模块调用，减少独立调度实体和跨执行环境转交。
图1. ZVM内置VirtIO框架
04 示例一：VirtIO I/O路径差异对比
以客户OS发起一次VirtIO I/O请求为例，各架构的处理路径如图2所示。KVM需经KVM、Host Linux以及QEMU或vhost后端访问设备驱动；Xen需经Hypervisor、Domain 0及QEMU后端完成设备访问；Jailhouse则需通过Root Cell及用户态VirtIO后端转交请求。相比之下，ZVM将VirtIO后端与设备驱动统一内置于RTOS底座，请求进入ZVM后即可由后端直接调用设备驱动完成I/O，减少中间执行环境和软件层级。
图2. 不同方案下VirtIO I/O路径差异对比
05 示例二：VirtIO 中断路径差异对比
以设备完成I/O后向客户OS返回VirtIO完成中断为例，各架构的中断路径如图3所示。KVM需经QEMU或vhost后端、Host Linux及KVM返回客户OS；Xen需经QEMU后端、Domain 0及Hypervisor完成中断转发；Jailhouse需经用户态后端、Root Cell及Jailhouse向non-root Cell返回通知。ZVM则由内置VirtIO后端通过统一中断机制直接向客户OS返回虚拟中断，减少中断返回过程中的跨执行环境转交。
图3. 不同方案下VirtIO中断路径差异对比
06 VirtIO后端内置带来的收益
- • 更短的I/O路径：VirtIO后端与设备驱动运行于统一RTOS底座，I/O请求可沿底座内部路径完成后端处理与设备访问，减少跨执行环境、特权级及上下文切换，使I/O处理路径更加直接；
- • 更小的虚拟化栈：承载VirtIO功能无需额外引入Host OS、Domain 0、独立用户态VMM或设备模型，参与I/O处理的软件层级和独立组件随之减少；
- • 更低的服务耦合：VirtIO后端以独立服务模块组织于ZVM底座，将传统跨OS、跨Domain的服务协同收敛为底座内部模块调用，降低不同执行环境之间的运行依赖；各类后端可按需组合、裁剪和扩展；
- • 更可预测的I/O时延：VirtIO后端处理、设备驱动、中断及调度统一纳入ZVM实时控制路径，减少额外调度等待和不确定执行环节，有利于降低I/O时延抖动。
07 内置VirtIO表现
作为ZVM的核心技术之一，内置VirtIO已应用于ZVM的六款发行版中，并在配套可视化管理工具VisualZVM中提供相关功能的快速测试与验证能力。具体支持情况如表2所示：
表2：内置VirtIO支持情况
| 发行版 | VirtIO-blk | VirtIO-net | VirtIO-i2c | VirtIO-gpio |
|---|---|---|---|---|
| ZVM-RK3568v2.1 | √ | √ | √ | √ |
| ZVM-RK3588v2.1 | √ | √ | √ | √ |
| ZVM-E2000v2.1 | √ | √ | 可拓展 | 可拓展 |
| ZVM-D2000v2.1 | √ | √ | 可拓展 | 可拓展 |
| ZVM-D3000v2.1 | √ | √ | 可拓展 | 可拓展 |
| ZVM-D3000Mv2.1 | √ | √ | 可拓展 | 可拓展 |
08 小结
ZVM的VirtIO内置并非简单地将后端代码置于Hypervisor内部，而是以实时内核与虚拟化功能一体化为基础，将VirtIO后端、设备驱动及请求处理能力统一组织于RTOS内核。在保持标准VirtIO前端接口兼容性的同时，I/O请求可在同一实时控制体系内完成后端处理和设备访问，减少跨执行环境、特权级和上下文切换；同时，无需额外引入Host OS、管理域或独立用户态VMM承载后端服务，进一步减少软件层级和独立组件，降低服务耦合。由此形成更轻量、更直接且时延更可预测的I/O虚拟化路径，为嵌入式混合关键系统提供稳定、高效的设备访问基础。