CustomVMM：打通CloudHypervisor与macOS Hypervisor.framework的移植实践

之前在折腾 macOS 下的轻量级虚拟化方案时，我发现了一个比较有价值的移植方向：把 CloudHypervisor 这种云原生 VMM 移植到苹果的 Hypervisor.framework 上，并且通过一个自定义的 CustomVMM 层来做适配。这个方向网上资料不多，踩坑也比较多，所以整理这篇文章，讲清楚概念、移植架构、核心代码实现以及调试排错思路。适合对虚拟化底层感兴趣的后端、系统开发者和 macOS 平台开发者阅读。

整个标题看起来很短，但信息量并不小。CloudHypervisor 是 rust-vmm 生态里的明星项目，Hypervisor.framework 则是 Apple 在 macOS 上提供的原生虚拟化 API。二者原本不是一套体系，把 CloudHypervisor “搬”到 macOS 上，不能只做简单的 API 替换，而是需要重新设计一层 VMM 兼容层。这就是标题中 CustomVMM 存在的意义。

本文会从背景概念开始，逐步拆解 Apple Hypervisor.framework 的能力边界，分析 CloudHypervisor 的架构抽象，再给出一个最小可运行的 VMM 实现思路，最后总结移植过程中最常见的坑和工程建议。

1. 背景与核心概念

1.1 CloudHypervisor 是什么

CloudHypervisor 是一个基于 rust-vmm 组件库构建的开源虚拟化监视器（VMM），定位是云原生工作负载场景下的轻量级虚拟机运行环境。它的目标很明确：只提供运行云工作负载所需的最小功能集，去掉传统虚拟机监视器中的那些历史包袱和陈旧设备模型。

和 QEMU 这种全能型模拟器不同，CloudHypervisor 更强调“轻量”和“安全”。它默认使用现代 virtio 设备模型，支持 PCIe、ACPI、VFIO 直通、NVDIMM 等特性，同时用 Rust 的内存安全特性来降低 VMM 自身的安全风险。

在传统架构中，CloudHypervisor 主要运行在 Linux 上，通过 KVM 使用硬件虚拟化能力；同时也有 Windows 平台的 WHPX（Windows Hypervisor Platform）后端。它本身并不直接操作硬件，而是通过一个 hypervisor 抽象层来对接不同的底层虚拟化接口。

1.2 Hypervisor.framework 是什么

Hypervisor.framework 是 Apple 在 macOS 10.10 时代推出的原生虚拟化框架。它提供给用户态程序直接创建和管理虚拟机的能力，不需要依赖第三方虚拟化软件，也不需要加载内核模块。

从设计上看，Hypervisor.framework 更像是一个“半成品”虚拟化框架：

• 它负责创建 VM、映射内存、创建 vCPU 并执行。
• 它不提供任何设备模拟。
• 它不提供 BIOS/UEFI 固件。
• 它不提供文件系统镜像的解析能力。

也就是说，苹果把硬件虚拟化的“发动机”交给了开发者，但“变速箱”“方向盘”和“车身”都要自己造。这正是为什么基于 Hypervisor.framework 的虚拟化方案通常都会搭配一个完整的用户态 VMM，比如 QEMU 的 macOS 版本，或者像 UTM 这样基于 QEMU 的 GUI 工具。

1.3 为什么要做这次移植

把 CloudHypervisor 移植到 Hypervisor.framework，最直接的动机是场景需要。在 macOS 上，虽然 QEMU 能跑，但 QEMU 的功能太重，启动速度、内存占用和镜像管理在云原生开发场景下并不理想。CloudHypervisor 的优势是轻量、快速启动、rust-vmm 纯用户态组件，非常适合做本地开发环境、CI 测试节点或者边缘设备上的轻量虚拟机。

另一个动机是技术验证。CloudHypervisor 的架构把 hypervisor 后端做了一个相对清晰的抽象，只要你能按照抽象层去实现一个新的后端，理论上就能把整个 VMM 运行在不同的底层框架上。移植到 Hypervisor.framework，既是对这个架构设计的一种实战检验，也能让 rust-vmm 生态在 macOS 上获得一个新的运行入口。

1.4 CustomVMM 的职责边界

标题里的 CustomVMM 并不是指 CloudHypervisor 本身，而是指为了连接 CloudHypervisor 和 Hypervisor.framework 而额外实现的一层“自定义虚拟机监视器”。

