ACRN Hypervisor 简介

学习虚拟化，建议按照顺序依次学习。

虚拟化入门笔记

1、ACRN 的由来

Project ACRN 官网

随着物联网 （IoT）与边缘计算系统的快速发展，开发者面临日益复杂的系统需求：设备需同时支持多样化的硬件资源、操作系统及软件工具，而传统数据中心级的虚拟化方案往往因体积庞大、启动缓慢、缺乏实时性 与安全关键特性，难以适用于资源受限的嵌入式环境。为应对这一挑战，ACRN（读作 "acorn"）应运而生（acorn 英文意思为橡子。寓意虽然开始很小，但最终可以长的很大，与该项目希望通过社区参与成长的方式相似）。

ACRN 由 Linux 基金会于 2018 年 3 月发布，是一个专为 IoT 和边缘计算场景 设计的开源 Type-1 运行在裸机上的 Hypervisor，从底层架构上针对小体积、快速启动、硬/软实时 支持以及功能安全隔离进行优化。其代码库精简（约 4 万行），远小于通用数据中心 Hypervisor（通常超过 15 万行），显著降低性能开销，同时提供近裸机级别的响应能力。ACRN 支持在同一 SoC 上安全地共存多个异构工作负载------包括安全关键型与非关键型任务------通过 Intel VT 技术实现强隔离，并支持静态 CPU 分配、LAPIC 与 PCI 设备直通、运行时零 VMExit 等关键实时特性。

VMExit（Virtual Machine Exit）是 Intel VT-x 虚拟化技术中的一个硬件机制：

当运行在 VMX Non-Root 模式（即 Guest VM）中的虚拟机执行某些敏感指令或触发特定事件时，CPU 会自动暂停该 VM 的执行，并将控制权交还给 Hypervisor（运行在 VMX Root 模式），这个过程就叫 VMExit。

ACRN 架构采用"服务虚拟机"（Service VM）模式，将大部分设备模拟逻辑（即 ACRN Device Model, DM）置于特权 VM 中执行，既保持 Hypervisor 内核极简，又通过丰富的 I/O Mediator 实现设备在多个客户 VM 间的高效共享；同时支持对时间敏感应用所需的设备直通（passthrough），满足低延迟需求。它原生支持 Linux、Zephyr、Windows 等多种操作系统，并可通过灵活的场景配置（shared、partitioned 或 hybrid）适配工业自动化、智能零售、车载系统等广泛边缘应用场景。

作为真正开放的解决方案，ACRN 以 BSD-3-Clause 许可证发布，提供透明、可定制、可扩展的参考平台，大幅降低嵌入式虚拟化的研发门槛，并支持与 Kubernetes、Docker（通过 Kata Containers）及 OpenStack 等主流编排框架集成，为边缘工作负载的统一管理奠定基础。

2、ARCN 高层架构

ACRN 是一种 Type1 型 Hypervisor，这意味着它直接运行在裸机硬件上。它采用混合虚拟机管理器（Virtual Machine Manager------VMM）架构，使用特权 Service VM 来管理 I/O 设备并提供 I/O mediation。它支持多个 User VMs，每个 User VMs 可以运行不同的操作系统。通过在独立的虚拟机中运行系统，可以隔离虚拟机及其应用程序 ，从而减少潜在的攻击面并最大限度地减少干扰，但可能会增加应用程序的延迟。

ACRN 充分利用 Intel VT-x 硬件虚拟化技术，运行于 CPU 的 VMX Root 模式（即 VMM 模式），作为系统的最高权限管理者。所有虚拟机------包括负责设备管理的 Service VM 和各类 User VM------均运行在 VMX Non-Root 模式（Guest 模式）。当虚拟机执行敏感操作（如访问 I/O 端口或修改页表）时，CPU 会自动触发 VM Exit，将控制权交还给 ACRN，由其安全地模拟或授权操作。这种硬件级隔离机制是 ACRN 实现强安全性和确定性的基石。

这里说的 ACRN，可以理解为，就是 ACRN Hypervisor

Service VM 以系统最高的虚拟机优先级 运行，以确保满足设备对时间敏感的要求和系统服务质量 (QoS)。Service VM 任务以混合优先级运行。当回调处理特定用户虚拟机的请求时，Service VM 中相应的软件（或转发器）将继承用户虚拟机的优先级。

