前言

在云原生、Serverless 与机密计算快速发展的今天，传统 C 语言实现的虚拟化栈（如 QEMU）面临内存安全漏洞频发、代码体积庞大、攻击面过宽等问题。2019 年由 Intel、Google、AWS、阿里云等多家厂商联合发起的 rust-vmm 项目应运而生 —— 它不是一款完整的虚拟机监视器（VMM），而是一套高度解耦、可按需组装的 Rust 虚拟化基础组件库，为整个行业提供了构建轻量、安全、高性能 VMM 的标准化「积木」。

rust-vmm 遵循「一个组件一个 crate」的设计原则，所有 crate 独立发布、按需依赖，从最底层的系统调用封装到上层的设备模拟，覆盖了虚拟化技术栈的全部核心环节。本文将按功能分层，系统梳理 rust-vmm 生态下的全部核心 crate 及其定位、能力、核心 API 与最小调用示例。

核实声明：本文所有事实（仓库归属、架构支持、trait 名称、crate 是否存在、API 签名）均经过对 rust-vmm 组织 GitHub 仓库与 crates.io 的实际比对，更新于 2026-06；示例 API 以 docs.rs latest 为准。近一两年 rust-vmm 推动了多次「workspace 化合并」，部分原本独立的仓库（如 kvm-bindings、kvm-ioctls、vfio-user）已被归档并整合到 workspace 仓库中，下文会标注实际位置。

整体架构：分层解耦的虚拟化积木

rust-vmm 采用自底向上的分层设计，每一层只依赖下层能力，职责边界清晰：

graph TD
    A[工程化与参考实现
rust-vmm-ci / rust-vmm-container / vmm-reference] --> B
    B[启动与兼容层
linux-loader / vm-fdt / vm-superio / vm-superio-ser] --> C
    C[硬件直通层
vfio-bindings / vfio-ioctls / vfio-user] --> D
    D[VirtIO & vhost 半虚拟化层
virtio-bindings / virtio-queue / virtio-queue-ser / vhost / vhost-user-backend / vhost-device-*] --> E
    E[核心资源层
vm-memory / vm-allocator / vm-device] --> F
    F[Hypervisor 抽象层
kvm-bindings / kvm-ioctls / mshv-bindings / mshv-ioctls] --> G
    G[基础系统工具层
vmm-sys-util / event-manager]

基础系统工具层

这一层是整个 rust-vmm 生态的公共基座，将操作系统底层能力封装为安全、跨平台的 Rust 接口。

vmm-sys-util

所有 rust-vmm 组件最核心的公共依赖。它将 eventfd、ioctl、epoll、文件描述符管理、tempfile、字节序处理、errno 错误类型、灵活数组成员（FAM）安全封装等系统级原语统一收敛在一个 crate 中，把 unsafe 收拢到最小范围。

核心 API：eventfd::EventFd、ioctl_*! 宏家族（ioctl_none! / ioctl_io! / ioctl_ior! / ioctl_iow! / ioctl_iowr!）、ioctl_with_val / ioctl_with_ref、tempfile::TempFile、epoll、errno::Error、fam::FamStruct。

最小示例（来自源码 doctest）：

1
2
3
4
5
6
7
8
9
10
use vmm_sys_util::eventfd::{EventFd, EFD_NONBLOCK};

let evt = EventFd::new(EFD_NONBLOCK).unwrap();
evt.write(55).unwrap();
assert_eq!(evt.read().unwrap(), 55);

// 跨线程共享同一计数（dup fd）
let evt_clone = evt.try_clone().unwrap();
evt.write(923).unwrap();
assert_eq!(evt_clone.read().unwrap(), 923);

EventFd 在 rust-vmm 里被广泛用作中断注入信号、退出信号、跨线程唤醒的轻量通道。

event-manager

轻量级事件驱动框架，VMM 中 I/O 事件、中断事件的核心调度器。它采用「事件管理器 - 事件订阅者」模型，提供两种订阅 trait 适配不同借用语义场景：

  • EventSubscriber：要求 &self，适用于通过 Arc<T> 共享、内部用 Mutex 自管的场景
  • MutEventSubscriber：要求 &mut self，适用于经 Mutex<T>/RefCell<T> 包装后由 manager 独占借用的场景