它要完成的工作包括：

• 对接 Hypervisor.framework 的 C API。
• 管理 VM 生命周期。
• 管理客户机物理内存映射。
• 创建和调度 vCPU。
• 处理 VM_EXIT 退出事件。
• 模拟必要的中断控制器和时钟设备。
• 为 CloudHypervisor 上层设备模型提供统一接口。

简单来说，CustomVMM 是介于 CloudHypervisor 的 hypervisor 抽象层和 Apple Hypervisor.framework 之间的“适配器”，同时它也在承担部分传统 VMM 的功能，比如中断控制器和 ACPI 表生成。

看到这里，你可能已经感觉到了，这不是一次简单的 API 换皮。我们需要深入理解 CloudHypervisor 的内部设计，才能知道 CustomVMM 应该提供哪些能力。

2. 架构分析与移植难点

2.1 CloudHypervisor 的虚拟化后端抽象

CloudHypervisor 内部把 hypervisor 的能力抽象成几个核心对象：整体的 Hypervisor、虚拟机 Vm、虚拟 CPU Vcpu，以及内存管理区域。

这种抽象的目标是让上层设备模型代码不依赖具体的底层虚拟化技术。上层只需要知道“我有一个 Vm，可以创建 Vcpu，可以映射内存，可以设置寄存器”，而不需要关心底层是 KVM、WHPX 还是 Hypervisor.framework。

所以，移植工作的第一步不是写业务代码，而是搞清楚 CloudHypervisor 依赖了底层后端的哪些能力。通过对源码的分析，大致可以归纳出这些关键能力：

1. 创建和销毁虚拟机实例。
2. 在客户机物理地址空间映射内存区域。
3. 创建 vCPU，并为每个 vCPU 设置初始状态。
4. 运行 vCPU，并在退出时获取退出原因。
5. 读写客户机寄存器。
6. 注入中断或设置中断控制器。
7. 处理客户机物理地址空间中的 MMIO 访问。

幸运的是，Hypervisor.framework 对上面大部分能力都有对应的 API 支持。但“支持”和“好用”是两回事，细节里有很多坑。

2.2 Hypervisor.framework 与 KVM 的差异对比

为了更清晰地说明移植难点，这里把 Hypervisor.framework 和 Linux 上常用的 KVM 做一次功能对比。

从这个表能看出，Hypervisor.framework 更像是一个“最小化”的 KVM。它把内存映射和 vCPU 执行这些最核心的能力暴露出来，把中断控制器、设备模型、时钟等全部留给用户态。

在 Linux 上，CloudHypervisor 可以依赖 KVM 提供 irqchip 能力，配合内核的虚拟中断控制器大大简化工作。但在 macOS 上，CustomVMM 必须自己在用户态实现一套中断控制器，并处理与 Apple 虚拟化框架的中断注入接口的对接。

2.3 移植的核心难点

第一个难点是 MMIO 陷阱机制。KVM 在客户机访问不存在的物理地址时，会以退出事件的方式通知用户态，并携带访问地址、访问长度、读写方向等信息。Hypervisor.framework 也提供类似的能力，但需要你手动管理内存映射的粒度。如果你把一大块内存映射成普通内存，客户机访问其中的设备区域时就不会触发陷阱，设备模拟就会失效。因此，设备区域必须保持为未映射状态，或者使用特殊的内存映射标志。

第二个难点是中断控制器。x86 体系中常见的虚拟化设备依赖 PIC、IOAPIC 和 MSI/MSI-X 机制。KVM 提供内核态 irqchip，或者允许用户态注册事件通知。而在 Hypervisor.framework 上，这些都要从零开始。CloudHypervisor 的设备模型中有 virtio-pci 设备，它们依赖 PCI 中断配置和 MSI-X 中断，CustomVMM 需要模拟足够的 8259 PIC 和 IOAPIC 逻辑，从而让客户机内核能够完成中断初始化。

第三个难点是时钟。虚拟机的启动和运行高度依赖时间源。在 KVM 中，时间虚拟化机制比较成熟；在 Hypervisor.framework 上，需要自己设计时钟设备，常见做法是提供一个虚拟 ACPI 定时器（ACPI Timer）或虚拟 HPET。CloudHypervisor 的 ACPI 表中可以暴露这类设备，但底层时钟的读取必须映射到真实的主机时钟。