如前所述，虚拟机使用的硬件资源可以配置为两部分，如下混合虚拟机示例配置所示：

Figure 1 ACRN High-Level Architecture Hybrid Example

如 Figure 1 左侧所示，我们划分了资源，这些资源专用于由 Hypervisor 启动的 User VM（在 SVM 启动之前）。该 pre-launched VM 独立于其他 VM 运行，并拥有专用的硬件资源，例如 CPU 核心、内存和 I/O 设备。其他 VM 甚至可能不知道该 pre-launched VM 的存在。因此，它可以作为安全虚拟机运行硬件故障检测代码，并在系统发生严重故障时采取紧急措施。其他 VM 的故障或 SVM 的重启不会直接影响该 pre-launched VM 的运行。

如 Figure 1 右侧所示，剩余的硬件资源由服务虚拟机 (Service VM) 和用户虚拟机 (User VM) 共享。SVM 由 Hypervisor 在所有 pre-launched VM 启动后启动。SVM 可以通过运行本地驱动程序直接访问剩余的硬件资源，并通过设备模型（Device Model）向 User VMs 提供设备共享服务。这些启动后的 User VMs 可以运行多种操作系统，包括 Ubuntu 或 Windows，或者实时操作系统，例如 Zephyr、VxWorks 或 Xenomai。由于实时虚拟机 (RTVM) 具有实时功能，因此可用于软件可编程逻辑控制器 (PLC)、进程间通信 (IPC) 或机器人应用。这些共享的 User VMs 可能会受到 SVM 故障的影响，因为它们可能依赖于 SVM 提供的设备访问服务。

Service VM 拥有包括平台设备在内的大部分设备，并提供 I/O 管理。值得注意的是，分配给 pre-launched User VM 的设备除外。某些 PCIe 设备可以通过虚拟机配置传递给启动后的 User VMs。

ACRN hypervisor 还运行 ACRN VM manager，用于收集用户虚拟机的运行信息，并控制用户虚拟机，例如启动、停止和暂停虚拟机，以及暂停或恢复虚拟 CPU。

3、面向场景的静态配置模型

ACRN 采用 "按场景定制"（Scenario-Based Static Configuration）的构建范式，摒弃了传统虚拟化平台"单一通用二进制 + 运行时配置"的模式。其核心理念是：在编译阶段，就将 Hypervisor 与目标硬件及应用需求深度绑定，生成高度优化的专用镜像。每个场景（Scenario）通过 XML 文件明确定义：

• 虚拟机的数量、类型（RTVM、Safety VM、普通 User VM 等）
• CPU 核心与内存的静态分配
• 设备归属（哪些设备直通给哪个 VM，哪些由 Service VM 共享）
• I/O 策略、启动顺序等

配合由 Board Inspector 工具自动生成的硬件描述文件（board.xml） ，开发者可使用 ACRN Configurator 图形工具，基于预设模板（如 Industry、Hybrid、Partitioned）快速定制自己的场景配置。这种静态配置模型带来三大关键优势：

• 极简架构：无需内置复杂的运行时配置解析器，显著降低 Hypervisor 逻辑复杂度；
• 超小体积：避免引入冗余代码，确保 Hypervisor 代码量稳定控制在 4 万行以内；
• 极速启动：省去启动时的配置解析开销，满足工业与车载场景对毫秒级启动的要求。

正因如此，ACRN 能够在资源受限的嵌入式平台上，同时实现强实时性、功能安全与灵活部署------这正是其作为 IoT 与边缘参考 Hypervisor 的核心竞争力所在。

以下是三种示例场景类型和图表，用于说明如何定义自己的配置场景。

3.1 共享（shared）

共享是一种传统的虚拟机间计算、内存和设备资源共享模型。ACRN hypervisor 启动 Service VM。Service VM 随后启动任何 Post-launched User VMs，并通过 Device Mode 提供设备和资源共享协调。Service VM 运行本地设备驱动程序来访问硬件，并为 User VMs 提供 I/O 协调。

