UVirtio：为RISC-V工业边缘设备实现无处不在的资源共享

《ACM Transactions on Architecture and Code Optimization》：UVirtio: Enabling Ubiquitous Resource Sharing for RISC-V Industrial Edge Devices

　　**AbstractAI 摘要**
要查看此由 AI 生成的摘要，您必须拥有高级访问权限。了解更多信息请登录。

**摘要**
物联网设备的普及要求在动态的工业边缘场景中部署无处不在的操作系统（UOS），这些场景面临实时需求和资源碎片化的挑战。现有的虚拟化方法往往对于这些环境来说过于庞大或不够灵活。在本文中，我们介绍了 UVirtio，这是一种轻量级的无处不在的虚拟化机制，能够实现分布式边缘设备之间的高效资源共享。UVirtio 引入了一种基于设备配置文件的虚拟硬件抽象层，将性能开销降至最低。该系统促进了边缘设备之间的协作和数据聚合，使传感器数据的吞吐量提高了 37.6% 并支持在共享的 AI 加速器上执行复杂任务（如面部识别）。此外，UVirtio 实现了一种基于差异打包的实时迁移机制，使得动态资源重新分配的停机时间小于 40 毫秒，从而为无处不在的计算领域提供了一种可扩展且敏捷的虚拟化解决方案。我们的工作是开源的，具体地址为：https://github.com/muliangshou/UVirtio/tree/main。

**AI 生成的摘要（实验性）**
此摘要是使用自动化工具生成的，并非由文章作者编写或审阅。它旨在帮助读者发现信息、评估相关性，并协助来自相关研究领域的读者理解本文内容。它是对作者提供的摘要的补充，而作者提供的摘要仍然是本文的官方摘要。完整文章才是权威版本。点击此处了解更多信息。点击此处对摘要的准确性、清晰度和实用性发表评论。您的反馈将有助于改进未来生成的摘要版本。要查看此由 AI 生成的通俗语言摘要，您必须拥有高级访问权限。

**1 引言**
随着计算边界的不断扩展，计算场景不再局限于传统领域，而是深入融入了更广阔的物理世界。根据全球综合数据库 Statista 的数据，到 2019 年，物联网（IoT）设备的数量已经超过了非物联网设备；预计到 2033 年，物联网设备的数量将超过 400 亿台 [59]。新型的无处不在的操作系统（UOS）[5, 9, 43] 正成为边缘系统软件创新和生态系统建设的新前沿。如图 1 所示，在典型的智能工厂场景中，多个边缘终端通过摄像头和 I2C/GPIO 外设执行基础任务，例如自动读取压力表、流量计和电表的读数 [22, 72]，检测缺陷（包括划痕、气泡、边缘裂纹和焊接缺陷 [11, 48]，以及进行操作员身份验证 [19, 20]（例如面部识别）。

**图 1. 具有嵌入式边缘节点的典型无处不在的工业应用**
尽管边缘节点在现代工厂中无处不在，但在资源管理方面却面临困境。一方面，现代的高精度深度学习网络的计算能力往往超过了单个边缘单元的独立计算能力。例如，典型的超低功耗边缘 AI 视觉芯片 Kendryte K210 [55] 只能运行最简单的（“纳米级”）模型 [64]，精度较低且需要大量量化处理。另一方面，尽管有大量的物联网设备存在，但它们的资源仍然是分散的。大多数工业环境需要实时的本地响应 [5, 21, 42, 65]，一些设备在去中心化的私有云外网络环境中运行 [66, 70]，以确保低延迟和数据合规性。摄像头、传感器和加速器分布在多个独立的设备上，形成了隔离的“数据孤岛”，阻碍了资源的协作和协同处理。云边缘解决方案 [16, 33, 39, 71] 受限于网络往返延迟、带宽和覆盖范围。考虑到车间环境的严苛条件，迁移是动态工业边缘环境中的关键功能，正如先前关于移动性感知边缘计算的研究 [8, 36] 所强调的那样。

当前的虚拟化和协调框架并不适合这种极端环境。传统的嵌入式虚拟化技术（如 RT-Xen 和 KVM-embedded [67, 73]）由于引入了完整的虚拟机监控程序 [46]，导致了显著的内存和 CPU 开销。虽然像 Bao 或 XVisor [42, 50] 这样的静态分区虚拟机监控程序提供了强大的隔离性和实时性保证，但它们缺乏在节点之间共享或聚合计算能力的灵活性。许多研究探索了基于容器的轻量级虚拟化解决方案 [4, 47, 69, 70]，以支持边缘处的实时迁移。然而，基于容器的迁移依赖于检查点与重启（C/R）机制 [69]，这通常需要在地址空间粒度上将进程转存为图像文件，从而带来额外的内存压力和序列化开销，可能导致过长的停机时间。

为了解决这些问题，我们提出了 UVirtio，这是一种无处不在的资源共享机制，它在以下三个方面推进了当前的研究：
1. UVirtio 使用基于 ACRN 虚拟机监控程序 [34] 的接口统一虚拟硬件抽象层（vHAL）的新型设备配置文件抽象扩展；
2. 提供基于原生 UOS [9] 的轻量级虚拟化；
3. 对神经计算芯片、气压传感器和伺服电机的虚拟化实现了最小的开销；
4. 在设备级引入了协作方案，显著提高了传感器物理测量的吞吐量，并通过两个开发板的聚合实现了面部识别的实际应用；
5. 此外，UVirtio 还提出了一种名为 InterConnect 的细粒度迁移机制，该机制在设备驱动程序层面实现实时迁移，停机时间小于 40 毫秒。UVirtio 作为 XiUOS 生态系统中的子系统实现，而 XiUOS 是运行在我们物理 RISC-V 节点上的基础操作系统，负责低级硬件初始化、本地线程调度和基本硬件驱动程序管理。RISC-V 在低成本工业边缘设备中的采用及其开放的 ISA 生态系统激励我们针对 RISC-V 微控制器的架构定制了注册、运行时 MMIO 拦截和虚拟化功能，尽管 UVirtio 的概念软件抽象也适用于其他资源受限的 MCU 系列。总之，UVirtio 的主要贡献包括：
- 我们在 XiUOS [9] 上利用类型 I 虚拟化，通过灵活的设备配置文件模型映射各种硬件设备，同时保持与原生设备驱动程序以及官方 RT-Thread 端口驱动程序相近的封装性和延迟性能；
- 我们建立了跨端点设备协作和聚合方案，将分散的硬件资源池化，使传感器测量应用程序的吞吐量至少提高了 37.6%，并支持卷积神经网络（CNN）的计算；
- 我们提出了一种实时迁移机制，实现了低停机时间（<40 毫秒）的动态设备迁移。