核心 API：EventManager<T>、EventSubscriber / MutEventSubscriber、EventOps、Events、SubscriberId、SubscriberOps。

最小示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
use event_manager::{EventManager, EventOps, Events, MutEventSubscriber};
use vmm_sys_util::{epoll::EventSet, eventfd::EventFd};

pub struct CounterSubscriber { event_fd: EventFd, counter: u64 }

impl MutEventSubscriber for CounterSubscriber {
    fn init(&mut self, ops: &mut EventOps) {
        ops.add(Events::new(&self.event_fd, EventSet::IN)).unwrap();
    }
    fn process(&mut self, events: Events, ops: &mut EventOps) {
        match events.event_set() {
            EventSet::IN => { self.counter += 1; let _ = self.event_fd.read(); }
            EventSet::HANG_UP => { ops.remove(events).ok(); }
            _ => {}
        }
    }
}

let mut mgr = EventManager::<CounterSubscriber>::new().unwrap();
let _id = mgr.add_subscriber(CounterSubscriber {
    event_fd: EventFd::new(0).unwrap(), counter: 0,
});
let _ = mgr.run_with_timeout(100);   // 进入 epoll_wait

init 中注册感兴趣的 fd，process 中处理就绪事件；VMM 在主循环里反复调用 EventManager::run。

Hypervisor 抽象层

这一层直接对接操作系统内核的虚拟化模块，将底层 unsafe 的内核接口封装为类型安全的 Rust API。rust-vmm 同时支持 Linux KVM 与微软 MSHV 两大虚拟化平台。

KVM 系列：Linux 硬件虚拟化标准接口

自 2024 年起，原 rust-vmm/kvm-bindings 与 rust-vmm/kvm-ioctls 已归档合并至单仓库 https://github.com/rust-vmm/kvm（workspace），但 crates.io 上的两个 crate 名称与发布节奏不变。

kvm-bindings

通过 bindgen 自动生成的 Linux KVM API 原生 FFI 绑定，包含所有 KVM ioctl 命令、数据结构与常量定义，并为灵活数组成员（如 kvm_cpuid2、kvm_msr_list）提供安全的 FAM 封装，是 Rust 代码与 KVM 内核交互的底层协议基础。

kvm-ioctls

构建在 kvm-bindings 之上的安全封装层，将原本 unsafe 的 ioctl 调用转化为类型安全的高级 API。

核心 API：

  • Kvm：系统级 ioctl 入口（new、create_vm、get_api_version、check_extension）
  • VmFd：VM 级（set_user_memory_region、create_vcpu、get_dirty_log、create_irq_chip、register_irqfd）
  • VcpuFd：vCPU 级（get_regs/set_regs、get_sregs/set_sregs、run）
  • VcpuExit：枚举 Hlt / IoIn / IoOut / MmioRead / MmioWrite / …

最小示例（节选自 kvm-ioctls 顶层 doctest，x86_64）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
use kvm_bindings::{kvm_userspace_memory_region, KVM_MEM_LOG_DIRTY_PAGES};
use kvm_ioctls::{Kvm, VcpuExit};

// guest 在 0x1000 处运行：out %al,%dx; mov $0,(0x8000); hlt
let asm: &[u8] = &[0xba,0xf8,0x03, 0x00,0xd8, 0x04,b'0', 0xee, 0xec,
                   0xc6,0x06,0x00,0x80,0x00, 0x8a,0x16,0x00,0x80, 0xf4];
let kvm = Kvm::new().unwrap();
let vm = kvm.create_vm().unwrap();
let mem_size = 0x4000; let guest_addr = 0x1000;
let host = unsafe { libc::mmap(std::ptr::null_mut(), mem_size,
    libc::PROT_READ|libc::PROT_WRITE,
    libc::MAP_ANONYMOUS|libc::MAP_SHARED, -1, 0) as *mut u8 };
unsafe { std::slice::from_raw_parts_mut(host, mem_size)[..asm.len()].copy_from_slice(asm); }
let region = kvm_userspace_memory_region {
    slot: 0, guest_phys_addr: guest_addr, memory_size: mem_size as u64,
    userspace_addr: host as u64, flags: KVM_MEM_LOG_DIRTY_PAGES,
};
unsafe { vm.set_user_memory_region(region).unwrap(); }

