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

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

　　

# 摘要

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

## AI摘要

（查看此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. 带有嵌入式边缘节点的新型无处不在工业应用。**

尽管边缘节点在现代工厂中无处不在，但在资源管理方面却面临困境。一方面，现代高精度深度学习网络往往超出了单个边缘单元的单边计算能力。例如，像Kendryte K210[55]这类典型的超低功耗边缘AI视觉芯片，只能运行精度有限且量化严重的极简（"nano"）模型[64]。另一方面，虽然大量物联网设备物理存在，但它们的资源仍然碎片化。大多数工业环境要求本地硬实时响应[5, 21, 42, 65]，部分还运行在去中心化[7, 47, 49, 69]的私有云外网络设置[66, 70]中，以确保低延迟和数据合规性。摄像头、传感器和加速器在物理上分散在多个独立设备上，形成了孤立的"数据孤岛"，阻碍了协作资源调度和推理。云边解决方案[16, 33, 39, 71]受限于网络往返延迟、带宽和覆盖范围。在服务连续性方面，鉴于车间地面的恶劣运行条件，迁移是动态工业边缘环境中的基石功能，正如先前的移动感知边缘计算研究[8, 36]所强调的那样。

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

为解决上述关注点，我们提出了UVirtio，一种无处不在的资源共享机制，在以下三个目标方面推进了当前研究。UVirtio使用了一种基于接口统一虚拟硬件抽象层（vHAL）的设备配置文件抽象扩展，该扩展基于ACRN hypervisor[34]，并提供基于原生UOS[9]的轻量级虚拟化。对神经计算芯片、气压传感器和伺服电机的虚拟化对工业物联网应用引入了最小的开销。在聚合方面，UVirtio引入了一种设备级协作方案，显著提高了传感器物理测量采集的吞吐量，并允许通过聚合两块开发板来实际执行人脸识别。此外，UVirtio提出了一种细粒度的设备驱动级迁移机制，称为InterConnect模块。基于虚拟机迁移优化技术，如差异打包和队列优化，InterConnect不是迁移整个运行环境和运行状态，而是实现了停机时间低于40毫秒的设备在线迁移。UVirtio作为XiUOS生态系统中的一个子系统实现，XiUOS作为运行在我们物理RISC-V节点上的基础操作系统，处理底层硬件初始化、本地线程调度和基本物理驱动程序管理。RISC-V在低成本工业边缘设备中的日益普及及其开放ISA生态系统激励我们专门针对RISC-V微控制器的架构来定制vHAL的注册、运行时MMIO拦截和虚拟化，尽管UVirtio的概念性软件抽象也适用于其他资源受限的MCU系列。总之，UVirtio做出了以下贡献：

— 我们利用XiUOS[9]（一种UOS）上的Type I虚拟化，通过灵活的设备配置文件模型映射各种硬件设备，同时保持与原生设备驱动程序以及UOS上官方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]，拥有8 MiB SRAM，成本约为5到10美元[14]。文献[62]报告称，在K210上进行有意义的图形处理只能在神经网络参数量保持在5.9 MiB以下时实现。这意味着独立的边缘节点只能支持尽可能最小的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级别），并支持本地确定性执行。然而，代价是它们实现了平坦内存模型。这意味着任务静态地耦合到硬件上的特定物理基地址。像Jitsu[40]这样的单内核[41, 45]在启动延迟方面表现出色，代价是几乎没有地址空间管理和设备模型。静态链接和最小设备模型的设计哲学排除了高效的资源池化。嵌入式软件与虚拟化的交汇催生了专为嵌入式和物联网场景设计的新Type I VMM。XVisor[50]将所有设备驱动程序实现为单个具有最高系统权限的软件层，以实现直接硬件访问和模拟。Hermes[32]以统一中断处理层的形式抽象硬件资源管理。它们可以实现比工作站级 hypervisor 更高的资源利用率，同时保持强大的功能隔离。然而，这两个 hypervisor 都遵循单体设计，仅支持有限范围的硬件类型。ACRN[34]与单体方案不同，将设备资源管理卸载到用户空间。这提供了一种灵活、轻量且可扩展的嵌入式虚拟化解决方案，同时确保了一定程度的安全性和实时性能。一个显著的替代方案是Jailhouse[52]和Bao[42]使用的静态分区策略。尽管静态分区提供了强大的隔离和实时保证，但它不可避免地牺牲了资源利用效率和灵活性。UVirtio采用模块化设计，确保跨应用场景的通用性，并将单一硬件平台的资源抽象扩展到跨端点的可扩展虚拟化和动态迁移机制。