Figure 2 ACRN High-Level Architecture Shared Example
  由于设备和应用程序的使用寿命较长，虚拟化在工业环境中尤为重要。虚拟化使工厂能够通过使用虚拟机来运行远超预期使用寿命的旧控制系统和操作系统，从而实现控制系统硬件的现代化。 例如，一条使用 Windows XP 和专有控制软件的生产线，可通过 ACRN 将其完整迁移至新一代工控服务器（硬件更新、软件无需修改），无需重写代码，同时在同一硬件上新增 AI 质检或远程运维功能等

ACRN hypervisor 需要运行不同的工作负载 且彼此之间几乎没有干扰 ，增强系统安全 功能，同时运行对实时性 要求极高的工作负载和通用计算工作负载，并进行数据分析以采取及时行动和预测性维护。

ACRN 的核心价值：在一个物理设备上安全、高效地整合多种异构任务

在这个例子中，一个启动后的用户虚拟机提供人机界面（HMI）功能，另一个提供人工智能（AI）功能，一些计算功能在 Kata 容器中运行，而 RTVM 运行需要硬实时特性的软可编程逻辑控制器（PLC）。

• SVM 为其他虚拟机提供设备共享功能，例如磁盘和网络中介。它还可以运行编排代理，从而允许使用 Kubernetes 等工具对用户虚拟机进行编排。

用户虚拟机（如 HMI、AI、RTVM）能够被统一调度、自动部署和集中管理。这种"可编排"能力，是构建大规模、可维护的工业边缘计算基础设施的关键支撑

• 人机界面（HMI）应用操作系统可以是 Windows 或 Linux。
• ACRN 可以支持软实时操作系统（例如用于软 PLC 控制的 preempt-rt Linux），或者支持抖动较小的硬实时操作系统。

3.2 分区（partitioned ）

Figure 3 ACRN High-Level Architecture Partitioned Example

在某些应用场景中，用户虚拟机（User VM）需要完全独立于其他虚拟机运行 ，以确保最高级别的确定性、隔离性和可靠性 。为此，ACRN 支持资源分区（Partitioned）模型：在此模式下，每个分区型 User VM 的硬件资源（如 CPU 核心、内存、I/O 设备等）均在系统启动前静态分配 ，且不与其他 VM 共享。

这类分区型 VM 由 ACRN Hypervisor 直接在系统引导阶段启动 ，无需依赖 Service VM 或 ACRN Device Model。它们通过原生设备驱动 直接访问专属硬件资源，从而避免了中介层带来的延迟或潜在故障点，特别适合对实时性、安全性或稳定性有严苛要求的工作负载。

典型用例包括：

• 实时虚拟机（RTVM）：用于软 PLC、运动控制等硬实时任务；
• 安全关键虚拟机（Safety VM）：运行故障监测、紧急停机等高可靠功能；
• 标准隔离 VM：需强隔离但无实时需求的通用应用。

示例场景： 在一个简化的分区配置中，两个 User VM 均被静态分配独立的硬件资源，彼此完全隔离，互不可见。Hypervisor

在启动时自动并行加载这两个 VM，整个系统无需 Service VM 参与，架构简洁、启动迅速、行为可预测。

该模型通过消除资源共享与运行时依赖，为关键任务提供了接近裸机的性能与可靠性，是构建功能安全（Functional Safety）和确定性边缘系统的重要基础。

3.3 混合（hybrid）

Figure 4 ACRN High-Level Architecture Hybrid-RT Example

ACRN 的混合型场景在一个统一的硬件平台上同时支持资源分区（partitioning）与资源共享（sharing），兼顾确定性关键任务与灵活通用计算的需求。在此模型中：

• 预启动用户虚拟机（Pre-launched User VM）：
  • 由 Hypervisor 在系统引导早期直接启动，拥有静态分配且完全独占的硬件资源（如专用 CPU 核、内存和 I/O 设备），与其他虚拟机严格隔离。这类 VM 通常用于运行硬实时（Hard Real-Time）或安全关键（Safety-Critical）工作负载。
• 服务虚拟机（Service VM）：
  • 在所有预启动 VM 启动完成后，由 Hypervisor 启动。它拥有对剩余硬件资源的直接访问权限，并通过内置的 ACRN Device Model（设备模型）为后续 VM 提供设备模拟与 I/O 中介服务。
