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

ACRN 到底具有哪些强大的功能，它又是怎么实现的？今天我们就从架构到应用对 ACRN 进行详细分析，让开发者们快速上手使用ACRN进行产品设计。

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

ACRN hypervisor 是一个 Type-I 的 hypervisor，可以直接运行在物理硬件上，适用于各种物联网和嵌入式设备解决方案。ACRN hypervisor 解决了当前数据中心 hypervisor 和 partitioning hypervisor 之间存在的差距。ACRN hypervisor 设计时把系统分为不同的功能域，并为物联网和嵌入式设备精心挑选的用户操作系统进行共享优化。

汽车应用案例

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

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

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

• 汽车的速度、燃油、行驶里程和其它驾驶信息；
• 投影在挡风玻璃上的抬头显示，用以警告缺油或胎压报警；
• 显示后视摄像头影像和车身的周边摄像头信息，用于辅助停车；

车载娱乐系统（IVI）的功能包括：

• 导航系统、收音机和其它娱乐系统；
• 连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；
• 通过手势识别或触控进行交互；

后座娱乐系统（RSE）可以运行：

• 娱乐系统；
• 虚拟办公；
• 连接到前排座椅的IVI系统和移动设备（云连接）；
• 连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；
• 通过手势识别或触控进行交互；

ACRN hypervisor 可以支持 Linux 和 Android 虚拟机作为用户操作系统（UOS），UOS 由 ACRN hypervisor 进行管理。开发者和 OEM 厂商可以在 ACRN hypervisor 之上运行自己的虚拟机，以及 IC、IVI 和 RSE VM。Service OS 是作为 VM0 运行（在Xen hypervisor 中被称为 Dom0，在 KVM hypervisor 中被称为 Host OS），User OS 用户操作系统作为 VM1 运行（也被称为 DomU）。

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

图 1 显示了一个使用 ACRN hypervisor 的实例框图。

图 1：SOS 和 UOS 运行在 ACRN hypervisor 之上

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

• ACRN hypervisor 直接位于 bootloader 之上，因而具备快速启动的能力；
• 部分资源进行 partitioning，以确保安全关键性应用和非安全关键业务可以共存在同一平台上；
• 丰富的 I/O 设备虚拟化提供在多个 VM 之间的 I/O 设备共享，从而提供全面的用户体验；
• 通过高效的虚拟化，一个 SoC 可以支持多个操作系统同时运行；

图 1 中的黄色部分是 ACRN 项目的软件栈。该架构框图中列出的某些功能还没有完全实现，欢迎社区共同参与开发实现。另外，图中的其他模块来自于别的开源项目，这里仅供参考。

例如，Service OS 和 Guest Linux 来源于 https://clearlinux.org 上的 Clear Linux 项目，而未来 Guest Android 的支持将会来自 https://01.org/android-ia 项目。

当前ACRN所支持的功能列表，请参照发布说明。

许可证

ACRN hypervisor和ACRN Device Model软件采用的都是自由许可证的BSD-3-Clause，它允许以“源代码和二进制再次发布和使用，无论是否进行了修改”， 许可证中也注明了完整版权声明和免责声明。

ACRN Device Model，Service OS 和 User OS

为了使 ACRN hypervisor 代码尽可能精悍且高效，用于实现 I/O 设备共享的 device model 代码运行在 Service OS 中而非 ACRN Hypervisor。哪些 I/O 设备被共享以及其实现细节将在下面的 pass-through 章节具体介绍。

Service OS 在所有虚拟机里，以最高优先权运行，以满足那些对时间响应要求很高的需求和系统服务质量的需求（QoS）。具体到 Service OS 中的任务（task），他们的优先级则有高有低。例如响应 User OS 请求的回调函数，其运行在 Service OS 的软件（或者 mediator）就会继承 User OS 的优先级。另外，在 Service OS 中还有一些在后台运行的任务也是低优先级。

在上述的车载系统示例中，User OS 是驾驶控制和车内娱乐的中心枢纽。它能提供收音机和各种娱乐选项、车内空调和通风控制、车辆导航显示等支持。它可以让第三方设备使用 USB、蓝牙或者 WiFi 等连接技术与车载系统进行交互，例如：Android Auto 或者 Apple CarPlay, 还能提供许多其它功能。

启动步骤

在图 2 中，我们展示了在一个采用英特尔架构平台的NUC上使用UEFI验证启动的步骤。