## 2.3 UOS中的资源管理

无处不在的计算需要在广泛的场景中管理资源。物联网[23]、游戏[58]和分析[39]应用要求最低延迟，许多工作探索了云边迁移的可能性[24, 31, 69]，使用预拷贝[61]、后拷贝[25]或混合方案。最先进的云边解决方案[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 后端在 3.1.1 节中统一了各种硬件表示，如 GPIO 和 I2C，3.1.2 节中的 UART 串口，以及 3.1.3 节中的内核处理单元（KPU）。

为了实现动态池化并启用设备到设备的聚合和设备协作，本文在 vHAL 之上设计了一个名为 InterConnect 的资源动态管理模块，详见 3.2 节。该模块在 3.2.1 节中建立了一种设备协调器机制，通过作为远程设备驱动程序的本地代理的“影子设备”来促进远程操作和重定向。3.2.2 节中的任务聚合基于这三个模块，通过扩展本地影子设备以对应一个或多个远程设备来实现灵活的任务划分。3.2.3 节讨论了设备概况协商和动态后端切换（例如，当任务目的地不可用 KPU 时）。InterConnect 还包括一个迁移管理器，结合 3.3 节中的优化，实现了低停机时间的无缝迁移。3.3 节中的边缘侧热迁移通过差量打包、队列排空和只读预迁移优化得到了进一步优化。UVirtio 不再迁移整个运行时环境和内存状态，而是通过迁移管理器选择性地打包关键信息，从而实现更高效的迁移过程。3.4 节进一步讨论了安全考量。最后，我们在 4 节中详细说明了我们的实现细节。

3.1 设备虚拟化
本文实现的 vHAL 由各种 Virtio 设备驱动程序组成，包括 Virtio-GPIO、Virtio-I2C、Virtio-Serial 和 Virtio-KPU。

3.1.1 GPIO 和 I2C
为了增强 GPIO 设备管理的灵活性并提高系统资源利用率，本文引入了一种类似 ACRN [34] 的虚拟 GPIO 引脚映射机制。UVirtio 提供了五个 I/O 操作接口：open、close、write、read 和 ioctl。其中，open 和 close 主要负责创建和销毁 Virtqueues，而 write、read 和 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 具有独特的工作流程。与发送不同，接收不是由应用程序层发起的，而是当收到外部输入时由硬件中断触发的。因此，在串口设备驱动程序的 open 操作期间，除了初始化 RX Virtqueue 外，还会预分配一个空白内存缓冲区，并用指向该缓冲区的虚读请求填充 RX Virtqueue。后端还将一个回调函数绑定到串口中断。当发生串口输入中断时，串口后端直接检索一个可用的描述符（即一个虚读请求），用接收到的数据填充预分配的缓冲区，并将该描述符放入已用描述符环中。当应用程序调用 read 接口时，前端驱动轮询 Virtqueue，直到检索到实际输入数据。在向应用程序层返回数据后，它会将虚读请求重新加入可用描述符环，为后续输入做准备。这种设计确保了与操作系统串口驱动行为的一致性。

3.1.3 内核处理单元（KPU）
本研究中使用的硬件配备了算能 K210 芯片，该芯片集成了 KPU 加速器，用于简单的小规模 CNN 计算任务，提供高达 1 TFOPS（每秒万亿次浮点运算）的计算性能。KPU 接口不提供 read 和 write。相反，所有操作都是 ioctl。

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

3.2.1 跨终端设备协作
基于 vHAL 层和 InterConnect 模块，UVirtio 实现了跨终端设备协作。基于 InterConnect 模块的远程操作重定向的典型工作流程如图 3 所示。

图 3。实现边缘到边缘资源动态池化和迁移的 InterConnect 模块概述。

设备注册。为了在终端之间建立设备协作，第一步是确认远程设备的 IP 地址、端口和基本属性。设备注册分为两种类型：静态和动态。静态设备注册发生在本地终端启动时，通过静态配置文件确定已知的远程 IP 地址和可用的设备类型。随着本地虚拟设备驱动的初始化，它根据配置文件继续映射远程设备的影子设备。另一方面，动态设备注册涉及在本地终端初始化时分配一个线程，用于监听并接收由远程设备主动发起的注册请求。这两个过程将 InterConnect 模块的管理结合在一起。

影子设备。一旦远程设备注册，就会在本地创建一个相应的虚拟设备驱动程序，称为影子设备，作为访问和操作远程设备的代理。影子设备的初始化过程与普通本地 Virtio 虚拟设备驱动类似，但有所不同。它在设备配置空间中包含额外的虚拟寄存器，以指示该设备是影子设备。初始化后，影子设备驱动也挂载在 Virtio 总线下，允许应用程序层通过标准设备驱动接口使用它。相应的远程物理设备也需要初始化，包括创建 Virtqueues 和绑定物理设备，这些任务由远程端完成。初始化完成后，远程设备将生成一个线程，监听指定端口上从影子设备端发送的操作请求。一旦初始化完成，影子设备即可准备操作。

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

图 4。具有不同型号、设备概况和延迟的设备的跨终端资源聚合。

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

去中心化负载监控和决策。在远程设备注册后，随后会在本地创建一个影子设备，作为访问和操作远程设备的代理。与设备重定向不同，在资源聚合中，单个影子设备可以对应一个或多个远程设备。在没有集中协调器的情况下，UVirtio 利用 InterConnect 层内的去中心化点对点状态交换协议。每个边缘节点维护一个本地软状态邻居资源表（NRT）。为了防止资源受限板卡上的网络拥塞，节点不会连续流式传输细粒度的负载详细信息。相反，我们实现了一种结合低频心跳搭载的按需探测机制。当一个节点的本地设备负载超过预定义阈值时，其 InterConnect 模块会广播一个轻量级资源查询。邻居节点回复它们当前的设备概况描述符和可用的执行队列槽位。

基于通过按需探测机制收集的信息，UVirtio 采用了一种轻量级预估完成时间（ECT）策略来确定任务应在本地执行还是卸载到远程端点。对于任务 t 和候选端点 j，UVirtio 估算其完成时间为 ECT_j(t)=(q_j+1)sˉ_j(t)+RTT_j+(B_in(t)+B_out(t))/BW^j，(1) 其中 q_j 是当前在端点 j 的执行队列中等待的请求数，sˉ_j(t) 是任务 t 在相应设备上的预估服务时间，RTT_j 是源和端点 j 之间测量的往返网络延迟。B_in(t) 和 B_out(t) 分别表示任务的输入和输出数据大小，BW^j 表示到端点 j 的预估可用带宽。ECT 策略使用的变量仅在任务完成后更新，并搭载在现有探测中。可用带宽 BW^j 从最近完成的传输中估算，而服务时间估计 sˉ_j(t) 针对每个设备和任务类型单独维护，使用指数加权移动平均。该策略可以结合更丰富的应用程序层语义进一步优化。

例如，在 KPU-FACE 推理操作期间，作业队列中每一帧的推理任务被分发到多个节点上进行异步处理，而不会被前一个帧阻塞。每一帧都被封装为带有帧 ID 的独立 KPU 请求。这种设计之所以适用，是因为 KPU-FACE 的推理是逐帧独立的。每一帧都使用预先安装的模型权重以及 VKpuDevProfile 中相同的模型规范进行处理。乱序帧或处理失败不会影响人脸检测结果，也不会影响与人脸数据库的相似度匹配。针对各种应用需求的替代策略的探索留待未来工作。

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

图5. 实时迁移过程的一般工作流程。

3.3 轻量级部署与实时迁移

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

3.3.1 差异打包。我们采用差异打包方案来最小化需要迁移的数据量。在迁移过程中，迁移管理模块选择性打包和序列化关键信息，主要包含三个部分：

- 前端控制平面数据：包括 Virtio-MMIO 虚拟寄存器和相关数据结构，这些在初始化和运行时决定设备驱动程序的配置。

- Virtqueue 和 I/O 请求相关的平面数据：主要包括描述符表中的描述符、环形缓冲区中的描述符、I/O 请求以及其负载对应的内存空间。

- 后端控制平面数据：包括实际物理设备上可能存在的状态信息，如 GPIO 引脚映射、端口信号电平以及其他物理细节。

通过聚焦这些关键组件，迁移过程确保了关键驱动和设备状态得到保存和高效传输，从而实现目标终端上的无缝操作延续。

3.3.2 停机时间。停机时间是迁移的一个重要性能指标，指的是由于迁移导致系统无法提供服务的时期。为了最小化停机时间，我们开发了两种策略：队列排空和只读预迁移，如图6所示。

队列排空是指在触发迁移操作时不再接受新的 Virtio 请求，但不立即执行迁移。相反，它等待 Virtqueue 中现有的 Virtio 请求完成并释放相关资源，然后再继续后续的迁移过程，如图6所示。与迁移这些数据的开销相比，等待未完成 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。这是一个 write 操作。

- GET_VALUE：读取 pin 的值并填入 val。这是一个 read 操作。

- SET_CONFIG：将 pin 的输入/输出模式配置为与 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 外设地址。该地址由虚拟设备驱动程序在其配置信息中维护。对于后续的 write 和 read 操作，只需提供读写负载，因为请求中的地址信息是由驱动程序填充的。如果用户需要切换到不同的 I2C 设备，只需调用 ioctl 接口修改地址信息即可。

4.1.3 Virtio-UART

目前，UVirtio 的 UART 串口支持单个 ioctl 命令来配置串行设备的基本特性，包括 baud_rate（波特率）、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（内存映射输入/输出）地址空间冲突，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] 等最先进解决方案相比如何？