我们的工作是开源的，具体地址为：https://github.com/muliangshou/UVirtio/tree/main。

**2 背景与动机**
在本节中，我们将介绍我们研究的背景和动机。首先探讨了无处不在的计算操作系统的基本概念，然后研究了嵌入式环境中的虚拟化技术。我们强调了动态资源管理的现有挑战以及当前研究领域的空白，从而为我们的解决方案 UVirtio 建立了必要性。

**2.1 工业无处不在的场景**
无处不在的计算 [15, 54] 代表了广泛的分布式边缘计算场景的概括，如嵌入式系统 [18, 29, 44]、工业物联网（IIoT）[7, 9, 21, 49] 和无处不在的制造 [1, 10, 11, 22, 51, 71, 72]。工业环境的特点是高度确定的实时性保障。例如，在聚乙烯泡沫生产中，泡沫片边缘缺陷检测的周期时间限制在 <200 毫秒 [68]，这一时间阈值被认为是实时误差校正的关键限制。与此同时，工业边缘的计算通常在资源有限的低功耗硬件平台上进行 [20]。代表性的芯片是 Kendryte K210 AI 视觉芯片，其计算能力不到 1 TOPS (INT8) [55]，SRAM 容量为 8 MiB，成本约为 5 到 10 美元 [14]。文献 [62] 报告称，只有当神经网络参数的大小保持在 5.9 MiB 以下时，K210 才能实现有意义的图形处理。这意味着独立的边缘节点只能支持最小的 YOLOv8n-NANO 模型，精度约为 35% (mAP@50) [64]。缺乏标准化 [56] 通过导致各种 ISA 的专用硬件和碎片化的配置，加剧了资源稀缺问题。通过高效资源池化 [3] 来协调这些差异变得越来越必要。

**2.2 无处不在环境中的虚拟化**
虚拟化的核心在于使用虚拟机监控程序（VMM）来虚拟化物理硬件的能力。基础解决方案（如 Xen 和 KVM）已被移植到无处不在的场景中，但效果参差不齐 [67, 73]。这些移植并不是为无处不在的计算场景专门设计的，在开销 [18, 26, 28, 37, 44] 和系统兼容性 [13, 28, 40, 41, 57] 方面仍有很大改进空间。基于容器的解决方案在边缘场景中得到了广泛探索 [4, 47, 69, 70]，但需要注意的是，目前还没有关于容器服务质量（QoS）指标的统一定义 [47]。当时间限制可以灵活调整时，这些解决方案对于大多数应用是可行的 [6]。然而，设备直通 [38] 是容器聚合的一个主要障碍。我们在 UVirtio 中通过实现设备配置文件编排层并仅在聚合和迁移期间同步必要的 Virtqueue 描述符来规避这一问题。为实时物联网应用量身定制的操作系统更加轻量级。RT-Thread [53] 和 NuttX [5] 实现了最小化的内核大小（仅几 KB），并支持本地确定性执行。然而，作为交换，它们采用了扁平的内存模型，这意味着任务被静态地绑定到硬件的特定物理地址上。Unikernels [41, 45]（如 Jitsu [40]）在启动延迟方面表现出色，但代价是地址空间管理和设备模型非常有限。静态链接和最小化设备模型的设计理念限制了资源的高效池化。嵌入式软件和虚拟化的结合催生了专为嵌入式和物联网场景设计的新类型 I VMM。XVisor [50] 将所有设备驱动程序作为一个软件层实现，具有直接访问硬件的最大系统权限和仿真能力。Hermes [32] 以统一的中断处理层形式抽象了硬件资源管理，可以比面向工作站的虚拟机监控程序实现更高效的资源利用，并保持强大的功能隔离性。然而，这两种虚拟机监控程序都采用单体设计，仅支持有限的硬件类型。ACRN [34] 不同于单体解决方案，它将设备资源管理卸载到用户空间，提供了一种灵活、轻量级且可扩展的嵌入式虚拟化解决方案，同时确保了一定的安全性和实时性能。Jailhouse [52] 和 Bao [42] 使用的静态分区策略是一种值得注意的替代方案。尽管静态分区提供了强大的隔离性和实时性保证，但它不可避免地牺牲了资源利用率和灵活性。UVirtio 采用了模块化设计，确保了在不同应用场景中的通用性，并将单一硬件平台的资源抽象扩展为可扩展的虚拟化和动态迁移机制。

**2.3 UOS 中的资源管理**
无处不在的计算要求在各种场景中管理资源。物联网 [23]、游戏 [58] 和分析 [39] 类的应用程序需要最小的延迟，许多研究探索了使用预复制 [61]、后复制 [25] 或混合方案进行云边缘迁移的可能性 [24, 31, 69]。最先进的云边缘解决方案 [2, 17, 27] 通常在虚拟机和容器层面运行。例如，H-Container [69] 利用静态二进制翻译和 CRIU 等技术，在不同 ISA 的边缘节点之间实现容器迁移，停机时间少于 100 毫秒。AVEC [30] 将 GPU 虚拟化，将边缘工作负载卸载到云端，并设计了一种 API 拦截中间件，实现无状态的容器迁移，耗时不到 5 秒。这些研究要么利用了中间件的功能，要么采用了粗粒度的虚拟化/容器迁移技术。这对于云边缘协作是合适的，因为云拥有更多的计算能力来支持高级框架，而更细粒度的迁移带来的性能优势被网络通信开销所抵消。然而，无处不在的设备通常必须满足严格的实时需求，并且需要不断确保边缘节点与客户端保持物理接近，这在边缘设备之间需要资源管理。UVirtio 是对云边资源管理解决方案的补充，旨在填补设备驱动程序级别轻量级、细粒度的边缘负载均衡和迁移方法的研究空白。我们还将从预复制 [61] 和后复制 [25] 优化中汲取灵感，设计队列清空和只读预迁移机制，以确保迁移带来的停机时间最小。图 2. UVirtio 框架的架构概述。

