物联网市场的应用场景日益复杂Linux基金会推出开源项目–ACRN

物联网市场的应用场景越来越复杂，越来越多的联网设备需要支持更多的硬件资源、操作系统、软件工具和应用程序。显然，现有的解决方案无法为大量的物联网设备提供相应的解决方案。灵活性，这给开发人员带来了巨大的设计压力。虚拟化技术是解决这些问题的关键。然而，现有的虚拟化解决方案并不能满足物联网开发对轻量级和灵活性的特殊要求。为了适应当前物联网市场的发展趋势，Linux基金会推出了一个开源项目——ACRN，

ACRN 有哪些强大的功能，它是如何实现的？今天，我们将从架构到应用详细分析 ACRN，让开发者可以快速开始使用 ACRN 进行产品设计。

ACRN是为嵌入式设备设计的hypervisor，包括以下两部分：一套hypervisor参考软件和架构，通过虚拟机监视器（Virtual Machine Manager）可以安全地在同一个物理硬件系统上同时运行多个操作。此外，它还定义了一个用于设备虚拟化仿真的参考设计框架，称为“ACRN 设备模型”。

ACRN 管理程序是一种 I 类管理程序，可以直接在物理硬件上运行，用于各种物联网和嵌入式设备解决方案。ACRN 管理程序解决了数据中心管理程序和分区管理程序之间的当前差距。ACRN 管理程序旨在将系统划分为不同的功能域，并与为物联网和嵌入式设备精心挑选的用户操作系统共享优化。

汽车应用案例

ACRN 管理程序的一个有趣案例是用于汽车场景。ACRN 管理程序可用于构建软件定义的驾驶舱 (SDC) 或车载娱乐系统 (IVE)。作为参考实现，ACRN 可以为嵌入式管理程序供应商解决方案提供良好的基础，以及一组用于 I/O 设备虚拟化的参考设计。

在这种情况下，汽车 SDC 系统由仪表盘 (IC) 系统、车载信息娱乐系统 (IVI) 和一个或多个后座娱乐系统 (RSE) 组成。为了整体系统安全，每个系统都作为独立的虚拟机运行。

仪表盘（IC）用于显示与驾驶员相关的车辆驾驶操作信息，如：

车载娱乐 (IVI) 功能包括：

后座娱乐系统 (RSE) 可以操作：

ACRN 管理程序可以支持 Linux* 和 Android* 虚拟机作为用户操作系统 (UOS)，由 ACRN 管理程序管理。开发人员和 OEM 可以在 ACRN 管理程序以及 IC、IVI 和 RSE VM 之上运行他们自己的虚拟机。服务操作系统作为 VM0 运行（在 Xen* 管理程序中称为 Dom0，在 KVM* 管理程序中称为主机操作系统），用户操作系统作为 VM1（也称为 DomU）运行。

注意：Android* 虚拟机支持将在未来版本中发布。

图 1 显示了使用 ACRN 管理程序的示例的框图。

图 1：在 ACRN 管理程序上运行的 SOS 和 UOS

从ACRN hypervisor的架构图中可以看出：

图1中黄色部分是ACRN项目的软件栈。架构框图中列出的部分功能尚未完全实现，欢迎社区参与开发和实现。此外，图中其他模块均来自其他开源项目，仅供参考。

例如，Service OS 和 Guest Linux 来源于 Clear Linux 项目，而未来对 Guest Android 的支持将来自该项目。

有关 ACRN 当前支持的功能列表，请参阅发行说明。

执照

ACRN 虚拟机管理程序和 ACRN 设备模型软件均在 BSD-3-Clause 免费许可下获得许可，该许可允许“在源代码和二进制代码中重新分发和使用，无论是否修改”，并且该许可还声明了完整的版权免责声明和免责声明.

ACRN 设备型号、服务操作系统和用户操作系统

为了使 ACRN hypervisor 代码尽可能精简和高效，用于实现 I/O 设备共享的设备模型代码在 Service OS 中运行，而不是在 ACRN Hypervisor 中运行。共享哪些 I/O 设备及其实现细节在下面的直通部分中进行了描述。

服务操作系统在所有虚拟机中以最高优先级运行，以满足对时间响应要求和系统服务质量 (QoS) 要求较高的用户的要求。具体到 Service OS 中的任务，它们的优先级有高有低。例如，响应用户操作系统请求的回调函数，运行在服务操作系统上的软件（或中介）将继承用户操作系统的优先级。此外，Service OS 中有一些在后台运行的任务也是低优先级的。