新引入的虚拟化开销是否会影响应用设置（第 5.2.1 节）的正常功能？（2）UVirtio 的跨端资源聚合以何种方式、在多大程度上改善了设备工作负载的延迟（第 5.3.1 节）和吞吐量（第 5.3.2 节）？（3）当设备扩展到多个节点时，UVirtio 能否保持其资源共享方案带来的性能优势？（4）UVirtio 的边缘侧迁移在下机时间方面表现如何，队列排空和预复制优化以何种方式影响这些观察结果（第 5.5 节）？

5.1 实验设置
实验在一块开发板 [60] 上进行，该板配备 Kendryte K210 MCU，这是一个运行频率为 400 MHz 的 64 位 RISC-V 单元。系统配置了 8 MB 内存和 16 MB 闪存。开发板自带 W5500 以太网控制器、KPU、I2C 控制器和 RS485 收发器模块，并通过扩展方式添加了 SanDisk 64 GB 存储卡、OV2640 摄像头、3.92 TFT 显示器、BMP180 气压计以及步进电机，这些模块可作为系统的新功能进行安装。对于资源聚合和负载均衡测试，我们使用了两块配置完全相同的板子。准确地说，存储卡仅用作数据记录和评估工具的辅助扩展存储。核心的 UVirtio 系统、操作系统内核和设备驱动仅占用片上闪存和内存中很小的一部分，符合真实边缘部署的内存约束。

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 设备驱动中，前端和后端被设计为两个独立线程，它们通过信号量和事件机制按照 Virtio 标准进行通信，从而引入开销。此外，所使用的硬件终端仅支持单核运行，需要在前端与后端之间进行线程调度才能完成正常的 I/O 操作，这也带来了不可避免的调度开销。在多核系统中，这一开销可以被规避。在 open I/O 操作中，前后端之间的通信和调度使用最为频繁，这就是为什么 open 操作的额外开销在所有操作中最为明显的原因。