let vcpu = vm.create_vcpu(0).unwrap();
let mut sregs = vcpu.get_sregs().unwrap();
sregs.cs.base = 0; sregs.cs.selector = 0; vcpu.set_sregs(&sregs).unwrap();
let mut regs = vcpu.get_regs().unwrap();
regs.rip = guest_addr; regs.rax = 2; regs.rbx = 3; regs.rflags = 2;
vcpu.set_regs(&regs).unwrap();

loop {
    match vcpu.run().unwrap() {
        VcpuExit::IoOut(addr, data) => println!("OUT {:#x} = {:#x}", addr, data[0]),
        VcpuExit::Hlt => break,
        e => panic!("{:?}", e),
    }
}

经典的「五步走」流程：Kvm::new → create_vm → set_user_memory_region → create_vcpu 并 setup regs → vcpu.run() 循环匹配 VcpuExit。

MSHV 系列：Windows 平台虚拟化支持

mshv-bindings / mshv-ioctls

对应微软 Hypervisor（MSHV）的 FFI 绑定与安全接口封装，让 rust-vmm 突破 Linux 限制，可适配 Azure 等 Windows 云环境。设计逻辑与 KVM 系列完全一致（Mshv / VmFd / VcpuFd），降低跨平台开发的心智负担。

虚拟机核心资源层

这一层定义了虚拟机的核心资源模型 —— 内存、地址空间、设备抽象，是所有虚拟设备与业务逻辑的运行载体。

vm-memory

虚拟机客户机内存管理的基石组件。它支持匿名内存、文件 - backed 内存的 mmap 映射，实现了客户机物理地址（GPA）到宿主机虚拟地址（HVA）的安全转换，提供脏页跟踪、原子读写、零拷贝数据传输、跨字节序访问等核心能力，是设备 DMA 模拟、虚拟机热迁移、内存快照的基础支撑。

核心 API：

  • trait：GuestMemory（只读视图）、GuestMemoryRegion、Bytes（read/write/read_obj/write_obj）、Address
  • 类型：GuestAddress、GuestUsize、GuestMemoryMmap<B = ()>、MmapRegion、GuestRegionMmap、GuestMemoryAtomic（多线程换页 / 快照）

最小示例（来自 README）：

1
2
3
4
5
6
7
8
9
10
11
12
use vm_memory::{Bytes, GuestAddress, GuestMemoryMmap};

let gm: GuestMemoryMmap<()> = GuestMemoryMmap::from_ranges(&[
    (GuestAddress(0),      0x1000),
    (GuestAddress(0x1000), 0x1000),
]).unwrap();

let sample = &[1u8, 2, 3, 4, 5];
assert_eq!(gm.write(sample, GuestAddress(0xffc)).unwrap(), 5); // 跨 region 边界写
let mut buf = [0u8; 5];
assert_eq!(gm.read(&mut buf, GuestAddress(0xffc)).unwrap(), 5);
assert_eq!(&buf, sample);

GuestMemoryMmap::from_ranges 在宿主匿名 mmap 出来的内存基础上构建 guest 物理地址空间；Bytes trait 让设备模型直接以 (addr, slice) 方式跨 region 读写。

vm-allocator

虚拟机系统资源分配器，负责 MMIO 地址空间、PIO 端口、中断号（GSI）、设备 ID 等硬件资源的分配与回收。它支持地址区间对齐校验、资源冲突检测，确保虚拟机的硬件资源布局符合架构规范。

核心 API：

  • IdAllocator：整数资源分配器（如 GSI、KVM memslot id），用 BTreeSet 维护已释放 ID
  • AddressAllocator：区间资源分配器（基于 IntervalTree 的地址段）
  • AllocPolicy::{FirstMatch, LastMatch, ExactMatch}、Constraint、RangeInclusive

最小示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
use vm_allocator::{AddressAllocator, AllocPolicy, IdAllocator};

const MMIO_START: u64 = (1 << 32) - (768 << 20); // 32-bit gap
const MMIO_SIZE:  u64 = 768 << 20;
const PAGE: u64 = 0x1000;

let mut ids   = IdAllocator::new(0, 100).unwrap();   // 闭区间 [0, 100]，共 101 个 ID
let mut mmio  = AddressAllocator::new(MMIO_START, MMIO_SIZE).unwrap();