在上面的车载系统示例中，用户操作系统是驾驶控制和车载娱乐的中心枢纽。它支持收音机和各种娱乐选项、车内空调和通风控制、车辆导航显示等。它允许第三方设备使用 USB、蓝牙或 WiFi（如 Android Auto* 或 Apple CarPlay*）等连接技术以及许多其他功能与车载系统进行交互。

启动步骤

在图 2 中，我们展示了在基于英特尔架构的 NUC 上使用 UEFI 身份验证启动的步骤。

图 2 ACRN Hypervisor 引导流程

启动顺序执行如下：

1 UEFI验证并启动ACRN hypervisor和Service OS的bootloader；

2 UFEI（或Service OS的引导加载程序）验证并启动Service OS内核；

3 Service OS的内核通过dm-verity验证，加载ACRN Device Model和virtual boot loader；

4 虚拟引导加​​载程序启动客户端的认证启动过程；

ACRN 管理程序架构

ACRN 管理程序是一种可以直接在硬件系统上运行的 1 类管理程序。它是一种混合 VMM 架构，使用在特权级别运行的服务操作系统来管理和协调 I/O 设备的使用。它支持多个用户虚拟机，每个虚拟机都可以运行Linux或Android操作系统作为用户操作系统。

虚拟机中运行的操作系统与其他虚拟机中的系统或应用程序隔离，从而降低了被攻击的潜在可能性，将安全风险降到最低。当然，由于系统运行在虚拟机中，也可能会为其应用程序的运行带来额外的延迟。

图 3 显示了车载系统中 ACRN 管理程序、仪表集群 (IC) VM 和服务 VM 协同工作的架构图。Service OS（SOS）负责管理大部分设备，包括平台设备对虚拟化技术的理解正确的选项是，并提供I/O协调功能。一些 PCIe 设备可以通过 VM 配置传递到用户操作系统。IC 应用程序和 VM 特定应用程序都运行在 SOS 中，例如：ACRN 设备模型和 ACRN VM 管理器。

ACRN hypervisor中还有ACRN virtual machine manager，用来收集User OS的运行信息，控制用户虚拟机的启动、停止和暂停，还可以暂停或恢复某项的执行单个虚拟 CPU。

图 3 ACRN Hypervisor 架构图

ACRN 管理程序使用 Intel 虚拟化技术 (Intel VT)，它以虚拟机扩展模式 (VMX) 的根模式运行，也称为主机模式或 VMM 模式。包括 UOS 和 SOS 在内的所有其他用户虚拟机在 VMX 非 root 模式或访客模式下运行。（以下为简洁起见，我们将继续使用术语 VMM 模式和访客模式）。

VMM 模式下有 4 种特权环模式，但 ACRN 管理程序只运行在环 0 的特权模式下，其余环 1-3 不使用。运行在guest模式的用户系统（包括SOS和UOS）也有自己的4种ring模式（ring 0-3）。用户系统的内核在guest模式下运行在ring 0，而用户的应用system 它以访客模式运行在 ring 3 上（ring 1 和 ring 2 一般不被商业操作系统使用）。

图 4 VMX 简介

如图4所示，VMM模式和guest模式通过VM Exit和VM Entry进行切换。当引导加载程序将控制权传递给 ACRN 管理程序时，处理器尚未处于 VMX 模式。ACRN 管理程序首先需要通过 VMXON 指令启用 VMX 模式。启用 VMX 后，处理器处于 VMM 模式，它可以通过 VM resume 指令（或通过第一个 VM 启动指令）进入 guest 模式，然后可以通过处理器的 VM exit 事件返回 VMM 模式。典型的处理器将有一个 VM 退出以响应某些指令和事件。

在访客模式下，处理器的执行由虚拟机控制结构 (VMCS) 控制。VMCS 包含虚拟机状态（在 VM Entry 上加载并在 VM Exit 上保存）、主机状态（在 VM exit 上加载）以及虚拟机的控制执行。ACRN 管理程序为每个虚拟 CPU 创建一个 VMCS 数据结构，并使用此 VMCS 来控制在访客模式下运行的处理器的行为。

当虚拟机执行敏感指令时，会触发 VMCS 配置中定义的 VM 退出事件。当 VM 退出时，系统的控制权将移交给 ACRN 管理程序。ACRN hypervisor会模拟虚拟机的指令（如果VM退出的原因是指令权限问题），然后恢复虚拟机继续执行下一条指令，或者根据VM的原因进行相关处理退出（比如虚拟机的存储页面需要建立映射关系），然后恢复虚拟机重新执行指令。