事实上，调度和通信引入的额外开销相对固定，单次线程切换会带来约 0.02 毫秒的延迟。如果 I/O 操作本身的延迟远大于此值，线程切换的影响随后就被掩盖了。如图 8 (b) 所示，由于 I2C 设备自身的读写延迟已经达到约 0.5 毫秒，UVirtio 设备驱动与原生设备驱动之间的性能差异微乎其微。此外，UVirtio-I2C 驱动的 ioctl 操作不涉及前后端之间的通信，因此不会产生通信调度开销。类似地，UVirtio-Serial 驱动的 read 操作通过中断实现，也不涉及前后端之间的通信或调度，消除了来自这些过程的额外开销。在这两个测试案例中，UVirtio 设备驱动展现出与原生驱动相当的总体延迟。这进一步表明，UVirtio 设备驱动对现有 I/O 操作接口的性能没有显著影响，尽管存在通信和调度带来的延迟，但在多核环境中这些延迟很容易被掩盖。

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

5.2.2 嵌入式应用
我们评估了 UVirtio 在嵌入式应用设置下的性能，并与两个基线进行比较：原版通用操作系统（ubiquitous OS），以及通用操作系统维护者向原版操作系统提供的 RT-Thread 官方移植版本。遗憾的是，K210 尚未获得官方支持，我们开发了一个自定义 RT-Thread 插件以测试 KPU-FACE。图 9 (a) 到 (e) 给出了比较五种不同应用延迟的实验结果。图 9 (f) 展示了 KPU 视觉任务的 CPU 追踪。由于视觉数据的密集型预处理，CPU 几乎处于饱和状态，这表明资源利用率很高。