第四个难点是 virtio 设备的通知路径。CloudHypervisor 里的 virtio 设备使用 MMIO 或 PCIe 配置空间与客户机通信。当客户机写设备通知寄存器时，会产生 MMIO 退出事件，CustomVMM 必须捕获退出事件并将通知转发到对应的 virtio 后端线程。通知链路越长，延迟也越高，这块性能优化要做细致。

3. 环境准备与项目结构

3.1 开发环境要求

要在 macOS 上开发和运行基于 Hypervisor.framework 的 VMM，首先需要满足以下环境条件：

• 一台 Mac 电脑，Intel 或 Apple Silicon 芯片都可以，但开发阶段建议先用 Intel Mac，调试工具更成熟。
• macOS 版本建议使用较新的稳定版本，不同版本对 Hypervisor.framework 的 API 有一定调整。
• 安装 Xcode 以及 Command Line Tools，因为编译 Rust 和访问系统头文件都需要它们。
• 安装 Rust 工具链，建议使用 rustup 管理，并保持 nightly 和 stable 之间的切换能力。

版本方面不需要强求某个具体版本，重点是理解 Hypervisor.framework 的接口会随 SDK 变化。实际开发时，应该以本地 macOS SDK 中的 Hypervisor.h 头文件为准。

3.2 项目目录设计

一个典型的移植项目可以参考下面的目录结构：

cloud-hypervisor-mac/ ├── Cargo.toml ├── src/ │ ├── main.rs │ ├── vmm/ │ │ ├── mod.rs │ │ ├── hypervisor.rs │ │ ├── vm.rs │ │ ├── vcpu.rs │ │ └── memory.rs │ ├── devices/ │ │ ├── mod.rs │ │ ├── interrupt_controller.rs │ │ ├── clock.rs │ │ └── virtio.rs │ └── api/ │ ├── mod.rs │ └── hv_bindings.rs ├── resources/ │ ├── firmware.bin │ └── kernel.bin └── scripts/ └── run.sh

这个结构里，api/hv_bindings.rs是用来放 Hypervisor.framework C API 的 FFI 绑定代码，vmm/目录实现 CustomVMM 核心逻辑，devices/目录放设备模拟代码。

这种分层的好处是，后续如果你想回到 KVM 或 WHPX 后端，只需要在vmm/目录下替换对应的后端实现，上层设备模型可以最大化复用。

3.3 依赖与代码签名权限

Rust 项目里，除了 cloud-hypervisor 自身的依赖之外，通常还需要引入libccrate 来声明 C 语言类型和接口。

更重要的是代码签名权限。在 macOS 上，通过 Hypervisor.framework 创建虚拟机不是任意进程都可以做到的。进程必须具有com.apple.security.hypervisor权限，否则hv_vm_create可能会直接失败。

开发阶段可以通过生成一个带有该 entitlement 的证书来实现签名。在 Xcode 工程中，可以在entitlements文件里添加：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.hypervisor</key> <true/> </dict> </plist>

如果是纯命令行工具，可以通过 codesign 指定 entitlements 文件来签名。这一步不处理好，后面调用 hv_vm_create 时会浪费很多时间排查。

4. 核心实现拆解

4.1 VM 生命周期管理

CustomVMM 的第一块内容是 VM 生命周期管理。封装 Hypervisor.framework 的hv_vm_create和hv_vm_destroy接口。

在 Rust FFI 绑定中，需要先声明外部函数，然后封装一个抽象结构：

// 文件路径：src/api/hv_bindings.rs #![allow(non_camel_case_types)] use libc::{c_int, c_void, size_t}; pub type hv_return_t = c_int; pub type hv_uvaddr_t = *const c_void; pub type hv_ipa_t = u64; pub type hv_vm_t = *const c_void; pub type hv_vcpu_t = *const c_void; pub const HV_SUCCESS: hv_return_t = 0; extern "C" { pub fn hv_vm_create(config: u64) -> hv_return_t; pub fn hv_vm_destroy() -> hv_return_t; pub fn hv_vm_map(addr: hv_uvaddr_t, ipa: hv_ipa_t, size: size_t, flags: u64) -> hv_return_t; pub fn hv_vm_unmap(ipa: hv_ipa_t, size: size_t) -> hv_return_t; pub fn hv_vm_interrupt(vcpu: hv_vcpu_t, irq: u32) -> hv_return_t; }