3 设计
我们介绍了 UVirtio 的设计，这是一种用于嵌入式设备的通用资源共享机制。总体架构的描述可以在图 2 中找到。UVirtio 主要由三个部分组成：
- 在图 2 的? 中，我们基于 Virtio 接口构建了一个基于设备配置文件的 vHAL，它由多个提供基本操作的虚拟设备驱动程序组成。
- 在 ? 中，我们设计了一个 InterConnect 模块，该模块通过从 vHAL 分类设备配置文件的能力来重新路由本地和远程设备终端（或基于云的端点）之间的 I/O 请求，从而实现动态资源管理。
- 在? 中，我们在设备驱动程序级别实现了跨终端设备实时迁移。vHAL 提供的设备配置、I/O 请求和设备状态被打包、序列化并通过 InterConnect 模块发送到远程设备。

接下来，我们将详细介绍每个部分的关键组件，并描述它们如何在图 2 中协同工作。vHAL 的核心是设备驱动程序的内部实现，该实现遵循 Virtio 标准，并将驱动程序分为前端和后端组件，如第 3.1 节所描述。两者之间的数据传输通过共享内存空间中的 Virtqueues 实现，而设备驱动程序的配置则通过 Virtio-MMIO 映射的寄存器内存地址空间进行管理。Virtio 后端统一了各种硬件表示，如 GPIO 和 I2C（第 3.1.1 节）、UART 串行（第 3.1.2 节）以及内核处理单元（KPU）（第 3.1.3 节）。

为了实现动态资源池化并支持设备间的聚合和协作，本文在第 3.2 节设计了一个名为 InterConnect 的动态资源管理模块。该模块在第 3.2.1 节建立了一个设备协调机制，通过“影子设备”（远程设备驱动程序的本地代理）来促进远程操作和重定向。（反）序列化模块和通信模块确保了通过以太网以及 LwIP 协议栈的可靠传输。第 3.2.2 节的任务聚合基于这三个模块，通过扩展本地影子设备以对应一个或多个远程设备来实现灵活的任务分配。第 3.2.3 节讨论了设备配置文件协商和动态后端切换（例如，在任务目标端 KPU 不可用时）。InterConnect 还包括一个迁移管理器，结合第 3.3 节中的优化，实现了低停机时间的无缝迁移。第 3.3 节进一步优化了边缘端的实时迁移，通过差分打包、队列清空和只读预迁移优化。UVirtio 选择性地打包关键信息而不是迁移整个运行时环境和内存状态，从而提高了迁移过程的效率。第 3.4 节进一步讨论了安全性考虑。

3.1.1 GPIO 和 I2C
为了提高 GPIO 设备管理的灵活性并改善系统资源利用率，本文引入了一种类似 ACRN [34] 的虚拟 GPIO 引脚映射机制。UVirtio 提供了五种 I/O 操作接口：打开、关闭、写入、读取和 ioctl。其中，打开和关闭主要用于创建和销毁 Virtqueues，而写入、读取和 ioctl 用于实现基本的 GPIO 操作。虚拟设备上的应用程序级 I/O 操作被封装成 Virtio 请求，这些请求包含三个字段：pin、val 和 cmd。遵循 Virtio 标准，UVirtio 将 Virtio-I2C 设备驱动程序的前端和后端之间的数据传输组织成一种称为描述符链的特定格式。

3.1.2 UART 串行
ENABLE_VIRTIO_SERIAL 配置也可以在内核编译期间设置。与其他设备驱动程序不同，UVirtio 设計了两个独立的 Virtqueues 来处理串行端口设备的数据传输和接收请求：TX Virtqueue 和 RX Virtqueue。TX Virtqueue 与其他设备中的 Virtqueues 类似。由于串行端口接收的特性，RX Virtqueue 有一个独特的工作流程。与传输不同，接收不是由应用层发起的，而是当接收到外部输入时由硬件中断触发。因此，在打开串行设备驱动程序时，除了初始化 RX Virtqueue 之外，还会预先分配一个空白内存缓冲区，并用指向该缓冲区的虚拟读取请求填充 RX Virtqueue。后端还将回调函数绑定到串行端口中断。当发生串行输入中断时，串行后端直接检索一个可用的描述符（即虚拟读取请求），用接收到的数据填充预先分配的缓冲区，并将描述符放入已使用的描述符环中。当应用程序调用读取接口时，前端驱动程序会轮询 Virtqueue 直到检索到实际输入数据。在将数据返回给应用层后，它会将虚拟读取请求重新放入可用的描述符环中，以准备后续的输入。这种设计确保了与操作系统串行端口驱动程序的行为一致。

3.1.3 内核处理单元（KPU）
本研究中使用的硬件配备了 Kendryte K210 芯片，该芯片集成了一颗 KPU 加速器，适用于简单和小型 CNN 计算任务，提供高达 1 TFOPS（每秒太浮点运算次数）的计算性能。KPU 接口不提供读写功能，所有操作都通过 ioctl 实现。

3.2 通用资源的动态池化
我们在设备驱动程序级别设计了一种轻量级的边缘设备协作和资源聚合机制，称为 InterConnect 模块。InterConnect 的主要组件包括：
- 设备协调器：建立影子设备机制，将远程硬件资源抽象为本地设备，实现远程资源集成和无缝交互。
- （反）序列化模块：负责 InterConnect 过程中的数据序列化，并解决网络通信与复杂数据结构之间的兼容性问题。
- 通信模块：处理数据包的发送和接收。这些模块支持以太网连接以及 LwIP 协议栈。
- 迁移管理器：支持虚拟设备驱动程序的动态、轻量级迁移。其功能将在第 3.3 节的各种实时迁移优化中进一步讨论。