// 给一个新设备分配一个 ID + 一页对齐的 MMIO 区间
let id    = ids.allocate_id().unwrap();
let range = mmio.allocate(PAGE, PAGE, AllocPolicy::FirstMatch).unwrap();
println!("dev#{id} mmio = [{:#x}, {:#x}]", range.start(), range.end());

// 释放
mmio.free(&range).unwrap();
ids.free_id(id).unwrap();

vm-device

虚拟设备的统一抽象框架。它定义了 PIO 与 MMIO 两条总线上的设备 trait，并提供 IoManager 作为按地址段路由 I/O 的总线分发器。所有虚拟设备均可基于这套抽象开发，无缝接入任意 VMM。

核心 API：

  • 设备 trait（共 4 个）：
    • PIO：DevicePio（不可变 self）、MutDevicePio（可变 self）
    • MMIO：DeviceMmio（不可变 self）、MutDeviceMmio（可变 self）
  • 总线 trait：PioManager、MmioManager
  • 具体管理器：IoManager
  • 地址类型：PioAddress、PioRange、MmioAddress、MmioRange

最小示例（来自 README）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
use std::sync::{Arc, Mutex};
use vm_device::bus::{PioAddress, PioAddressOffset, PioRange};
use vm_device::device_manager::{IoManager, PioManager};
use vm_device::MutDevicePio;

struct LogDevice;
impl MutDevicePio for LogDevice {
    fn pio_read(&mut self, base: PioAddress, off: PioAddressOffset, _data: &mut [u8]) {
        println!("read base={:?} off={off}", base);
    }
    fn pio_write(&mut self, base: PioAddress, off: PioAddressOffset, data: &[u8]) {
        println!("write base={:?} off={off} data={:?}", base, data);
    }
}

let mut mgr = IoManager::new();
let range = PioRange::new(PioAddress(0), 10).unwrap();
mgr.register_pio(range, Arc::new(Mutex::new(LogDevice))).unwrap();
mgr.pio_write(PioAddress(0), &[b'o', b'k']).unwrap(); // 由 IoManager 路由到 LogDevice

VMM 在 VcpuExit::IoOut/MmioWrite 上调用 mgr.pio_write/mmio_write，Manager 按地址范围找到对应设备并转发。

VirtIO 生态层

VirtIO 是云计算领域的事实半虚拟化设备标准，rust-vmm 提供了从协议绑定到队列实现、再到设备框架的完整支持。

仓库结构：virtio-bindings、virtio-queue、virtio-queue-ser、virtio-blk、virtio-console、virtio-device、virtio-vsock 等 crate 同属一个仓库 https://github.com/rust-vmm/vm-virtio（workspace），并非各自独立仓库，且 crates.io 上没有名为 vm-virtio 的 crate，仓库名只是 workspace 容器。

virtio-bindings

VirtIO 规范的原生 FFI 绑定（来源是 Linux kernel 的 virtio uapi 头文件），定义了 VirtIO 设备的标准数据结构、特性位、队列协议常量，按内核版本提供不同 feature。是所有 VirtIO 相关组件的协议底座。

virtio-queue

VirtIO Split Virtqueue 的纯 Rust 完整实现，包含描述符表、可用环（avail ring）、使用环（used ring）的全部逻辑，并通过 Kani 进行了形式化证明。

核心 API：

  • Queue（单线程）、QueueSync（Arc<Mutex<Queue>>）
  • trait：QueueT / QueueOwnedT
  • Descriptor、DescriptorChain、DescriptorChainRwIter、AvailIter
  • QueueState（save/restore 用）

最小示例（节选自 Queue doctest）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
use virtio_queue::{Queue, QueueOwnedT, QueueT};
use vm_memory::{Bytes, GuestAddress, GuestMemoryMmap};

let mem: GuestMemoryMmap<()> =
    GuestMemoryMmap::from_ranges(&[(GuestAddress(0), 0x10000)]).unwrap();

let mut queue = Queue::new(1024).unwrap();
queue.set_size(8);
queue.set_desc_table_address(Some(0x1000), None);
queue.set_avail_ring_address(Some(0x2000), None);
queue.set_used_ring_address(Some(0x3000), None);
queue.set_event_idx(true);
queue.set_ready(true);
assert!(queue.is_valid(&mem));

// 模拟 driver 把一个 chain head 推到 avail ring，并把 idx 推到 3
mem.write_obj::<u16>(3, GuestAddress(0x2002)).unwrap();