请注意，VMM 模式中使用的地址空间与访客模式中使用的地址空间不同。guest模式和VMM模式使用了不同的内存映射表，所以虚拟机无法访问ACRN hypervisor。ACRN 管理程序使用 EPT 来映射虚拟机地址。虚拟机页表将虚拟机的线性地址映射到虚拟机的物理地址。EPT 表将虚拟机的物理地址映射到机器的物理地址或主机物理地址（HPA）。.

ACRN 设备模型架构

由于系统设备可能需要在不同的虚拟机之间共享，因此虚拟机中的应用程序（和操作系统）需要设备仿真才能访问这些共享设备。一般来说，设备仿真有三种架构：

在上面讨论的设备仿真架构中，共享设备是有成本的。因为无论设备模拟是在hypervisor中，还是在每个虚拟机内的用户空间中，都有相应的系统开销。但是，只要系统设备需要被多个虚拟机操作系统共享，这种开销是值得的。相反，如果设备不需要共享，则可以使用更有效的访问设备的方法，例如“直通”。

看完上面的分析，是不是对 ACRN 有了更深入的了解呢？还有更多问题需要紧急回答吗？别着急，我们将在下一期继续讲解各种技术细节，如ACRN设备模块架构、设备透传、ACRN I/O中介、Virtio框架结构等，一一为您展示。

ACRN 的设备模块

在 ACRN 中，每个 User OS（简称 UOS）都需要有一个与之对应的 ACRN 设备模型。ACRN设备模型首先为UOS初始化虚拟硬件平台（包括初始化VCPU状态、分配和初始化内存、初始化UOS启动脚本中指定的虚拟设备）、加载客户平台固件文件或客户操作系统内核文件等.，最后通过调用ACRN hypervisor提供的服务来执行guest指令。

ACRN设备模型是运行在Service OS（简称SOS）上的应用程序，其架构如图5所示。

图 5 ACRN 设备模块

在 ACRN 中，I/O 虚拟化主要依赖于以下三部分的协同工作：

1）设备仿真

2）I/O 请求处理

3）VHM（Virtio 和 Hypervisor 服务模块）。

设备仿真：

设备仿真是指一系列I/O设备仿真例程，用于仿真不同种类的设备，如PCI总线设备、ACPI设备等。这些设备仿真例程注册在ACRN设备模型中，由ACRN 设备模型中的 I/O 调度程序。当UOS产生I/O设备访问请求时，I/O调度器会根据请求的I/O地址、PIO或MMIO进一步调用具体设备的模拟例程。

I/O请求（简称IOREQ）处理：

参考下面的 ACRN-I/O-mediator

录像机：

VHM（Virtio and Hypervisor service Module）模块充当ACRN hypervisor和设备模型之间的桥梁，为设备模型提供必要的服务。VHM 运行在 Service OS 中，以内核模块的形式存在。其具体服务流程如下：

1 ACRN 管理程序通过中断通知 VHM 新 IOREQ 的到来；

2 VHM 首先将IOREQ 标记为“处理中”，并将其发送给VHM 的用户（例如，设备型号、gvt-g、VBS-K 等）进行进一步处理。之后，VHM 可以处理新的 IOREQ；

3 IOREQ的实际处理可以是运行在SOS用户态的ACRN设备模型，也可以是运行在SOS内核态的其他设备模型，如gvt-g、VBS-K等。一旦IOREQ处理完毕，会通知VHM（内核态直接通过函数调用通知，用户态通过IOCTL通知），然后VHM进一步通知ACRN hypervisor，通过IOREQ处理完毕超级调用。

用户态程序：ACRN设备模型；

内核模式模块：VHM、VBS-K、gvt-g等；

设备直通

通常，设备直通旨在提供给定设备的独占使用，以供来宾操作系统独立使用。

图 6 设备直通

设备直通可以实现近乎原生的性能。在多个虚拟机不需要共享同一个设备的情况下，比如系统中有多个物理设备对虚拟化技术的理解正确的选项是，对于一些对 I/O 要求比较高的设备，设备透传是最好的选择，因为 hypervisor（无论是否在管理程序或用户空间中）虚拟设备会导致额外的性能损失。

抛开性能方面的考虑，有些设备天生就不能在多个虚拟共享环境中使用，例如 USB 设备模式下的 xDCI 端口。对于此类设备，ACRN 直接采用设备透传的方式供客户操作系统使用。

设备直通的硬件支持