这里只是 FFI 声明示例，实际头文件中的类型可能更严格，需要按你本地 SDK 进行调整。核心思路是把不安全的 C API 包裹成 Rust 可以安全调用的接口。

4.2 客户机内存初始化与映射

内存管理是 VMM 中最容易出错的部分。CloudHypervisor 支持普通 RAM、MMIO 区域和设备直通区域等多种内存区域。CustomVMM 需要为每种区域选择不同的映射方式。

普通 RAM 的映射非常简单，直接调用hv_vm_map把用户态分配的内存映射到指定的 IPA 地址：

// 文件路径：src/vmm/memory.rs use crate::api::hv_bindings::*; pub const HV_MEMORY_READ: u64 = 1 << 0; pub const HV_MEMORY_WRITE: u64 = 1 << 1; pub const HV_MEMORY_EXEC: u64 = 1 << 2; pub const HV_MEMORY_DEVICE: u64 = 1 << 3; pub fn map_guest_memory( host_addr: *const libc::c_void, guest_addr: u64, size: usize, device: bool, ) -> Result<(), String> { let mut flags = HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC; if device { flags |= HV_MEMORY_DEVICE; } let ret = unsafe { hv_vm_map(host_addr, guest_addr as hv_ipa_t, size, flags) }; if ret != HV_SUCCESS { return Err(format!("hv_vm_map failed, return = {}", ret)); } Ok(()) }

这段代码的关键点是 flags 的设置。普通 RAM 使用 READ/WRITE/EXEC，但设备区域千万不要加上 EXEC 标志，否则客户机可能会把设备区域当成可执行内存，造成不可预期的结果。

5. 实战：最小化 VMM 示例

为了让概念落地，我们写一个最小的 C 语言 VMM。它做的事情很简单：创建一个虚拟机，映射一块内存，创建一个 vCPU，然后尝试运行。它的目的不是启动完整操作系统，而是验证 Hypervisor.framework 的核心链路是否打通。

5.1 创建 VM 与内存映射

// 文件路径：minimal_vmm/main.c #include <Hypervisor/Hypervisor.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #define GUEST_MEM_SIZE (256 * 1024 * 1024) static uint8_t *guest_mem; int create_vm_with_memory(void) { hv_return_t ret; // 创建虚拟机 ret = hv_vm_create(HV_VM_DEFAULT); if (ret != HV_SUCCESS) { printf("hv_vm_create failed with %d\n", ret); return -1; } // 分配客户机物理内存 guest_mem = malloc(GUEST_MEM_SIZE); if (!guest_mem) { printf("malloc failed\n"); return -1; } memset(guest_mem, 0, GUEST_MEM_SIZE); // 将用户态内存映射到客户机物理地址 0x0 ret = hv_vm_map(guest_mem, 0x0, GUEST_MEM_SIZE, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC); if (ret != HV_SUCCESS) { printf("hv_vm_map failed with %d\n", ret); return -1; } return 0; }

这段代码比较容易看懂。先创建 VM，然后分配一块 256MB 的用户态内存，把它映射到客户机物理地址的起始位置。HV_MEMORY_EXEC表示这段内存允许执行，后面如果要加载启动固件，这个标志是必需的。

5.2 创建 vCPU 并读取寄存器

创建 vCPU 时，需要准备一个 vCPU 入口状态结构。不同 macOS 版本中这个结构体的定义会有调整，一般需要初始化寄存器值，并把 rip 设置到客户机代码入口地址。

// vcpu_helpers.h #include <Hypervisor/Hypervisor.h> int setup_vcpu(hv_vcpu_t *vcpu, uint64_t entry, uint64_t stack) { hv_return_t ret; ret = hv_vcpu_create(vcpu, NULL, HV_VCPU_DEFAULT); if (ret != HV_SUCCESS) { printf("hv_vcpu_create failed with %d\n", ret); return -1; } // 设置初始寄存器 uint64_t value = 0; value = entry; ret = hv_vcpu_write_register(*vcpu, HV_X86_REG_RIP, &value); if (ret != HV_SUCCESS) { printf("write RIP failed\n"); return -1; } value = stack; ret = hv_vcpu_write_register(*vcpu, HV_X86_REG_RSP, &value); if (ret != HV_SUCCESS) { printf("write RSP failed\n"); return -1; } return 0; }