图 2： ACRN Hypervisor 启动步骤

启动引导顺序执行如下：

1. UEFI 验证和启动 ACRN hypervisor 和 Service OS 的引导加载程序；
2. UFEI（或 Service OS 的引导加载程序）验证并启动 Service OS 内核；
3. Service OS 的内核通过 dm-verity 验证并且加载 ACRN Device Model 和虚拟引导加载程序；
4. 虚拟引导加载程序启动用户端的验证启动进程；

ACRN Hypervisor 架构

ACRN hypervisor 是 Type 1 的虚拟机管理程序，能够直接运行在硬件系统上。它是一个混合的 VMM 架构，采用一个运行在特权级的 Service OS 来管理和协调 I/O 设备的使用。它能支持多个用户虚拟机，其中每个虚拟机都可以运行 Linux 或者安卓操作系统作为用户操作系统。

在虚拟机内运行的操作系统是与其它虚拟机内的系统或应用程序相互隔离的，从而缩小了潜在的被攻击可能性，最大限度地减小安全隐患。当然由于系统运行在虚拟机内也可能会给其应用程序的运行带来额外的延迟。 

图3显示了 ACRN hypervisor、车载系统中的 Instrumental Cluster (IC) VM 和 Service VM 一起协同工作的架构图。Service OS（SOS）负责包括平台设备在内的大部分设备的管理，并提供 I/O 的协调功能。某些PCIe设备可以通过VM配置直通给 User OS 使用。IC 应用程序和虚拟机特定的应用程序都运行在 SOS 中，例如：ACRN device model 和 ACRN VM 管理器。

ACRN hypervisor 内还有 ACRN 虚机管理器，用来收集 User OS 的运行信息，并控制用户虚拟机的开始、停止和暂停，还能暂停或者恢复执行单个虚拟 CPU。

图 3： ACRN Hypervisor 架构图 

ACRN hypervisor 采用了英特尔虚拟化技术（Intel VT），其运行在虚拟机扩展模式（VMX）的 root 模式下，也称为主机模式或 VMM 模式。其他所有的用户虚拟机包括 UOS 和 SOS 都运行在 VMX non-root 模式或 guest 模式下。（以下为了简略，我们将继续使用术语 VMM 模式和 guest 模式）。

VMM 模式下有 4 种权限的 ring 模式，但 ACRN hypervisor 仅在 ring 0 的特权模式下运行，其余 ring 1-3 并未使用。运行在 guest 模式下的用户系统（包括 SOS 和 UOS）也有自己的 4 个 ring 模式（ring 0-3）。用户系统的内核运行在 guest 模式下的 ring 0，而用户系统的应用程序则在 guest 模式下运行于 ring 3（ring 1 和 ring 2 一般不被商业操作系统所使用）。

图 4： VMX 简介

如图 4 所示，VMM 模式和 guest 模式通过 VM Exit 和 VM Entry 进行切换。当引导加载程序将控制权交给 ACRN hypervisor 时，处理器还未启动 VMX 模式。ACRN hypervisor 首先需要通过 VMXON 指令启用 VMX 模式。启用 VMX 后，处理器处于 VMM 模式，它可以通过 VM resume 指令进入 guest 模式(或者通过第一次 VM launch 指令)，然后可以通过处理器的 VM exit 事件回到 VMM 模式。一般处理器会在响应某些指令和事件时发生 VM exit。

在 guest 模式下，处理器的执行是由一个虚拟机控制结构（VMCS）所控制的。VMCS 包含了虚机状态（在 VM Entry 时加载并在 VM Exit 时保存），主机状态（在 VM exit 时加载），以及虚机的控制执行。ACRN hypervisor 为每个虚拟 CPU 创建了一个 VMCS 数据结构，并使用该 VMCS 来控制运行在 guest 模式下处理器的行为。 

当虚机执行到一个敏感指令时，就会触发一次定义在 VMCS 配置中的 VM exit 事件。当 VM exit 发生后，系统的控制权就交给了 ACRN hypervisor。ACRN hypervisor 会模拟虚机的指令（如果 VM exit 的原因是由于指令权限问题），然后恢复虚机继续执行它的下一条指令，或者根据 VM exit 的原因进行相关处理（例如，一个虚机的存储页面需要建立映射关系），然后恢复虚机重新执行该条指令。