3.2.1 跨端点设备协作
基于 vHAL 层和 InterConnect 模块，UVirtio 实现了跨端点设备协作。图 3 描述了基于 InterConnect 模块的远程控制重定向的典型工作流程。

3.2.2 跨端点资源聚合
资源聚合涉及多个终端硬件设备的网络连接，将来自多个设备的碎片化物理资源整合为池化资源。在图 4 中，我们首先在 InterConnect 模块中注册远程设备及其基本信息。由于远程设备在硬件型号和操作能力上可能存在差异，它们的性能指标（如吞吐量和任务完成延迟）也会有所不同。因此，在设备注册后抽象设备配置文件的能力有助于更好的资源管理。设备驱动程序维护一个 device_profile 结构，记录与设备的外设、CPU、RAM 和其他硬件配置相关的关键信息，这些信息反映了设备的性能范围。例如，在聚合来自不同型号和计算能力的多个远程 KPU 的资源时，创建一个 VKpuDevProfile 结构来描述它们的硬件型号、计算能力和网络延迟信息。这有助于更高效地分配任务工作负载。

3.2.2 跨端点资源聚合
资源聚合涉及多个终端硬件设备的网络连接，以将来自多个设备的碎片化物理资源整合为池化资源。在图 4 中，我们首先在 InterConnect 模块中注册远程设备及其基本信息。由于远程设备在硬件型号和操作能力上可能存在差异，它们的性能指标（如吞吐量和任务完成延迟）也会有所不同。因此，在设备注册后抽象设备配置文件的能力有助于更好的资源管理。设备驱动程序维护一个 device_profile 结构，记录与设备的外设、CPU、RAM 等硬件配置相关的关键信息。例如，在聚合来自不同型号和计算能力的多个远程 KPU 的资源时，创建一个 VKpuDevProfile 结构来描述它们的硬件型号、计算能力和网络延迟信息。

3.2.3 分散式负载监控和决策
在远程设备注册后，本地会创建一个相应的虚拟设备驱动程序（称为影子设备），作为访问和操作远程设备的代理。影子设备的初始化过程类似于常规的本地 Virtio 虚拟设备驱动程序，但有一些额外的虚拟寄存器在设备配置空间中指示该设备是影子设备。初始化完成后，影子设备驱动程序也会挂在 Virtio 总线上，允许应用层通过标准设备驱动程序接口使用它。相应的远程物理设备也需要初始化，这包括创建 Virtqueues 和绑定物理设备，这些任务由远程端完成。初始化完成后，远程设备将启动一个线程来监听来自影子设备端的操作请求。一旦初始化完成，影子设备就可以运行了。

3.2.3 远程重定向
当本地应用层需要操作影子设备时，Virtio 驱动程序会将相应的请求重定向到 InterConnect 模块。然后该模块根据设备注册期间建立的设备地址映射信息序列化和封装 I/O 请求，并通过网络将其发送到相应的远程设备。远程 InterConnect 模块随后反序列化 I/O 请求并将其传递给 Virtio 虚拟设备驱动程序执行。远程设备完成执行后，它通过网络发送结果，最终本地驱动程序将操作结果返回给应用层。

3.3 轻量级实时迁移优化
为了实现低停机时间的无缝迁移，本文设计了以下优化：
- 差分打包：仅传输关键信息而不是整个运行时环境和内存状态。
- 队列清空：在迁移前清空队列，减少延迟。
- 只读预迁移：在迁移前进行只读操作，避免不必要的数据传输。

3.4 安全性考虑
本文在第 3.4 节进一步讨论了安全性考虑。

4.3 实现细节
本文实现的 vHAL 包括各种 Virtio 设备驱动程序，包括 Virtio-GPIO、Virtio-I2C、Virtio-Serial 和 Virtio-KPU。

4.3.1 设备虚拟化
本文实现的 vHAL 包括各种 Virtio 设备驱动程序，包括 Virtio-GPIO、Virtio-I2C、Virtio-Serial 和 Virtio-KPU。例如，在KPU-FACE操作期间，作业队列中每个帧的推理任务会被分发到多个节点上异步处理，而不会被前面的帧阻塞。每个帧都被封装为一个独立的KPU请求，并带有帧ID。这种设计是可行的，因为KPU-FACE推理是与帧无关的。每个帧都使用预先安装的模型权重和VKpuDevProfile中相同的模型规范进行处理。顺序错乱的帧或失败不会影响面部检测结果或与面部数据库的相似性匹配。在各种应用需求下探索替代策略的工作留待未来进行。

3.2.3 设备配置协商和动态后端切换
为了支持图2中显示的情况，即一个节点可能拥有另一个节点没有的KPU，UVirtio在初始迁移握手阶段实现了能力协商协议。每个节点维护一个特征位掩码标志ENABLE_VIRTIO_KPU，这是一个紧凑的位向量，表示其KPU硬件设备配置。UVirtio将KPU不视为固定的物理内存地址，而视为与通用virtual_kpu_execute()原语交互的抽象数据结构。因此，在运行时层面，UVirtio可以根据节点的本地特征位掩码标志自动将此虚拟调用映射到物理KPU（用于硬件加速）或Soft-KPU（基于软件的引用内核）。在状态传输开始之前，源节点会查询目标节点的位掩码。如果检测到不匹配，握手协议会触发强制模式切换。这确保了在移动一个字节的任务上下文之前，迁移过程已经知道了硬件差异。当任务必须迁移到没有KPU的“较弱”节点时，它通过软件回退来处理这种转换。到达目标节点后，UVirtio调度器检测到该标志的缺失，然后将其虚拟计算对象重新绑定到任何可能的软件推理引擎上，例如在CPU上编译的TinyML解释器[35]，以保证操作连续性，尽管帧率较低。UVirtio并不假设任意加速器内部状态总能转换为软件实现。只有当应用程序提供了可移植的状态表示和兼容的回退处理程序时，才允许迁移到较弱的目标节点。图5显示了实时迁移过程的一般工作流程。