loop {
    queue.disable_notification(&mem).unwrap();
    while let Some(chain) = queue.iter(&mem).unwrap().next() {
        // 这里遍历 chain 的描述符（chain.into_iter() / readable / writable）
        queue.add_used(&mem, chain.head_index(), 0x100).unwrap();
        if queue.needs_notification(&mem).unwrap() { /* 注入中断 */ }
    }
    if !queue.enable_notification(&mem).unwrap() { break; }
}

标准的 split virtqueue 处理循环 —— 禁用通知 → 迭代 AvailIter 取出 DescriptorChain → 处理后 add_used → 按 needs_notification 决定是否触发中断。

virtio-queue-ser

virtio-queue 的版本感知序列化扩展，对 QueueState 进行序列化与反序列化。它是热迁移的关键 —— 虚拟机暂停后，可将所有 VirtIO 设备的队列状态持久化，目标主机恢复后重建队列状态，保证业务无感知迁移。

vhost 与 vhost-user 层

vhost 系列组件将 VirtIO 设备的数据面从 VMM 进程中剥离，分别下沉到内核态（vhost）、独立用户态进程（vhost-user）或硬件（vDPA），既提升性能，又通过进程隔离缩小攻击面。

vhost

vhost、vhost-user、vDPA 三种加速方案的统一抽象库。它屏蔽了内核态 vhost、用户态 vhost-user、硬件 vDPA 的实现差异，提供统一的 vring 操作、事件通知、特性协商接口。

vhost-user-backend

vhost-user 后端设备的通用开发框架，完整封装了 vhost-user 协议的控制面交互逻辑：握手、特性协商、队列配置、生命周期管理、中断注入。开发者只需实现设备的数据面处理逻辑。

核心 API：

  • trait：VhostUserBackend / VhostUserBackendMut（num_queues、max_queue_size、features、set_event_idx、update_memory、handle_event、process_queue 等）
  • VhostUserDaemon<S, V, B>：服务端入口（new / start / wait / get_epoll_handlers）
  • vring trait：VringT，三种实现 VringState / VringMutex / VringRwLock

最小示例（来自 README，关键骨架；下面的 Error::* 为读者自定义错误类型，需结合具体后端实现）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
use vhost_user_backend::{VhostUserBackendMut, VringMutex, VringT};

impl VhostUserBackendMut for MyBackend {
    fn process_queue(&mut self, vring: &VringMutex) -> Result<bool> {
        let mem = self.mem.as_ref().ok_or(Error::NoMem)?.memory();
        let mut state = vring.get_mut();
        while let Some(avail) = state.get_queue_mut().iter()
            .map_err(|_| Error::IterateQueue)?.next()
        {
            // 1) 解析 avail 的 readable/writable 描述符并完成 I/O
            let head = avail.head_index();
            // 2) 归还到 used ring
            state.add_used(head, 0).ok();
            // 3) 必要时触发中断
            if !self.event_idx || state.needs_notification().unwrap_or(true) {
                state.signal_used_queue().ok();
            }
        }
        Ok(true)
    }
    // 还需实现 num_queues / max_queue_size / features / protocol_features /
    // set_event_idx / update_memory / handle_event ...
}

// 入口：
//   let mut daemon = VhostUserDaemon::new(name, backend, atomic_mem)?;
//   daemon.start(Listener::new("/tmp/sock", true)?)?;
//   daemon.wait()?;

vhost-device 系列

rust-vmm 社区维护的开箱即用 vhost-user 设备集合，每个设备是 workspace 内独立的二进制 crate（vhost-device-<name>）。截至 2026-06，仓库内官方设备清单（按字母序）：