需要注意的是用于VMM模式的地址空间和用于 guest 模式的地址空间是不同的。guest 模式和 VMM 模式下使用不同的内存映射表，因此虚机是无法访问 ACRN hypervisor 的。ACRN hypervisor 使用 EPT 来映射虚机地址，虚机页表会将虚机的线性地址映射到虚机的物理地址， EPT 表则将虚机的物理地址映射到机器物理地址或主机物理地址（HPA）。 

ACRN 设备模式架构

因为系统设备可能需要在不同的虚机之间被共享，虚机内应用程序（和操作系统）要对这些共享设备进行访问就需要借助设备模拟。一般来说，设备模拟有三种架构： 

• 第一种架构被称为 hypervisor中 的设备模拟，这是在 VMware 工作站产品（一个基于操作系统的 hypervisor）中实现的设备模拟方式。在这种方式中，hypervisor 负责模拟需要在各个虚机操作系统之间共享的常见设备，其中包括：虚拟磁盘、虚拟网络适配器和其它必要的平台资源。
• 第二种架构称为用户空间的设备模拟。顾名思义，不是将设备模拟的实现嵌入到 hypervisor 中，而是将其放在一个用户空间的应用程序中实现。比如被各种独立的 hypervisor 所使用的 QEMU 就提供了此类的设备模拟方式。这种架构的优势在于设备模拟的实现不依赖于 hypervisor，所以其它 hypervisor 可以重用改实现。甚至它还可以做任意设备的模拟，而不必担心其功能的实现会影响 hypervisor（其在特权模式下运行）。
• 第三种架构则是从基于 hypervisor 的设备模拟改变而来的半虚拟化驱动程序。该架构一开始是在XEN项目中引入的，其中 hypervisor 提供物理设备驱动，每个虚机操作系统则需要安装一个与能与物理驱动配合使用的 hypervisor 感知的驱动程序。

在以上讨论的设备模拟架构中，共享设备都需要付出代价。因为不管设备模拟是在 hypervisor 中，还是在每个虚机内的用户空间中，都存在相应的系统开销。不过只要系统设备需要被多个虚机操作系统共享，这种开销就是值得的。反之如果设备不需要被共享，那么就可以使用更有效的方法来访问设备，例如使用“直通”。

看完以上的分析，你是否对 ACRN 有了更深入的了解？也是否有更多问题急需解答？ 不用着急，我们将在下期中继续讲解各种技术细节，例如 ACRN 设备模块架构、设备 pass through， ACRN I/O mediator，Virtio 框架结构等一一为你展示。

ACRN 的设备模块

在 ACRN 中，每个 User OS（简称 UOS）都需要有一个 ACRN 设备模型与之对应。ACRN 设备模型首先为 UOS 初始化虚拟硬件平台（包括初始化 VCPU 状态、分配并初始化内存、初始化 UOS 启动脚本中所指定的虚拟设备）、加载 guest 平台固件文件或 guest 操作系统内核文件等，并最终通过调用 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

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

1. ACRN hypervisor 通过中断的方式通知 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 通过 hypercall 的方式，进一步通知 ACRN hypervisor 该 IOREQ 已经处理完成。

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

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

设备直通

总体上讲，设备直通是为了将指定设备排他性提供给某个客户操作系统独立使用。

图 6： 设备直通

通过设备直通可以实现几乎原生的性能。在不需要在多个虚拟机中共享同一个设备的情况下，如系统中有多块物理设备，设备直通对于某些高 I/O 需求的设备来说是最佳选择，因为通过 hypervisor（无论是在 hypervisor 中还是在用户空间中）虚拟设备会产生额外的性能下降。

除了性能角度考量外，有些设备先天不能被用在多个虚拟共享环境中，如 USB device 模式的 xDCI 端口。对于这类设备，ACRN 中则直接采用设备直通的方式供客户操作系统使用。

设备直通的硬件支持

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

此外，在 ACRN 项目中，设备主要使用 MSIx/MSI 中断，而不是传统的基于中断 pin 的方式通知 guest。从而带来的好处在于不仅能够很好地处理来自于多个 VM 多个中断的情况，而且能够保证中断源的隔离。

设备直通的 hypervisor 支持

较新的英特尔处理器架构均支持 VT-d，因此各主流 hypervisor（Xen 和 KVM）均可以基于 VT-d 实现设备直通的功能。ACRN 同样基于 VT-d 实现设备直通的功能。