英特尔当前的处理器架构使用 VT-d 来提供对设备直通的支持。VT-d 将客户端平台的物理地址映射到本地平台机器的物理地址，这样客户操作系统就可以通过访问客户端平台的物理地址来访问本地平台的物理硬件。在这个过程中，VT-d负责设备的访问和保护，而客户平台操作系统只需要像在非虚拟化环境中那样直接访问设备即可。此外，VT-d 可以防止物理设备恶意访问属于其他 VM 或 hypervisor 的内存，从而提高安全性。

此外，在 ACRN 项目中，设备主要使用 MSIx/MSI 中断来代替传统的基于中断引脚的方法来通知客人。这样做的好处是不仅可以处理来自多个VM的多个中断，还可以保证中断源的隔离。

设备直通管理程序支持

较新的 Intel 处理器架构支持 VT-d，因此所有主流 hypervisor（Xen 和 KVM）都可以基于 VT-d 实现设备直通。ACRN还基于VT-d实现了设备透传功能。

ACRN 虚拟 I/O 设备

图 7 显示了访问 ACRN 中的虚拟 I/O 的流程。

图 7 I/O 虚拟进程（端口 IO）

以下是图 7 中编号的项目：

1、当客户操作系统执行一个 I/O 指令（PIO 或 MMIO）时，VM-Exit 发生，ACRN hypervisor 获得对处理器的控制。首先，它将确定虚拟机执行和退出的原因。在我们的例子中，VM-Exit 是由于来宾中的 PIO 访问，退出原因号是 VMX_EXIT_REASON_IO_INSTRUCTION。

2、除了基于 VM-Exit 的原因号之外，ACRN 管理程序还对生成 VM-Exit 的指令进行解码。在我们的例子中，管理程序会注意到 PIO 指令（例如：在 AL 中，20h）。接下来，hypervisor将解码后的相关信息（包括PIO访问、访问字节、读/写模式、目标寄存器等）放入与ACRN VHM和ACRN设备模型共享的物理页面中，然后使用中断的方式通知SOS/VHM 用于进一步处理。

3、SOS 中的VHM 收到中断后，查询IOREQ 的所有信息。

4、VHM 会首先检查 IOREQ 是否应该被内核态的设备模型处理。如果是这样，则相应内核模块之前注册的回调函数将被 VHM 调用。否则，如果没有内核模式设备模型来处理 IOREQ，VHM 会将 IOREQ 保存在共享页面中，并唤醒 ACRN 设备模型来处理 IOREQ。

5、ACRN 设备模型使用与 VHM 相同的机制来处理 IOREQ。设备模型的I/O执行线程会首先查询IOREQ的具体信息，同时检查是否有设备仿真模块实现了IOREQ对应的逻辑。如果有对应的模块，就会调用该模块对应的回调函数。

6、ACRN设备模型完成设备仿真后（本例中是对端口IO 20h的访问，uDev1将结果保存到共享页中（本例中存放在AL寄存器中）。

7、ACRN设备模型完成对应IOREQ的仿真和仿真后，通过VHM API将控制权返回给ACRN hypervisor。

8、ACRN hypervisor得知IOREQ已经处理完毕，将结果保存到VCPU对应的寄存器中。

9、ACRN hypervisor更新VCPU寄存器后，进一步更新IP地址寄存器指向下一条guest指令，重新开始执行guest。

guest中MMIO访问的处理与上例中PIO访问的处理类似，只是VM-Exit的原因不同：MMIO对应的VM-Exit原因码为VMX_EXIT_REASON_EPT_VIOLATION。

Virtio 框架架构

Virtio 是一种通用的面向虚拟设备的抽象，可以在任何管理程序中使用。在 ACRN 参考设计中，我们的 Virtio 实现符合 Virtio 标准规范 0.9 和 1.0。好处是，对于虚拟设备实现，虚拟环境和客户端平台可以重用一组直观、高效、标准和可扩展的机制，而无需针对每个环境或操作系统进行定制。

Virtio提供了一个通用的前后端驱动框架，不仅规范了virtio设备的访问接口，还增加了不同虚拟化平台上的代码复用。

图 8 Virtio 架构

为了更好地理解 Virtio，尤其是它在 ACRN 项目中的使用，这里有几个 Virtio 的关键概念：

Virtio 前端驱动

Virtio采用前后端架构，分别为前端和后端的Virtio驱动提供简单灵活的框架。Virtio 前端驱动框架提供前端 Virtio API 来配置硬件、传递消息、提交请求、通知后端 Virtio 驱动等。因此，Virtio前端驱动易于实现，与设备仿真相比性能大幅提升。

后端 Virtio 驱动程序