crate 用途 crates.io
vhost-device-can CAN 总线（车载 / 工控） https://crates.io/crates/vhost-device-can
vhost-device-console 串口 / 控制台 https://crates.io/crates/vhost-device-console
vhost-device-gpio GPIO https://crates.io/crates/vhost-device-gpio
vhost-device-gpu GPU（virtio-gpu） https://crates.io/crates/vhost-device-gpu
vhost-device-i2c I2C 总线 https://crates.io/crates/vhost-device-i2c
vhost-device-input 输入设备（键鼠等） https://crates.io/crates/vhost-device-input
vhost-device-rng 熵源 / 随机数 https://crates.io/crates/vhost-device-rng
vhost-device-scmi ARM SCMI 协议 https://crates.io/crates/vhost-device-scmi
vhost-device-scsi SCSI 块存储 https://crates.io/crates/vhost-device-scsi
vhost-device-sound 音频（virtio-snd） https://crates.io/crates/vhost-device-sound
vhost-device-spi SPI 总线 https://crates.io/crates/vhost-device-spi
vhost-device-vsock guest-host socket 通道 https://crates.io/crates/vhost-device-vsock
vhost-device-template 新设备开发模板 —
vhost-device-video（staging） 视频编解码 —

辨析：vhost-device-blk、vhost-device-net 并不存在于本仓库。块设备 / 网络设备的 vhost-user 实现一般由 VMM 自带（如 Cloud Hypervisor 的 vhost-user-block、SPDK 的 vhost-user-blk、DPDK 的 vhost-user-net）或者部署内核态 vhost-net。

VFIO 硬件直通层

对于需要极致性能的场景（如 GPU 计算、高速网卡），rust-vmm 提供了完整的 VFIO 硬件直通支持。

原 rust-vmm/vfio-user 已于 2025 年归档，源码迁移至 https://github.com/rust-vmm/vfio workspace；vfio-bindings、vfio-ioctls、vfio-user 三个 crate 现位于同一仓库。

vfio-bindings

Linux VFIO（Virtual Function I/O）子系统的 FFI 绑定，包含 VFIO 容器、设备组、物理设备的所有数据结构与 ioctl 命令定义。

vfio-ioctls

VFIO API 的安全 Rust 封装，支持 PCIe 设备的完整透传流程。

核心 API：

  • VfioContainer：包装 /dev/vfio/vfio，提供 vfio_dma_map / vfio_dma_unmap
  • VfioDevice：单个透传设备（get_irq_info、enable_irq、region_read / region_write、get_region_info）
  • VfioGroup、VfioRegion、VfioIrq、错误类型 VfioError

最小骨架（仓库未提供独立 examples，下面按公共 API 还原）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
use std::path::Path;
use std::sync::Arc;
use vfio_ioctls::{VfioContainer, VfioDevice};

// 1) 打开容器（device_fd 通常来自 KVM VmFd 实现的 hypervisor handle）
let container = Arc::new(VfioContainer::new(Some(device_fd))?);

// 2) 通过 sysfs 路径打开一个 PCI 设备，例如 0000:01:00.0
let sysfs = Path::new("/sys/bus/pci/devices/0000:01:00.0");
let dev   = VfioDevice::new(sysfs, container.clone())?;

// 3) 查询 BAR0 region 信息 / 读寄存器
let info  = dev.get_region_info(0)?;
let mut buf = [0u8; 4];
dev.region_read(0, &mut buf, 0);
println!("BAR0 size={:#x} flags={:#x} val={:?}", info.size, info.flags, buf);

// 4) 把一段宿主内存映射到 IOVA，供设备 DMA
container.vfio_dma_map(/*iova=*/0x1_0000_0000, len, host_va)?;

vfio-user

vfio-user 协议（基于 Nutanix libvfio-user 规范）的纯 Rust 实现，同时提供 Client（VMM 侧）与 Server（设备侧）两种 struct，支持把物理 / 模拟设备以 socket 形式远程挂载到虚拟机，适合分布式虚拟化与设备池化。

关于 iommufd：截至 2026-06，rust-vmm 组织下并不存在 iommufd-bindings 或 iommufd-ioctls 这两个 crate。Linux 新一代 iommufd 子系统的能力目前通过 vfio-bindings / vfio-ioctls 在 VFIO 容器/IOMMUFD 兼容路径中暴露；如未来 rust-vmm 推出独立的 iommufd crate，会以 workspace 子 crate 形式发布在 vfio 仓库。本节不再假装存在这两个 crate。

启动与兼容层

这一层提供虚拟机启动所需的内核加载、硬件信息传递、legacy 设备兼容能力，是 Guest OS 正常引导的基础。

vm-superio / vm-superio-ser

经典超级 I/O 控制器的模拟实现，包含：

  • Serial<T, EV, W>：16550A UART 串口（PC 与多数嵌入式平台通用）
  • Rtc<EV>：ARM PL031 RTC（注意是 ARM 的 PL031，不是 PC 上的 CMOS RTC，也不是 i8042）
  • I8042Device：极简 i8042 PS/2 控制器，目前仅模拟 CPU Reset 命令用于关机通告

