KVM / HVF / WHPX 与 libkrun

定义

硬件虚拟化把「运行另一份内核」变成 CPU 与芯片组的能力。操作系统再把这一能力通过内核模块或框架暴露给用户态：

接口	操作系统	作用
KVM（Kernel-based Virtual Machine）	Linux	内核模块，配合 `/dev/kvm` 创建虚拟 CPU 与内存
HVF（Hypervisor.framework）	macOS	Apple 提供的用户态 hypervisor API，Box 用于 Apple Silicon
WHPX（Windows Hypervisor Platform）	Windows	Windows 的 hypervisor 平台 API，Box 用于 x86_64 资格验证

libkrun 是一个库，而不是一个独立的「虚拟机软件窗口」。调用方在进程内配置 vCPU、内存、根设备与 virtio 设备，然后进入客户机。Box 通过 deps/libkrun-sys 绑定该库，并由 a3s-box-shim 进程执行进入动作。

问题背景

若每个平台都直接编写 KVM ioctl、HVF 或 WHPX 的细节，产品层会与操作系统接口缠在一起。libkrun 把「启动一个用于运行 Linux 容器的 MicroVM」收敛为稳定的 C API，使 Box 可以用同一套 InstanceSpec 描述三端，只在资格检查与少量设备差异上分支。

机制说明

资格：有接口不等于能用

硬件虚拟化需要 CPU 支持、固件未关闭、内核模块已加载，以及当前用户对设备节点的权限。Linux 上常见检查是 /dev/kvm 是否存在、是否可读写。Box 的 a3s-box info 把结果汇总为人类可读的能力报告；host_check.rs 在启动前做同样的预检。预检失败必须阻止创建，而不是改走共享内核。

libkrun 为何要单独进程

krun_start_enter() 的语义是：当前进程变成客户机。这与「库函数返回后再继续处理 CLI」不兼容。Box 因此把 VMM 放进 a3s-box-shim。父进程（ExecutionManager 一侧）保留产品状态、日志与控制通道；子进程负责虚拟化。

平台现状（Box v3.2.7）

Linux/KVM：主要本地 MicroVM 路径，与生命周期、SDK、CRI、snapshot-fork、soak 等门并列。
macOS/HVF：仅 Apple Silicon；Intel macOS 不受支持。持久恢复与无挂载文件系统快照已有物理机门。
Windows/WHPX：真实主机 soak 覆盖生命周期、exec、copy、stats、端口、卷、commit、快照与清理；限制包括单 vCPU，以及无交互 PTY、桥接网络、TEE、snapshot-fork、CRI。通过 OCI Runtime 的 WHPX 资格服务是显式选择加入，默认关闭。

目标架构中，KVM / HVF / WHPX 驱动将下沉到 A3S OCI Runtime 的 utility-VM 路径。当前 MicroVM 生产路径仍由 Box + libkrun 拥有；AllViaOci 不是 Linux 默认。

在 Box 中的位置

FFI 绑定：src/deps/libkrun-sys/。
shim 内的启动：src/shim/src/krun/、vm_launch.rs。
主机检查：src/runtime/src/host_check.rs。
安装与资格：docs/installation.md、docs/windows-whpx.md、docs/ci-kvm-runner.md、docs/ci-hvf-runner.md。

验证命令

a3s-box info

在 Linux 上，输出应包含 KVM 是否可用、VM 后端是否为 krun。若显示 KVM 不可用，省略 --isolation 的 run 应失败，而不是自动改用 Sandbox。