• 后启动用户虚拟机（Post-launched User VM）：
  • 由 Service VM 中的 Device Model 动态创建，共享剩余系统资源，适用于非实时、非安全关键的通用任务（如人机界面、数据分析、AI 推理等）。

典型混合实时场景示例：

一个预启动的 实时虚拟机（RTVM）由 Hypervisor 直接加载，用于执行微秒级响应的控制逻辑（如软 PLC）；与此同时，Service VM 启动一个后置的通用 User VM，运行非实时应用（如监控后台或 Web 服务）。两者共存于同一 SoC，互不干扰，各司其职。 该架构充分发挥了 ACRN "按需虚拟化" 的设计理念------在单一硬件上实现强隔离的关键任务与高灵活性的通用计算的高效融合，是工业自动化、智能边缘和车载系统等复杂场景的理想选择。

4、Device Access Models in ACRN

4.1 设备虚拟化与设备共享概述

由于设备可能需要在多个 VM 之间共享，ACRN 通过 device emulation（设备模拟） 的方式，为 VM 及其 Guest OS 提供对共享设备的访问能力。

从虚拟化架构的发展来看，传统上主要存在以下三种 device emulation 方案：

a. Hypervisor 内部的 device emulation

在这种方案中，device emulation 直接实现于 hypervisor 内部。

VMware Workstation（基于 Host OS 的 hypervisor）采用了这种方式。

Hypervisor 内部包含了常见设备的模拟实现，使多个 Guest OS 可以共享这些设备，例如：

• virtual disk
• virtual network adapter
• 以及其他必要的平台设备

---

b. 用户态 device emulation（User space device emulation）

在该方案中，device emulation 不再嵌入 hypervisor，而是由独立的 用户态应用程序 实现。

QEMU 是这一模型的典型代表，也被多个 hypervisor 采用。

这种方式的优势在于：

• device emulation 与 hypervisor 解耦
• 同一套 device model 可以被不同 hypervisor 复用
• 避免将复杂的设备模拟逻辑放入运行于特权态的 hypervisor 中
• 可以灵活地实现任意类型的设备模拟

---

c. Paravirtualized（PV）drivers

Paravirtualized device model（半虚拟化设备模型） 最早由 XEN Project 引入。

在该模型中：

• hypervisor 中包含物理设备驱动
• Guest OS 中包含 hypervisor-aware 的 PV driver
• Guest driver 与 hypervisor driver 协同完成设备访问

---

Device Sharing 的代价

设备共享并非没有成本。

无论 device emulation 是在 hypervisor 内部实现，还是通过独立 VM 中的用户态程序完成，都会引入额外的性能开销。

只要设备确实需要被多个 Guest OS 共享，这种开销通常是可以接受的。

但如果设备不需要共享，则可以采用更高效的访问方式，例如 device passthrough。

4.2 Device Model

在 ACRN 架构中，Device Model（DM）是一个运行于 Service VM 的用户态的程序，用于在不直接暴露物理设备的情况下，为 User VM 提供设备访问能力。

ACRN 中以下两种设备访问方式依赖 Device Model 实现：

• device emulation
• para-virtualization

4.2.1 device emulation

在 ACRN 的 device emulation 架构中：

• Service VM（SVM）拥有所有未被预先分配给 pre-launched User VM 的物理设备
• 对于 User VM，这些设备并不会被直接暴露
• ACRN Device Model（DM）运行于 SVM 的用户态，通过软件方式模拟完整的硬件设备模型

在该模式下：

• User VM 认为自己访问的是一个真实的硬件设备
• 设备驱动运行在 User VM 内，使用标准的 MMIO / PIO / IRQ 接口
• 相关的设备访问会触发 VM exit，由 Hypervisor 捕获并转发给 DM
• DM 在用户态中完成：
  • 寄存器模型维护
  • 设备状态机模拟
  • 中断注入
  • 数据路径的转发或仿真

典型的 device emulation 设备包括：

• UART
• RTC
• e1000（网络设备）

ACRN 实现的多种全虚拟化设备

该模式具有良好的兼容性，可以支持未修改的 Guest OS 和驱动，但由于设备行为完全由软件模拟，其性能和可扩展性相对受限。