ACRN 虚拟 I/O 设备

图 7 展示了ACRN 中访问一个虚拟 I/O 所经历的流程。

图 7 I/O 虚拟流程（Port IO） 

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

1. 当 guest 操作系统执行 I/O 指令（PIO 或 MMIO）时，VM-Exit 发生，ACRN hypervisor 获得处理器控制权，首先会判断虚拟机执行退出的原因。在我们的例子中，VM-Exit 是因为 guest 中发生了 PIO 访问，退出原因的号码为VMX_EXIT_REASON_IO_INSTRUCTION。
2. 除了根据 VM-Exit 的原因号码，ACRN hypervisor 还会对产生 VM-Exit 的指令进行译码。在我们的例子中，hypervisor会注意到是 PIO 指令（例如：in AL, 20h）。接下来，hypervisor 将译码得到的相关信息（包括 PIO 访问、访问字节数、读/写方式、目标寄存器等）放到与 ACRN VHM、ACRN 设备模型共享的物理页面之中，然后以中断的方式通知 SOS/VHM 去做进一步处理。
3. SOS 中的 VHM 接收到中断后，查询该 IOREQ 有关的所有信息。
4. VHM 首先会检查是否应该由内核态的设备模型来处理该 IOREQ，如果是，那么相应的内核模块之前注册的callback函数会被 VHM 调用。否则，如果没有内核态设备模型来处理 IOREQ，那么 VHM 则会将该 IOREQ 保留在共享页面中，并唤醒 ACRN 设备模型对该 IOREQ 进行处理。
5. ACRN 设备模型采用与 VHM 相同的机制对 IOREQ 进行处理。设备模型的 I/O 执行线程会首先查询 IOREQ 具体的信息，同时检查是否有设备仿真模块实现了该 IOREQ 对应的逻辑。如果有相应的模块，那么该模块对应的 callback 函数将会被调用。
6. ACRN 设备模型完成设备模拟仿真后（本示例中是对端口 IO 20h 的访问），uDev1 将结果保存到共享页面（示例中保存在 AL 寄存器）。
7. 完成相应 IOREQ 的模拟和仿真后，ACRN 设备模型通过 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 是一种通用的面向虚拟设备的抽象，可以应用在任何 hypervisor 中。在 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 后端驱动程序虚拟）可以直接以中断的方式通知前端驱动程序事件的发生。目前，Virtio 标准规范定义了几种总线结果，如PCI/PCIe 总线、MMIO 总线、CCW 总线等。目前 ACRN 项目只支持 PCI/PCIe 总线。

高效：鼓励批处理操作

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

标准：virtqueue

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

• add_buf 在 virtqueue 中添加请求/响应；
• get_buf 在 virtqueue 中获得响应/请求；
• kick 通知对方 virtqueue 已经被更新；

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

在 ACRN 的 Virtio 前端驱动程序开发过程中，virtqueue API 可被直接利用，从而用户无需关心 virtqueue 的具体内部细节。关于 virtqueue 实现的更多细节，请参考您所使用的 guest 操作系统。

可扩展：特征 bit

每个 Virtio 设备和其 Virtio 前端驱动程序之间都存在一个简单可扩展的特征协商（feature negotiation）机制。每个Virtio设备都可以声明其设备特定的功能，而相应地 Virtio 前端驱动程序可以表示自己能够理解哪些硬件特征。这种特征协商的机制能够保证驱动程序向前和向后兼容。 

在 ACRN 参考实现中，Virtio 前端驱动程序存在于 guest 操作系统的内核态空间，而 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 hypervisor 的帮助。

图 10: Virtio 框架- 内核态程序

从性能角度出发，为了支持一些性能要求较高的设备，数据平面（data plane）的处理可以从用户态挪到内核态，从而避免 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，即 VHM 负责分发 IOREQ 给 VBS-K 模块。每个 VBS-K 需要处理一类或者多类 IOREQ 请求，具体多少取决于特定的VBS-K需要监听多少段连续的寄存器空间。最后，VBS-K 借助于 VHM 的 API 来通过中断的方式通知 Virtio 前端驱动程序。

看到这里，开发者们是不是有兴趣亲自动手实践了，如果您在项目设计中遇到关于ACRN的技术问题，欢迎访问ACRN社区进行讨论，社区地址：https://projectacrn.github.io/latest/index.html