3.3 轻量级部署和实时迁移
在嵌入式和物联网系统中，通常会执行预加载的、持久化的、与设备无关的应用逻辑，其运行时状态实际上反映在设备I/O操作和驱动程序状态信息中。因此，UVirtio没有迁移整个运行时环境和内存状态，而是在Virtio vHAL和Inter Connect模块的基础上实现了一种基于设备的轻量级动态管理机制。图5描述了一般的工作流程。我们假设应用程序二进制文件和任何不可变的模型数据已经位于目标端点，并传输了虚拟设备配置、待定的Virtqueue状态和可导出的物理设备状态。具有额外可变状态的应用程序必须重新构建该状态或注册特定的序列化回调。目前，具有不透明、不可导出的加速器状态的设备不在迁移范围内。

3.3.1 差异性打包
我们采用差异性打包方案来最小化需要迁移的数据量。在迁移过程中，迁移管理模块选择性地打包和序列化关键信息，这些信息主要包含三个部分：
- 前端的控制平面数据：这包括Virtio-MMIO虚拟寄存器及相关数据结构，它们决定了设备驱动程序在初始化和运行时的配置。
- Virtqueue和I/O请求相关的数据平面信息：这主要包括描述符表中的描述符、环形缓冲区中的描述符、I/O请求及其负载对应的存储空间。
- 后端的控制平面数据：这包括可能存在于实际物理设备上的状态信息，如GPIO引脚映射、端口信号电平和其他物理细节。

图6显示，迁移优化带来了减少停机时间的好处。通过关注这些关键组件，迁移过程确保了必要的驱动程序和设备状态得到有效保留和转移，从而在目标终端上无缝继续操作。

3.3.2 停机时间
停机时间是迁移过程中的一个主要性能指标，指的是由于迁移而导致系统无法提供服务的这段时间。为了最小化停机时间，我们开发了两种策略：队列清空和只读预迁移，如图6所示。队列清空是指在触发迁移操作时不接受新的Virtio请求，并不是立即执行迁移，而是等待Virtqueue中现有的Virtio请求完成并释放相关资源后，再继续后续的迁移过程。与迁移这些数据的开销相比，等待未完成的I/O操作完成并清空队列所花费的时间相对较少。根据Virtio规范，当Virtqueue为空时，尽管某些参数可能会改变，但从功能上看与初始化后的状态没有区别。因此，甚至可以完全跳过与Virtqueue相关内容的迁移。第5.5节中的实验也表明，这种设计有效减少了停机时间。只读预迁移的设计灵感来自于预复制的设计哲学，即在源设备驱动程序和应用程序继续运行时，可以先将设备的只读信息迁移到目标终端。这种方法减少了停机期间需要迁移的数据量，从而缩短了停机时间。通过在停止源之前传输尽可能多的数据，迁移的最后阶段（需要短暂暂停以传输剩余状态）可以显著缩短，使得迁移过程更加高效且干扰更小。

3.4 安全考虑
虽然设计主要关注跨设备资源共享的功能可行性和性能效率，但对于去中心化的边缘系统来说，安全性仍然是一个关键问题。目前，UVirtio假设在一个受信任的本地网络环境下运行，所有参与的边缘节点都经过了预先认证，并由一个统一的管理域管理。在这个受信任的上下文中，主要的安全攻击面涉及InterConnect模块和迁移机制。具体来说：
- 迁移过程中的数据完整性：为了确保迁移后的应用程序不会被不受信任的中间人篡改，未来的版本可以集成轻量级的加密签名。
- 访问控制：“基于设备配置”的vHAL（目前主要关注性能指标）可以扩展以包含安全令牌，确保只有授权的节点才能调用远程设备资源。通过明确将威胁模型限制在受信任的集群内，UVirtio避免了复杂的加密方案，这些方案可能会给资源受限的边缘设备带来开销。

4 实现
4.1 Virtio设备驱动程序
4.1.1 Virtio-GPIO
GPIO的配置在编译内核时与操作系统集成。可以通过ENABLE_VIRTIO_GPIO配置来决定是否为特定的物理GPIO设备启用GPIO虚拟设备驱动程序。GPIO虚拟引脚和物理引脚之间的映射规则也在配置文件中指定。UVirtio提供了五种I/O操作接口：open、close、write、read和ioctl。其中，open和close主要用于创建和销毁Virtqueue，而write、read和ioctl用于实现基本的GPIO操作。应用程序级别的虚拟设备I/O操作被封装成Virtio请求，这些请求包含三个字段：pin、val和cmd。目前支持五种cmd值：
- OUTPUT_DIRECTION：将指定的引脚设置为输出引脚。这是一个ioctl操作。
- INPUT_DIRECTION：将指定的引脚设置为输入引脚。这是一个ioctl操作。
- SET_VALUE：将指定引脚的值设置为val。这是一个写操作。
- GET_VALUE：读取引脚的值并将其填充到val中。这是一个读操作。
- SET_CONFIG：将引脚的输入/输出模式配置为对应于val的值，包括输入、输出、上拉、下拉。这是一个ioctl操作。

4.1.2 Virtio-I2C
Virtio I2C的配置也集成到了操作系统配置中。在编译内核时，可以通过ENABLE_VIRTIO_I2C配置来决定是否为特定的物理I2C设备启用Virtio-I2C虚拟设备驱动程序。Virtio描述符链包括OUT_HDR（输出头部）、I2C_BUF（用于存储通过I2C总线传输或接收的数据的缓冲区）和IN_HDR（输入头部）。目前，ioctl接口只支持一个命令：I2C_SLAVE_ADDRESS，用于配置Virtio-I2C驱动程序对应的I2C从设备地址。这个值由特定的外围设备制造商确定。使用Virtio-I2C设备时，用户首先通过ioctl接口设置目标I2C外围设备地址。这个地址由虚拟设备驱动程序在其配置信息中维护。对于后续的写和读操作，只需要提供读/写负载，因为请求中的地址信息由驱动程序填充。如果用户需要切换到不同的I2C设备，他们只需调用ioctl接口来修改地址信息。

4.1.3 Virtio-UART
目前UVirtio的UART串行支持一个ioctl命令来配置串行设备的基本特性，包括波特率、data_bits（表示每个数据帧中的有效数据位数）、stop_bits（表示数据帧的结束）、parity_mode（用于错误验证）和buffer_size（以字节为单位）。