这里用到了hv_vcpu_write_register，它是较新 macOS 版本推荐使用的寄存器访问接口。如果是在旧版本 SDK 上开发，可能需要改成通过hv_vcpu_entry_t结构体设置。

5.3 vCPU 执行与退出事件处理

vCPU 创建好之后，核心就是运行循环。这个循环会反复执行 vCPU，每次执行后都会产生一个返回事件，根据返回值判断是正常退出还是异常。

// vcpu_run_loop.c #include <Hypervisor/Hypervisor.h> #include <stdio.h> int run_vcpu(hv_vcpu_t vcpu) { hv_return_t ret; int max_steps = 1000; int steps = 0; while (steps < max_steps) { ret = hv_vcpu_run(vcpu); if (ret != HV_SUCCESS) { printf("hv_vcpu_run failed with %d\n", ret); return -1; } uint64_t rip = 0; ret = hv_vcpu_read_register(vcpu, HV_X86_REG_RIP, &rip); if (ret != HV_SUCCESS) { printf("read RIP failed\n"); return -1; } printf("vCPU stopped at RIP = 0x%llx\n", rip); // 这里应该根据退出原因进行处理。 // 如果是为了验证最小链路，可以先简单 break。 break; } return 0; }

严格来说，hv_vcpu_run的返回值并不能直接告诉我们退出原因，我们还需要读取一些额外的 vCPU 状态或退出信息寄存器来判断是 MMIO 访问、中断等待还是其他事件。这个最小示例只是先把执行链路打通，真正完整实现时需要在这里做事件分发。

5.4 加载引导固件并验证

为了让 vCPU 能真正执行到代码，需要往客户机内存的入口地址写入一段机器指令。最简单的方式是准备一个最小二进制文件，用memcpy拷贝到 guest_mem 的对应位置，然后设置 RIP 指向它。

// load_firmware.c #include <stdio.h> #include <string.h> extern uint8_t *guest_mem; // 一个极简的固件镜像：hlt 指令 static uint8_t minimal_firmware[] = { 0xF4, // hlt }; int load_firmware(uint64_t load_addr) { memcpy(guest_mem + load_addr, minimal_firmware, sizeof(minimal_firmware)); printf("firmware loaded at 0x%llx\n", load_addr); return 0; }

然后修改主流程，把 RIP 设置成load_addr，运行 vCPU，看到它执行到hlt指令后停止，就说明 VM、内存映射、vCPU 创建、寄存器设置和运行循环这一整条链路是通的。

这是整个 CustomVMM 移植工作的地基。地基验证通过后，才能继续往上搭建中断控制器、设备模型和 virtio 后端。

6. 常见问题与排查思路

最常见的问题是第一步权限。很多人写好了代码，一运行发现hv_vm_create直接失败，第一反应是 API 用错了，其实是代码签名权限问题。

排查顺序建议如下：

1. 确认你的进程是否有com.apple.security.hypervisorentitlement。
2. 确认你的应用是经过签名运行的，不能只是终端里直接执行二进制文件。
3. 用codesign -d --entitlements - <可执行文件>查看最终签名结果。
4. 如果不是签名问题，再检查 API 调用参数，比如内存地址是否页对齐。

另一个常见的坑是 MMIO 区域处理。很多虚拟化开发者在 Linux KVM 上习惯了内存映射后由 KVM 自动通知非法访问，但 Hypervisor.framework 的行为不太一样。未映射区域是否会产生 MMIO 陷阱，取决于你的内存布局设计。如果设备区域被映射成了普通可读写内存，客户机对设备的读写就不会退出到用户态，设备模拟必然失败。

调试这类问题时，建议先给虚拟机的物理内存空间画一张完整的地图，把每个地址段的映射类型、访问权限、所属设备都列清楚。这是虚拟化开发最值得投资的工程习惯。

7. 最佳实践与工程建议

7.1 内存管理的安全边界

在写 CustomVMM 的过程中，内存管理是安全风险最高的地方。Hypervisor.framework 允许你把用户态内存直接映射为客户机物理内存，这本质上是一个双向通道：客户机可以读写宿主进程的内存。一旦 VMM 内存布局写错，可能导致客户机访问宿主进程的敏感数据。