vm-superio-ser 提供配套的 *StateSer 序列化结构，支持热迁移时 legacy 设备状态的 save/restore。

最小示例（16550A UART）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
use std::io::{Error, Result};
use std::ops::Deref;
use vm_superio::{Serial, Trigger};
use vmm_sys_util::eventfd::EventFd;

struct EventFdTrigger(EventFd);
impl Trigger for EventFdTrigger {
    type E = Error;
    fn trigger(&self) -> Result<()> { self.0.write(1) }
}
impl Deref for EventFdTrigger {
    type Target = EventFd;
    fn deref(&self) -> &EventFd { &self.0 }
}

let intr = EventFdTrigger(EventFd::new(libc::EFD_NONBLOCK).unwrap());
let mut serial = Serial::new(intr, Vec::<u8>::new()); // 输出可换 io::stdout()

serial.write(0, b'H').unwrap();      // 写 THR -> 立刻刷到 out
serial.write(0, b'i').unwrap();
let input = b"abc";
if serial.fifo_capacity() >= input.len() {
    serial.enqueue_raw_bytes(input).unwrap();   // 把数据塞进 RX FIFO，触发 RDA 中断
}
let _ = serial.read(0);              // 从 RBR 读

最小示例（PL031 RTC）：

1
2
3
4
5
6
7
8
9
10
11
12
13
use std::time::{SystemTime, UNIX_EPOCH};
use vm_superio::Rtc;

const RTCDR: u16 = 0x0;   // Data Register
const RTCLR: u16 = 0x8;   // Load Register

let mut rtc = Rtc::new();
let now = SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() as u32;
let mut data = now.to_le_bytes();
rtc.write(RTCLR, &data);                 // 设置当前时间
rtc.read(RTCLR, &mut data);
assert_eq!(now, u32::from_le_bytes(data));
rtc.read(RTCDR, &mut data);              // 读出递增后的时钟值

linux-loader

Linux 内核加载器，按架构提供不同的具体实现：

Loader feature 适用范围
loader::elf::Elf elf x86_64：同时承担 Linux 64-bit boot protocol 与 PVH boot protocol，PVH 入口由 ELF Note 发现，编码在结果的 pvh_boot_cap 字段
loader::bzimage::BzImage bzimage x86_64：传统 bzImage
loader::pe::PE pe aarch64 / riscv64：内核 Image（PE/COFF 格式）

注意：PVH 不是独立 loader，而是 Elf loader 通过 KernelLoaderResult::pvh_boot_cap 暴露的能力。

核心 API：trait KernelLoader::load、返回值 KernelLoaderResult（kernel_load、kernel_end、setup_header、pvh_boot_cap）、独立函数 load_cmdline、命令行构造器 Cmdline。

最小示例（节选自 README，bzImage）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
use std::fs::File;
use linux_loader::loader::bzimage::BzImage;          // 也可换成 elf::Elf / pe::PE
use linux_loader::loader::{KernelLoader, load_cmdline, Cmdline};
use vm_memory::{GuestAddress, GuestMemoryMmap};

let gm: GuestMemoryMmap<()> =
    GuestMemoryMmap::from_ranges(&[(GuestAddress(0), 256 << 20)]).unwrap();
let mut kernel = File::open("bzImage").unwrap();

let res = BzImage::load::<File, GuestMemoryMmap<()>>(
    &gm,
    Some(GuestAddress(0x10_0000)),   // kernel_offset
    &mut kernel,
    Some(GuestAddress(0x10_0000)),   // himem_start
).expect("load bzImage");

let mut cl = Cmdline::new(0x1_0000).unwrap();
cl.insert_str("console=ttyS0 reboot=k panic=1").unwrap();
load_cmdline(&gm, GuestAddress(0x2_0000), &cl).unwrap();
println!("kernel loaded at {:#x}, end {:#x}", res.kernel_load.0, res.kernel_end);

vm-fdt

扁平化设备树（FDT/DTB）生成库，符合 Devicetree Specification 规范。在 aarch64、riscv64 等架构下，它负责向 Guest OS 传递硬件拓扑、内存布局、中断控制器、设备地址等启动信息。