与 Virtio 前端驱动程序类似，Virtio 后端驱动程序运行在主机平台上（内核模式或用户模式）。Virtio 后端驱动程序处理来自前端驱动程序的请求，并根据需要将请求进一步转发到本地设备驱动程序。Virtio 后端驱动程序处理完请求后，后端驱动程序会通知前端驱动程序“请求已完成”。

直观：Virtio 设备重用现有设备总线

Virtio 重用了现有的设备总线，而不是创建一种新型的设备总线，好处是 Virtio 的前后端驱动可以直接使用现有的代码进行交互。比如Virtio前端驱动可以直接读写虚拟设备的寄存器（通过Virtio后端驱动虚拟化），虚拟设备（通过Virtio后端驱动虚拟化）可以直接通知前端-end 驱动程序通过中断事件的发生。目前，Virtio标准规范定义了几种总线结果，如PCI/PCIe总线、MMIO总线、CCW总线等。目前ACRN项目只支持PCI/PCIe总线。

高效：鼓励批量操作

批处理操作和延迟通知对于实现高性能 I/O 很重要，因为 Virtio 前端和后端驱动程序之间的通知会导致代价高昂的 VM-Exit 等。因此，应尽可能批量处理数据，同时减少事件的通知。

标准：virtqueue

所有的 Virtio 设备都使用相同的机制，称为 virtqueue，其内部实现是两个标准的环形缓冲区和一个描述符列表，如图 6 所示。 Virtqueue 是一个 scatter-gather 缓冲区队列，主要有以下三种操作模式：

add_buf 在 vi​​rtqueue 中添加请求/响应；

get_buf 在 vi​​rtqueue 中获取响应/请求；

kick 通知对方 virtqueue 已经更新；

virtqueue 由 Virtio 前端驱动程序在客户物理内存中创建。Virtio 后端驱动只需要调用 Virtio API 解析 virtqueue 的结构即可获得请求或响应。virtqueue 的构建方式取决于客户操作系统。在 Linux 中实现 Virtio 时，virtqueue 被实现为称为 vring 的环形缓冲区结构。

在 ACRN 的 Virtio 前端驱动开发过程中，可以直接使用 virtqueue API，用户无需关心 virtqueue 的具体内部细节。有关 virtqueue 实现的更多详细信息，请参阅您正在使用的客户机操作系统。

可扩展：特征位

每个 Virtio 设备与其 Virtio 前端驱动程序之间存在一种简单且可扩展的特性协商机制。每个 Virtio 设备都可以声明其特定于设备的功能，然后 Virtio 前端驱动程序可以表达它理解的硬件功能。此功能协商机制确保驱动程序向前和向后兼容。

在 ACRN 参考实现中，Virtio 前端驱动存在于客户操作系统的内核态空间，而 Virtio 后端驱动有两种可能：用户态和内核态。图 9 显示了 ACRN 用户空间中的 Virtio 后端驱动架构。

图 9 Virtio 框架 – 用户模式程序

在 ACRN virtio 后端驱动框架中，该实现兼容 virtio 标准规范 0.9 和 1.0 版本。VBS-U与设备模型静态链接，通过PCIe/PCI虚拟设备接口（PIO/MMIO或MSI/MSIx）与设备模型通信。VBS-U 使用用户态 virtqueue API 来访问由 Virtio 前端驱动程序放置在共享内存中的数据。SOS 对 UOS 物理内存的访问是基于 ACRN 管理程序的帮助。

图 10 Virtio 框架 – 内核模式程序

从性能上看，为了支持一些对性能要求较高的设备，可以将数据平面的处理从用户态移到内核态，避免Virtio后端驱动在用户切换时产生额外的数据模式和内核模式。处理；而控制平面（control plane）的处理，仍然留在用户空间，即VBS-U。VBS-U 需要选择在合适的时间初始化 VBS-K，比如 Virtio 前端驱动设置 VIRTIO_CONFIG_S_DRIVER_OK 的时候是一个好时机。在内核模式下运行的 Virtio 后端驱动程序可以使用 VBS-K virtqueue API 前端驱动程序来共享数据。VBS-K virtqueue API 的设计与 VBS-U virqueue API 非常相似，以便于使用。此外，VBS-K 依赖于 VHM，它负责将 IOREQ 分发到 VBS-K 模块。每个 VBS-K 需要处理一种或多种类型的 IOREQ 请求，具体取决于特定 VBS-K 需要监视的连续寄存器空间的数量。最后，VBS-K 使用 VHM API 以中断的方式通知 Virtio 前端驱动程序。

看到这里，开发者是不是有兴趣动手实践呢？如果您在项目设计中遇到有关 ACRN 的技术问题，请访问 ACRN 社区进行讨论，社区地址：

.