工程上建议做到几点：

• 客户机内存使用独立分配的页对齐内存块，不要直接映射 VMM 的栈或堆。
• 对 MMIO 区域要严格区分 DEVICE 内存和普通 RAM。
• 在映射前检查大小、地址对齐和权限标志。
• 销毁 VM 时，先 unmap 所有区域，再释放内存。

7.2 设备模型复用的取舍

CloudHypervisor 已经实现了大量 virtio 设备，比如块设备、网络设备、console 设备等。移植时不要急着重写它们，而是尽量复用 CloudHypervisor 已有的设备模型。CustomVMM 只负责把设备模型的“底层硬件事件”传递给 Hypervisor.framework，具体的数据通路可以沿用 Rust 异步运行时。

但需要注意，CloudHypervisor 的设备模型默认针对 PCIe 总线设计，而 PCIe 总线又依赖 ACPI 表和中断控制器。要移植，必须先保证中断控制器和 PCIe 配置空间能正常工作，否则后面所有 virtio 设备都是空中楼阁。

建议按下面的顺序推进功能：

1. VM 生命周期与内存映射。
2. vCPU 运行循环。
3. 基础中断控制器（PIC/IOAPIC）。
4. ACPI 表和固件加载。
5. 一个最小 virtio console 设备。
6. virtio-blk 和 virtio-net。

每完成一层，就做一次验证，不要一口气堆功能。

7.3 调试与性能优化

Hypervisor.framework 本身没有提供类似 KVM 的详细统计接口，调试起来要更依赖用户态日志。建议在 vCPU 退出循环里增加一个可配置的日志开关，把每次退出的 RIP、退出原因、访问地址和长度打出来。正常运行时关闭日志，排查问题时打开日志。

性能方面，重点优化两点：

• MMIO 退出处理路径。每次客户机访问设备寄存器都会产生一次退出事件，这比 Linux KVM 的某些优化路径要慢。可以将高频访问的设备寄存器集中放在连续的 MMIO 页面中，减少地址切换带来的缓存失效。
• virtio 通知批处理。CloudHypervisor 支持 virtio 的 packed virtqueue，它能在同一物理页面上连续提交多个缓冲描述符，减少通知次数。CustomVMM 要确保每个 MMIO 通知事件都能快速唤醒对应 virtio 后端线程。

7.4 移植工作的落地步骤

如果你真的想把 CloudHypervisor 移植到 macOS Hypervisor.framework 上，建议从 rust-vmm 的组件库入手，而不是直接改 CloudHypervisor 主仓库的大块源码。先编写独立的 hypervisor 后端 crate，让它可以编译成动态库，然后通过 trait 对接 CloudHypervisor 的 hypervisor 抽象层。

这样做的好处是隔离性强。即使 CloudHypervisor 主仓库不断更新，你的 CustomVMM 后端也能相对独立地演进。

8. 总结

CloudHypervisor 移植到 macOS Hypervisor.framework 是一次很有挑战性但也有价值的虚拟化工程探索。通过 CustomVMM 层，可以把 CloudHypervisor 的设备模型和 rust-vmm 生态带到 Apple 平台上，同时也在很大程度上检验了 CloudHypervisor 后端抽象的设计是否足够通用。

核心收获可以归纳为三点：

• Hypervisor.framework 只提供最小化的 CPU 虚拟化和内存管理能力，真正的 VMM 逻辑都要自己实现。
• CloudHypervisor 的 hypervisor 抽象层是移植工作的关键抓手，复用它而不是重写云原生功能。
• 中断控制器、时钟和 virtio 通知路径是移植中最大的三个工程黑洞，需要按顺序逐个击破。

下一步如果你感兴趣，可以先从最小 vCPU 运行循环开始，把本文中的 C 示例跑通，然后尝试用 Rust 重新实现一遍。之后再去研究 PIC/IOAPIC 模拟、ACPI 表生成和 virtio-console，逐步搭建一个真正能启动 Linux 的 macOS 版本 CloudHypervisor。这个方向比较底层，网上可以参考的资料不多，很多问题都需要通过阅读 CloudHypervisor 源码和 Hypervisor.framework 头文件来自己摸索。不过正是这种踩坑过程，才是理解虚拟化最好的方式。