4.1.4 Virtio-KPU
目前，UVirtio支持以下cmd指令：
- LOAD_MODEL：加载用于卷积计算的模型。ptr指向的内存空间包含了要执行的预加载模型。
- RUN_MODEL：执行卷积计算。ptr指向的内存空间存储了这次卷积计算的输入信息。
- WAIT_FLAG：检查标志以确定卷积计算是否已完成。ptr指向一个整数变量，值为0表示计算尚未完成，值为1表示计算已完成，允许读取输出结果。
- GET_OUTPUT：读取卷积计算的输出结果。ptr指向用于存储输出结果的预分配内存空间。可以在编译内核时使用ENABLE_VIRTIO_KPU标志来启用设备抽象。

4.2 InterConnect模块实现
InterConnect建立在以太网和LwIP轻量级协议堆栈之上。它包括四个组件：
- 设备协调器：管理影子设备和远程节点注册。
- （反）序列化模块：将Virtio请求转换为网络数据包。
- 通信模块：确保边缘节点之间的可靠传输。
- 迁移管理器：控制迁移工作流程和状态转移。
迁移在源节点和目标节点之间建立可靠的连接，执行只读预迁移和队列清空，使用差异性打包来序列化和传输最小的设备状态，并最终将服务切换到目标节点以恢复I/O。在开始迁移之前，源终端和目标终端之间会建立连接。请求通常由源终端发起。目标终端上的迁移管理模块创建一个线程来监听和接收迁移请求。一旦两边的迁移管理模块建立了基于以太网的网络连接，目标终端也创建一个线程来监听和接收来自源终端的迁移数据。所有后续操作都基于此连接进行。

4.3 MMIO地址冲突解决
为了防止在动态设备注册和实时迁移期间发生MMIO（内存映射I/O）地址空间冲突，UVirtio将应用程序的I/O访问与物理内存地址分离。具体来说，vHAL将外围控制寄存器映射到一个虚拟化地址空间。当远程或迁移的设备在边缘节点注册时，InterConnect模块动态分配系统虚拟内存块中未使用的一段来与设备的Virtio队列绑定。由于所有物理到虚拟的MMIO绑定都是通过操作系统的内存管理单元（MMU）或软件定义的I/O表在运行时动态管理的，因此不同设备之间的物理MMIO地址冲突根本被避免了。

图7显示了用作原型的两个RISC-V开发板的基准测试设置。组件用颜色标记，包括内置Kendryte K210 KPU的SiPEED M1W AIoT模块。这些板子还部署了EByte E22-400T30S LoRa模块、HanRun HR911105A以太网端口和RS485收发器模块。

5 评估
本节通过我们在图7中显示的基准测试设置，对UVirtio的性能进行了深入分析。我们回答了以下问题：
(1) UVirtio与操作系统的原生设备驱动程序实现以及RT-Thread [53]等SOTA解决方案相比如何？(1) 这些新引入的虚拟化开销是否会影响应用程序设置的正常功能（第5.2.1节）？

(2) UVirtio的跨端点资源聚合在哪些方面以及程度上改善了设备工作负载的延迟（第5.3.1节）和吞吐量（第5.3.2节）？

(3) 当设备扩展到多个节点时，UVirtio是否能够保持其资源共享方案带来的性能优势？

(4) UVirtio边缘侧迁移在停机时间方面表现如何，以及队列清空和预复制优化如何影响这些观察结果（第5.5节）？

5.1 实验设置
实验是在一个开发板上进行的，该开发板配备了Kendryte K210微控制器，这是一种运行在400 MHz频率下的64位RISC-V处理器。系统配备了8 MB的RAM内存和16 MB的闪存存储。开发板还配备了W5500以太网控制器、KPU、I2C控制器和RS485收发器模块。此外，还扩展了SanDisk 64 GB存储卡、OV2640摄像头、3.92英寸TFT显示器、BMP180气压传感器和步进电机。这些模块可以作为系统的新功能进行安装。对于资源聚合和负载均衡测试，我们使用了两个设置相同的开发板。确切地说，存储卡仅用作数据记录和评估工具的辅助扩展存储。核心UVirtio系统、操作系统内核和设备驱动程序仅占用芯片上非常小的一部分闪存和RAM，这与实际边缘部署的内存限制一致。

5.2 单一硬件平台
在这里，我们测试了单个硬件上基本I/O操作的延迟，以量化vHAL引入的额外开销。实验结果如图8所示。为了进一步说明性能瓶颈，还将UVirtio接口调用过程分为三个部分：前端、后端和通信。
图8显示了不同负载大小下UART输出的延迟情况，负载范围从2字节到1000字节，缓冲区大小设置为16字节。可以观察到，当负载大小≤16字节时，UVirtio-Serial的UART性能下降最为明显。底部列出了UVirtio设备驱动程序I/O接口的各种延迟来源与原生操作系统实现的比较。

5.2.1 延迟
从图8的(a)到(d)可以看出，在几乎所有设备驱动程序的I/O操作中，UVirtio驱动程序的延迟都明显高于原生设备驱动程序，最高的延迟达到了原生驱动程序的16倍，如在UVirtio-KPU ioctl接口的WAIT_FLAG和GET_OUTPUT命令中看到的那样。通过分析I/O操作的执行过程，可以推断出大部分延迟来源于前端和后端之间的通知和进程调度。在原生实现中，I/O操作的执行是一个单线程函数调用，没有调度和通信开销。没有前端或后端的概念。相比之下，在实现的UVirtio设备驱动程序中，前端和后端被设计为两个独立的线程，它们通过信号量和事件机制进行通信，从而引入了开销。此外，所使用的硬件终端仅支持单核操作，需要前端和后端之间的线程调度来完成正常的I/O操作，这也带来了不可避免的调度开销。这种开销在多核系统中可以被规避。在开放式的I/O操作中，前端和后端之间的通信和调度最为频繁，因此开放式I/O操作中的额外开销最为明显。实际上，由调度和通信引入的额外开销相对固定，单线程切换大约引入0.02毫秒的延迟。如果I/O操作本身的延迟显著大于这个值，那么线程切换的影响就会被掩盖。如图8的(b)所示，由于I2C设备本身的读写延迟已经达到约0.5毫秒，UVirtio设备驱动程序和原生设备驱动程序之间的性能差异并不显著。此外，UVirtio-I2C驱动程序的ioctl操作不涉及前端和后端之间的通信，因此不会产生通信调度开销。同样，UVirtio-Serial驱动程序的读取操作是通过中断实现的，也不涉及前端和后端之间的通信或调度，因此没有额外的开销。在这两个测试案例中，UVirtio设备驱动程序展示的整体延迟与原生驱动程序相当。这进一步表明，尽管引入了通信和调度的延迟，UVirtio设备驱动程序并不显著影响现有I/O操作接口的性能，而在多核环境中这些延迟可以很容易被掩盖。