核心 API：FdtWriter（new / begin_node / end_node / finish）、节点句柄 FdtWriterNode、属性 setter（property_string / property_u32 / property_u64 / property_array_u32 / property_array_u64 / property_null / property_string_list / 裸字节 property）。

最小示例（来自 README）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
use vm_fdt::{Error, FdtWriter};

fn create_fdt() -> Result<Vec<u8>, Error> {
    let mut fdt = FdtWriter::new()?;

    let root = fdt.begin_node("")?;
    fdt.property_string("compatible", "linux,dummy-virt")?;
    fdt.property_u32("#address-cells", 0x2)?;
    fdt.property_u32("#size-cells", 0x2)?;

    let chosen = fdt.begin_node("chosen")?;
    fdt.property_u32("linux,pci-probe-only", 1)?;
    fdt.property_string("bootargs", "panic=-1 console=hvc0")?;
    fdt.end_node(chosen)?;

    let memory = fdt.begin_node("memory")?;
    fdt.property_string("device_type", "memory")?;
    fdt.end_node(memory)?;

    fdt.end_node(root)?;
    fdt.finish()                       // -> Vec<u8>，可直接写入 guest 物理内存
}

工程化与参考实现

本节的三个项目都不是 crate（crates.io 上未发布），而是配套基础设施仓库。

rust-vmm-ci

社区统一的 CI 测试框架（Buildkite pipeline + pytest），通过 git submodule 引入到各 rust-vmm 仓库，提供一致的单元测试、格式检查（rustfmt）、Clippy、依赖漏洞审计、覆盖率检查。

rust-vmm-container

预配置的开发测试 Docker 镜像（rustvmm/dev），内置 Rust 工具链、x86_64 / aarch64 / riscv64 平台的内核头文件、QEMU 测试工具、依赖库等，让开发者一键搭建一致的 rust-vmm 开发与测试环境。

vmm-reference

官方参考 VMM 实现，通过极少量胶水代码串联起核心 rust-vmm 组件，构建出一个可直接运行的最小功能虚拟机。注意它声明为「实验性」、不应用于生产，定位是学习 / 验证 / 二次开发的范本。

生态落地与应用价值

rust-vmm 组件已经成为业界 Rust VMM 的事实标准，被大量生产级项目广泛复用：

  • Firecracker（AWS）：Serverless 微虚拟机标杆，核心依赖 kvm-ioctls、vm-memory、virtio-queue、linux-loader、vm-superio、event-manager 等组件，实现毫秒级启动与极低内存开销
  • Cloud Hypervisor：云原生通用 VMM，Kata Containers 主流后端之一，几乎覆盖全部 rust-vmm 组件，支持热迁移、TDX/SEV 机密计算、VFIO 直通等高级能力
  • Dragonball（蚂蚁/阿里）：Kata Containers 内置 VMM，针对容器场景优化，深度复用 rust-vmm 模块化能力
  • StratoVirt（华为 openEuler）：面向云、边缘、嵌入式的轻量化虚拟机，跨架构支持依托 rust-vmm 实现
  • crosvm（Google）：ChromeOS / Android 的沙盒虚拟机，是 rust-vmm 组件的重要上游贡献者

与传统 QEMU 相比，基于 rust-vmm 构建的 VMM 拥有天然内存安全、攻击面极小、按需裁剪、启动极速等优势，尤其适合 Serverless 函数计算、安全容器、机密计算、边缘虚拟化等新一代云场景。

总结

rust-vmm 的核心价值，在于用 Rust 的内存安全特性与模块化设计，重新定义了虚拟化基础设施的构建方式。它终结了各个 VMM 项目重复造轮子的局面，将 KVM 交互、内存管理、VirtIO 协议、设备模型等通用能力沉淀为标准化组件，让开发者可以聚焦业务场景创新，而非重复实现底层虚拟化逻辑。

随着云原生与安全需求的持续升级，rust-vmm 生态仍在不断扩展 ——RISC-V 架构（KVM / linux-loader / vm-memory 已稳定支持）、机密计算（TDX / SEV / SEV-SNP / pKVM）、更多设备模型（sound、video、scmi）都在持续推进。它不仅是 Rust 语言在系统级领域的标杆项目，更是下一代云基础设施的重要技术基石。

参考链接