4.2.2 para-virtualization

Para-virtualization 在 ACRN 中主要通过 Virtio 框架实现，是 device emulation 的一种高性能替代方案。

在该模式下：

• User VM 不再使用传统硬件设备模型
• 而是使用 Virtio 前端驱动（Virtio frontend）
• 对应的 Virtio 后端（Virtio backend) 运行在 SVM 的 Device Model（DM）中

其核心特征包括：

• 前后端通过共享内存中的 virtqueue 进行通信
• 避免了寄存器级的设备模拟
• 显著减少 VM exit 次数
• 提高 I/O 吞吐和降低延迟

Para-virtualization 的访问路径可以概括为：

User VM (Virtio frontend driver)
    ↓
Shared memory (Virtqueue)
    ↓
Device Model (Virtio backend)
    ↓
SVM OS 原生驱动
    ↓
物理硬件

在该架构中：

• DM 负责：
  • Virtio 设备后端实现
  • 与 SVM 内核驱动或系统服务交互
• Hypervisor 负责：
  • 共享内存映射
  • 中断与通知机制
  • 虚拟设备生命周期管理

Para-virtualization 在性能与隔离性之间提供了良好的平衡，是 ACRN 中 User VM 默认推荐的设备访问方式之一。

4.3 Device Passthrough

Device passthrough 是 ACRN 中一种不依赖 Device Model 的设备访问方式，也是性能最高、虚拟化开销最低的模式。

在该模式下，物理设备被直接分配给某个 User VM，User VM 使用原生设备驱动，设备的 MMIO、DMA 以及中断请求不再经过 Device Model，DM 在该路径中完全不参与。Device passthrough 是 ACRN 中性能最高、开销最低的设备访问模式。

在该模式下：

• 物理设备被 直接分配给某个 User VM
• User VM 使用原生设备驱动
• 设备的 MMIO、DMA 及中断请求不经过 Device Model
• DM 在该路径中 完全不参与

Figure 5 Device Passthrough

Device passthrough 主要依赖以下组件协同完成：

• Hypervisor
  • 负责设备分配与隔离策略
  • 配置 VM 对设备寄存器空间的访问权限
• IOMMU
  • 在不同 CPU 架构中叫法不同（Intel 中叫 VT-d。AMD 中叫 IOMMU。ARM 中叫 SMMU）
  • 提供 DMA 地址转换与访问隔离
  • 防止设备越权访问其他 VM 或 Hypervisor 内存
• 中断重映射机制
  • 确保设备中断只能送达目标 VM

其访问路径如下：

User VM driver
    ↓
MMIO / DMA / Interrupt
    ↓
Physical Device

由于设备被独占使用，device passthrough 能够提供接近裸机的性能，非常适合以下场景：

• 高性能网络或存储设备
• GPU、加速器等对延迟敏感的设备
• 对实时性要求较高的工作负载

需要注意的是，该模式对硬件虚拟化能力 依赖较强，且在设备共享和动态管理方面灵活性相对较低。

4.4 Device Sharing vs Dedicated Device Assignment

与 device passthrough 不同，基于 Device Model 的 device emulation 与 para-virtualization 并不要求物理设备被独占分配给单个 VM。

在这两种模式下，多个 User VM 可以通过 DM 共享同一个物理设备，而 DM 负责在不同 VM 之间完成设备访问的复用与仲裁。例如，多个 VM 可以同时使用同一个物理网络接口或存储设备，而无需为每个 VM 单独分配独立的硬件资源。

这种设备共享能力在以下场景中尤为重要：

• 物理设备数量受限的平台（如嵌入式或边缘计算场景）
• 需要同时运行多个轻量级或功能性 VM
• 对设备吞吐要求中等，但更关注系统整体资源利用率的工作负载

相比之下，device passthrough 虽然能够提供接近裸机的性能，但由于设备被独占使用，其可扩展性受限。当系统中 VM 数量大于可用物理设备数量时，device passthrough 将不再适用。

因此，ACRN 通过同时支持 device emulation、para-virtualization 以及 device passthrough，为不同应用场景提供了在性能、资源利用率和系统复杂度之间的灵活权衡。