除了设备驱动程序之间的I/O延迟外，设备使用的总线协议和硬件的物理特性也在I/O操作的性能中起着决定性作用。图8(e)比较了在串行端口波特率为115200、缓冲区大小为16字节、数据位为8字节的情况下，不同输出负载大小下UVirtio-Serial驱动程序和原生串行端口驱动程序的I/O延迟。可以观察到，当负载大小小于或等于缓冲区大小16字节时，串行端口设备输出操作只需要将数据复制到缓冲区中，导致延迟在微秒级别，这使得调度通信开销成为UVirtio-Serial的性能瓶颈。

5.2.2 嵌入式应用
我们评估了UVirtio在嵌入式应用环境中的性能，并将其与两个基准进行了比较：普通的通用操作系统和RT-Thread的官方端口（由通用操作系统维护者提供）。不幸的是，K210尚未得到官方支持，所以我们开发了一个自定义的RT-Thread插件来测试KPU-FACE。图9(a)到(e)展示了比较五种不同应用程序延迟的实验结果。图9(f)显示了KPU视觉任务的CPU trace。由于视频数据的密集预处理，CPU几乎处于饱和状态，表明资源利用率很高。

5.3 跨端点动态管理
在本节中，我们基准测试了跨多个设备的动态管理机制，并分析了其性能影响。
图10显示了远程协作延迟随着网络延迟的变化情况。

5.3.1 延迟
为了展示控制重定向对设备I/O操作性能的影响，选择了三个嵌入式应用程序——GPIO-SERVO、I2C-SENSOR和UART-PC。使用了两个硬件终端，一个终端处理应用程序的逻辑控制，另一个终端管理输入和输出操作。本研究模拟了多种网络延迟环境，并测量了应用程序的总运行延迟以及归因于网络传输的延迟比例。实验结果如图10所示。显然，远程设备协作为I/O操作引入了显著的网络传输开销。随着网络延迟的增加，网络传输在应用程序总运行时间中所占的比例也会增加。然而，网络延迟对不同应用程序的影响各不相同。实验中使用的三个应用程序代表了三种不同类型的应用程序，它们在读写操作方面具有独特的特性。GPIO-SERVO代表了一类对延迟敏感、I/O密集型应用程序。它频繁地在低间隔时间内执行I/O输出，这些I/O操作的频率直接决定了伺服电机的旋转速度。结果表明，由于I/O操作数量众多，即使在网络延迟较低的情况下，网络通信时间在应用程序执行过程中也占据了很大比例。此外，网络引起的I/O操作延迟对应用程序性能有明显影响，表现为伺服电机旋转速度的明显下降。UART-PC代表了一类对延迟不敏感、I/O较少的应用程序。其执行过程中的I/O操作比例相对较低，因此远程协作引入的网络开销也很小。 moreover，网络延迟的增加也不会显著影响系统的运行性能。I2C-SENSOR代表了另一类应用程序。当网络延迟较低时，远程协作引入的额外开销很小，不会影响应用程序的结果。然而，较高的网络延迟可能会降低应用程序的性能，例如增加传感器的采集间隔，降低灵敏度，甚至导致其故障。

5.3.2 性能和资源聚合
在图11中，我们测试了基于跨终端互连模块实现的资源聚合机制。对于KPU-FACE场景，在两个通用终端之间建立了网络链接，聚合了两个KPU设备的计算资源。KPU-FACE应用程序的计算任务在不同终端之间以不同的比例分配。测量了每个终端完成任务所需的延迟以及整个系统的KPU面部识别计算吞吐量。KPU-FACE应用程序的二进制文件和模型权重预先安装在每个支持KPU的端点上。资源聚合在运行时不会迁移应用程序二进制文件或模型参数。对于每个推理请求，源节点将180 KB的输入图像/张量传输到一个选定的远程端点，并接收36 KB的结果缓冲区。帧按请求粒度分配：每个帧完全由一个KPU处理，不会在多个节点之间划分。从图11(a)可以看出，远程延迟显著高于本地设置中的延迟。一个可能的原因是，每当KPU-FACE执行卷积计算时，它会向远程发送180 KB的图像数据，并检索36 KB的结果数据。限制网络带宽（10 Mbps）会加剧这一情况，最终导致本地和远程延迟之间的差距扩大到五倍。需要注意的是，虽然动态分配任务负载会引入显著的延迟，但在某些配置下仍然可以提高整个系统的吞吐量。当本地和远程端之间的负载分布约为5:1，接近它们延迟的比例时，系统可以实现最佳性能，吞吐量比纯本地执行增加了约18%。在图11(b)和(c)中可以观察到，在并行采集的情况下，整合本地和远程传感器资源可以显著提高系统吞吐量。在所有四个应用中，整体系统性能分别提高了37.6%、80.6%、86.4%和76.1%。除了响应时间外，活跃传感器的物理特性（如ZG09传感器）还包括更新时间，即两次采集之间的间隔或数据刷新频率。例如，ZG09通常具有1秒的更新时间，这意味着它每秒收集一次二氧化碳浓度值，并将这些值缓存在其内部存储介质中。当传感器从终端接收数据读取请求时，它会直接从缓存中检索数据并返回；在单个刷新间隔内读取的值保持不变。这个间隔从根本上决定了传感器检测物理量变化的最小时间间隔，反映了其采集灵敏度。通过整合传感器资源，可以从多个传感器设备交替读取数据，从而提高应用程序的整体更新频率，进而提高采集应用程序的灵敏度。