图 9. 不同通用应用操作在原版操作系统 [9]、UVirtio 以及原版操作系统的 RT-Thread 官方移植版本 [53] 上的微秒级延迟和 CPU 利用率。这些操作在实际应用中可能被调用多次，须表示各操作的变化范围。我们开发了自定义插件以支持 RT-Thread 移植版本与专有 K210 硬件的集成。GPIO、I2C 和 UART 任务的 CPU 利用率较低，约为 2.5%–4.5%，因此未予展示。

在微观层面，UVirtio 通常在三种情况中表现出最高延迟，尽管 UVirtio 与原生操作系统或 RT-Thread 之间的延迟差异非常小。最大的平均延迟差距在约 10 ms 以内。考虑到正常的系统波动和传感器固有的响应时间，在 GPIO-LED、GPIO-SERVO 和 UART-PC 的情况下，可以得出结论：本研究实现的 UVirtio 虚拟设备驱动表现出与原生设备驱动相同的 I/O 性能，对应用没有显著影响。

在影响最明显的实验，例如 I2C-SENSOR 和 KPU-FACE 中，UVirtio 引入的额外开销可能是因为，当在应用层面进行评估时，应用的运行时延迟不仅受单个 I/O 操作延迟的影响，在更大程度上还受其运行逻辑和实际需求的影响。例如，在 GPIO-SERVO 应用中，舵机的旋转需要多个 GPIO 接口按特定时钟频率依次输出电平信号，通常处于毫秒量级。在 I2C-SENSOR 应用中，温湿度传感器的工作原理规定，单次数据采集必须先向 I2C 接口输出指定信号，然后等待 20–40 ms 再读取输入，才能获取有效且准确的测量结果。在 KPU-FACE 应用中，标准人脸识别流程包括图像采集、卷积计算和识别框显示等步骤，仅卷积计算就需要几十甚至上百毫秒，导致总体延迟较大。在此类场景中，UVirtio 驱动为 I/O 操作引入的额外开销远小于 1 ms，因此不仅不影响各应用的正常功能，而且所引入的总体延迟也可以忽略不计。

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 操作所占比例相对较低，因此远程协作引入的网络开销也很小。此外，增加网络延迟不会显著影响系统运行性能。I2C-SENSOR 代表另一类应用。当网络延迟较低时，远程协作引入的额外开销很小，不影响应用结果。然而，较高的网络延迟可能会降低应用性能，例如增加传感器采集间隔、降低灵敏度，甚至导致其失效。

图 11. (a) 启用 KPU 聚合的人脸检测任务延迟/吞吐量。横轴表示由远程终端执行的任务比例，0% 表示纯本地执行，100% 表示纯远程执行。(b)、(c) 启用 I2C/UART 传感器聚合的传感任务延迟/吞吐量。BMP.A 是 I2C 总线上的 BMP180 气压高度传感器型号，HS.T.H 是 I2C 总线上的 HS3000X 温湿度传感器型号，QS.WS. 是 UART 总线上的 QS-FS 风速风向传感器型号，ZG.CO2 是 UART 总线上的 ZG09 CO2 浓度传感器型号。

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）2/4/8/16个节点下，采用I2C/UART传感器聚合的传感器任务延迟/吞吐量。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将聚合范式扩展到了泛在边缘计算领域。与需要通过RDMA来对抗软件内存一致性所带来的显著开销的GiantVM [28]不同，UVirtio专门通过标准化的VirtIO协议实现加速器级虚拟化。这一设计选择使我们能够在资源受限的RISC-V节点上实现高效的KPU池化，正如我们的性能评估所示，为对延迟敏感的工业应用维持高吞吐量。

7 结论

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