图12。(a) 使用I2C/UART传感器聚合时，2/4/8/16节点的传感器任务的延迟/吞吐量。4、8、16节点场景的数据来自OMNeT++离散仿真。(b) 使用KPU聚合时，面部检测任务的延迟/吞吐量。我们在OMNeT++中将节点建模为带宽为10Mbps的边缘设备。性能拐点出现在N=8时，此时通信成本超过了计算收益。KPU请求使用ECT策略在可用端点之间分配。

5.4 通过仿真评估可扩展性
5.4.1 数据平面
为了验证UVirtio在大规模边缘场景中的数据平面可扩展性，我们使用OMNeT++和INET框架[63]构建了一个离散事件仿真来研究网络级别的影响。我们将节点建模为通过以太网互连的边缘设备，它们使用10 Mbps的带宽进行通信。仿真测量了4、8和16节点规模下的端到端I/O延迟和系统吞吐量，其中2节点的数据来自图11中的真实硬件。具体来说，在图12(b)中的KPU聚合任务中，UVirtio将推理吞吐量从12 FPS显著提升到了18 FPS，但在双节点设置中，可扩展性本质上受到可用互连带宽的限制，此时出站数据大小明显大于入站数据大小。我们发现一个性能饱和点在N=8时，吞吐量稳定在大约24.5 FPS。这表明虽然UVirtio提供了一个灵活的资源池，但RISC-V边缘设备的最佳集群规模应根据计算收益和通信成本之间的平衡进行调整。图12(b)显示，当有效载荷不会占用过多带宽时，延迟和吞吐量保持高效率且通信开销较低。值得注意的是，尽管N=8的情况显示出比N<8的情况更长的端到端延迟，但它实现了最高的吞吐量。我们将此归因于多个推理请求同时执行。增加N可以暴露更多的并行KPU容量，使得每个单位时间内完成更多的请求，即使每个单独的请求都会经历额外的通信和排队延迟。在N=8时，并行执行的收益仍然超过了每个请求的延迟增加。在N=16时，网络竞争占主导地位，导致吞吐量下降。

图13. UVirtio在真实XiUOS端点上的稳态控制平面开销。(a) 所有影子设备激活后的持久内存占用，分为NRT/设备配置文件条目、影子设备元数据和Virtqueue/辅助状态。(b) 由一个过载触发的资源查询和稳态心跳消息生成的网络流量。

5.4.2 控制平面
除了图12中评估的应用层可扩展性外，我们还在图13中量化了远程设备发现和影子设备管理引入的控制平面开销。由于这些操作不需要所有远程设备的物理存在，我们在真实的XiUOS端点上实例化了2、4、8和16个设备配置文件。每个配置文件都会经过实际的影子设备创建、NRT更新和目标选择代码路径。我们关注内存占用、探测和心跳流量，因为这些成本在稳态操作期间仍然活跃。
图13(a)报告了所有远程设备注册后的持久内存占用。随着发现的远程设备数量增加，总内存占用也会增加。在N=16时，所有影子设备消耗24.8 KB。Virtqueue状态占用了大部分内存，而NRT和设备配置文件元数据在N=16时仅贡献了8.0 KB。图13(b)显示了控制平面生成的网络流量。一个过载触发的资源查询包括一个多播请求和每个邻居最多一个响应。

图14. 迁移的停机时间及其分解，同时展示了排队清理和迁移前的优化与原始情况的对比。

5.5 迁移
本节测试了基于虚拟设备迁移实现的动态部署机制。在图14中，停机时间主要由三个部分组成：设备物理状态迁移、驱动程序状态迁移和Virtqueue数据迁移。Virtqueue的同步不仅包括描述符表、可用/使用的描述符缓冲区和一些基本Virtqueue变量的复制和传输，还包括队列中当前未处理I/O请求负载所对应的内存区域。一些Virtio设备甚至包含多个Virtqueue，使得Virtqueue的迁移时间是停机时间的主要组成部分。设备的物理状态由具体硬件决定，因此不同外设的迁移时间也会有所不同。我们通过两种策略进一步优化了迁移过程：队列清理和读取障迁移前的优化。它们对总停机时间的影响可以在图14中看到。

6 讨论
功耗
值得注意的是，虽然UVirtio当前的设计主要关注于最小化虚拟化开销、确保硬实时确定性以及满足高可用性目标。这项工作的主要目标是验证在边缘节点的极端约束条件下的可行性，具体的功耗优化并未详细讨论。尽管如此，我们认识到功耗效率对于能源敏感的工业物联网部署是一个关键指标，并将这一领域留待未来的工作。

多对一虚拟化
将多个物理资源聚合到一个虚拟实例的概念，称为多对一虚拟化（例如GiantVM [28]和Aggregate VM [12]），已在云环境中得到了广泛研究。受此愿景的启发，UVirtio将聚合范式扩展到了无处不在的边缘计算领域。与GiantVM [28]不同，后者需要RDMA来克服软件内存一致性的重大开销，UVirtio通过标准化的VirtIO协议专注于加速器级别的虚拟化。这种设计选择使我们能够在资源有限的RISC-V节点上实现高效的KPU池化，正如我们的性能评估所展示的，保持了高吞吐量，适用于对延迟敏感的工业应用。

7 结论
在这项工作中，我们引入了UVirtio，这是一个轻量级且可扩展的虚拟化框架，专为跨工业边缘设备的普遍资源共享而设计。通过利用基于设备配置文件的vHAL和InterConnect模块，UVirtio解决了资源受限和实时边缘环境中现有虚拟化解决方案的局限性。我们的框架实现了高效的设备虚拟化、动态资源池化和在设备驱动程序级别上的实时迁移，并且性能开销极小。在RISC-V开发板上的广泛评估表明，UVirtio实现了接近原生的I/O延迟，通过资源聚合显著提高了系统吞吐量，并在毫秒级别实现了实时迁移和优化的停机时间。