VirtIO Networking虚拟网络设备实现架构

VirtIO

VirtIO 由 Rusty Russell 开发，最初是为了支持自己开发的 lguest Hypervisor，其设计目标是在虚拟化环境下提供与物理设备相近的 I/O 功能和性能，并且避免在虚拟机中安装额外的驱动程序。基于这一目标，后来通过开源的方式将 VirtIO 延伸为一种虚拟化设备接口标准，并广泛地支持 KVM、QEMU、Xen 和 VMware 等虚拟化解决方案。

为了追求更高的性能和更低的开销表现，VirtIO 采用了 Para-virtualizaiton（半虚拟化/准虚拟化）技术路线，本质区别于性能低下的 Full-virtualizaiton（e.g. QEMU I/O Emulation）。这也意味着使用 VirtIO 的 GuestOS 需要经过一定的代码修改（安装非原生的 Device Driver），这也是为什么需要将 VirtIO 定位于 “虚拟化设备接口标准“ 的原因，其整体的集成架构需要由 Front-end（GuestOS Kernel Device Driver）和 Back-end（VMM Provider）共同遵守统一的传输协议。

在应用 VirtIO 的场景中，除了 GuestOS 需要安装额外的 VirtIO Front-end Device Driver 这一点不足之外（通常在制作 QCOW2 镜像时会安装好），相对地带来了下列诸多好处：

高性能：VirtIO 省去了 Full-virtualizaiton 模式下的 Traps（操作捕获）环节，GuestOS 通过 VirtIO Interfaces 可以直接与 Hypervisor 中的 Device Emulation 进行交互。

低开销：VirtIO 优化了 CPU 在内核态和用户态之间频繁切换，以及 CPU 在 VM Exit 和 VM Entry 之间频繁陷入陷出所带来的性能开销。

标准化：VirtIO 实现了统一的虚拟设备接口标准，可以应用在多种虚拟化解决方案中。

VirtIO 虚拟设备接口标准

为了抑制 Para-virtualizaiton 所具有的跨平台兼容性缺点，VirtIO 明智地走上了开源之路，通过构建标准而统一的生态来争取最小化的兼容性排斥问题，反而让其逆转成为了一种优势。

在 VirtIO 提出的虚拟化设备接口标准中，包括多个子系统，每个子系统都定义了一组虚拟设备类型和协议。例如：

VirtIO-Block（块设备）：提供虚拟磁盘设备的接口。

VirtIO-Net（网络设备）：提供虚拟网络设备的接口。

VirtIO-Serial（串口设备）：提供虚拟串口设备的接口。

VirtIO-Memory（内存设备）：提供虚拟内存设备的接口。

VirtIO-Input（输入设备）：提供虚拟输入设备的接口。

此外还有 VirtIO-SCSI、VirtIO-NVMe、VirtIO-GPU、VirtIO-FS、VirtIO-VSock 等等虚拟设备类型和协议。

VirtIO 的前后端分层架构

VirtIO 虚拟设备接口标准的分层软件架构如下图所示：

Front-end：是一组通用的，安装在 GuestOS Kernel 中的 VirtIO Device Driver，通过 Hyper-call 的方式对 Back-end 进行调用。

Back-end：是一组 Hypervisor 专用的，运行在 VMM 中的设备模拟程序，提供了 Hyper-call 调用接口。

Transport：是一组标准的传输层接口，基于环形队列的方式来批量处理 I/O 请求。 

VirtIO 的数控路径分离架构

VirtIO 还定义了 “控制路径” 和 “数据路径” 的分离架构，两者的侧重各有不同，控制平面追求尽可能的灵活以兼容不用的设备和厂商，而数据平面则追求更高的转发效率以快速的交换数据包。

控制路径：控制建立或删除 Front-end 和 Back-end 之间的数据路径，提供可管理的灵活性。

数据路径：在 Front-end 和 Back-end 之间进行数据传输，追求性能。

对应地，VirtIO 标准也可以分为两个部分：

VirtIO Spec：定义了如何在 Front-end 和 Back-end 之间构建控制路径和数据路径的标准，例如：数据路径规定采用环形队列缓冲区布局。

Vhost Protocol：定义了如何降数据路径的高性能实现标准，例如：基于 Kernel、DPDK、SmartNIC Offloading 的实现方式。

以 QEMU 为例，其根据 VirtIO Spec 实现了控制路径，而数据路径则可以 Bypass QEMU，使用 vhost-net、vhost-user 等实现。

VirtIO Networking

VirtIO Networking 是一种高功能、高性能、可扩展的虚拟化网络设备，支持多种网络功能和虚拟网络技术，并可以通过多种实现方式进行部署。

网络功能：MAC 地址、流量限制、流量过滤、多队列收发等；

虚拟网络技术：VLAN、GRE、VXLAN 等；

多种实现方式：Kernel、DPDK、硬件网卡等。

virtio-net Driver 和 virtio-net Device（由 QEMU 模拟的后端）

virtio-net 是 VirtIO Networking 的默认实现。其中，Front-end 是 virtio-net Driver（虚拟网卡驱动程序）；Back-end 是由 QEMU 软件模拟的 virtio-net Device。

QEMU 会在 VM 启动时，为 VM 创建好相应的 virtio-net Device（虚拟设备），并在 VM 启动后，通过在 GuestOS Kernel 中安装的 virtio-net Driver 来 Probe（探知）到该 virtio-net Device。

virtio-net Driver 和 virtio-net Device 的软件架构如下图所示，我们需要关注 3 个方面：

Control Plane：virtio-net Driver 和 virtio-net Device 之间使用了 PCI 传输协议，如下图中蓝线部分。

Data Plane：virtio-net Driver 和 virtio-net Device 之间使用了 Virtqueues 和 Vrings，如下图中红虚线部分。而 virtio-net Device 和 Kernel Network Stack 之间使用了 Tap 虚拟网卡设备，作为 User space（QEMU）和 Kernel space（Network Stack）之间的数据传输通道，如下图中红实线部分。

Notification：作为 virtio-net Driver、virtio-net Device 和 KVM 之间交互方式，用于实现 “vCPU 硬中断“ 的功能。

其中值得细究的就是 virtio-net Driver 和 virtio-net Device 之间的 Transport（传输层）实现。virtio-net Transport 采用了非常类似于物理网卡设备（NIC Rx/Tx Queues 和 Kernel Rx/Tx Rings）的设计思路。

Front-end 和 Back-end 之间存在 2 个 Virtqueues，对应到 NIC 的 Rx/Tx Queues。Virtqueues 的底层利用了 IPC 共享内存技术，在 HostOS 和 GuestOS 之间建立直接的传输通道，绕开了 VMM 的低效处理。

Receive Queue：是一块 Buffer 内存空间，存放具体的由 Back-end 发送到 Front-end 数据。

Send Queue：是一块 Buffer 内存空间，存放具体的由 Front-end 发送到 Back-end 数据。

同时，每个 Virtqueue 都具有 2 个 Vrings，对应到 Kernel 的 Rx/Tx Rings：

Available Ring：存放 Front-end 向 Back-end 发送的 Queue 中可用的 Buffer 内存地址。

Used Ring：存放 Back-end 向 Front-end 发送的 Queue 中已使用的 Buffer 内存地址。

当然，Front-end 和 Back-end 之间还需要一种双向通知机制，对应到 NIC 和 CPU 之间的硬中断信号：

Available Buffer Notification：Front-end 使用此信号通知 Back-end 存在待处理的缓冲区。

Used Buffer Notification：Back-end 使用此信号标志已完成处理某些缓冲区。

具体的，当 GuestOS 发送数据时，Front-end 将数据填充到 Send Queue 内存空间，然后将地址记录到 Available Ring，并在适当的时候向 Back-end 发送 Available Buffer Notification；QEMU 接收到通知后，从 Available Ring 中获取到数据的数据，完成数据接收，然后记录 New Buffer Head Index 到 Used Ring，并在适当的时候向 Front-end 发送一个 Used Buffer Notification。Front-end 接收到通知后释放对应的 Send Queue 内存空间，Available Ring 指针指向下一位。

当 GuestOS 接收数据时，Front-end 首先分配好 NULL 的 Receive Queue 内存空间，然后将地址记录到 Available Ring，并在适当的时候向 Back-end 发送 Available Buffer Notification；QEMU 接收到通知后，从 Available Ring 中获取到数据填充入口地址，完成数据填充，然后记录 New Buffer Head Index 到 Used Ring，并在适当的时候向 Front-end 发送一个 Used Buffer Notification。Front-end 接收到通知后从 Receive Queue 中读取数据，Available Ring 指针指向下一位。

值得注意的是，在 PCI Passthrough 场景中，可以使用 virtio-pci（更多的是使用 VFIO）。虽然此时依旧会沿用了 Available/Used buffer notification 这一控制面的双向通知机制，但实际的数据面，则是由 DMA 和专用队列来完成的，具有更高的性能。这体现了数控分离带来的好处。

综上所述，下述流程图总结了 2 个关键流程：

virtio-net Device 初始化流程：包括 Device discovery 和 Device configuration。对于 virtio-net Driver 而言，virtio-net Device 就是一个 PCI 设备，遵守标准的 PCI 设备初始化流程，并且 Driver 和 Device 使用 PCI 协议进行通信。

virtio-net Driver 发包流程：

当 virtio-net Driver 发送数据包时，将数据包放入 Send Queue，将数据包的访问地址放入 Available Ring，触发一次 Available Buffer Notification 到 KVM，然后 VM Exit，由 QEMU 接管 CPU，执行 I/O 控制逻辑，将此数据包传递到 virtio-net Device，然后 virtio-net Device 降数据包通过 Tap 设备传入 Kernel Network Stack；

完成后，QEMU 将 New Buffer Head Index 放入到 Used Ring 中，同时 virtio-net Device 发出一个 vIRQ 中断注入到 KVM，然后 KVM 发出一个 Used Buffer Notification 到 virtio-net Driver，此时 virtio-net Driver 就会从 Used Ring 中取出 Buffer Head Index；

至此一次发送操作就完成了。

另外，由于 Tap 设备支持 Tx/Rx 多队列，所以实际上也会存在 N 个 Virtqueues Peer 进行一一映射。

vhost-net（由 Kernel 提供的后端）

由 QEMU 模拟的 virtio-net Device 显然性能不佳，具有频繁的模式和上下文切换、低效的数据拷贝、线程间同步等性能问题。于是，VirtIO 社区在 Kernel 中实现了一个新的 vhost-net 后端，以解决上述问题。

更低的延迟（latency）：比普通 virtio-net 低 10%。

更高的吞吐量（throughput）：比普通 virtio-net 高 8 倍，达到 7～8 Gigabits/Sec。

vhost-net 的核心思想就是将 Data Path Bypass QEMU，定义了一种新的 Data Path 传输方式，使得 GuestOS virtio-net Driver 和 HostOS Kernel vhost-net 可以直接通信。如下图所示：

Control Plane：virtio-net Driver 和 virtio-net Device 之间使用了 PCI 传输协议，virtio-net Device 和 vhost-net 之间使用 ioctl() 接口，如下图中蓝线部分。

Data Plane：virtio-net Driver 和 vhost-net 直通，如下图中虚线部分。而 vhost-net 和 Kernel Network Stack 之间使用了 Tap 虚拟网卡设备连接，如下图中红实线部分。

Notification：作为 virtio-net Driver、vhost-net 和 KVM 之间交互方式，用于实现 “vCPU 硬中断“ 的功能。

vhost-net 的本质是一个 HostOS Kernel Module，实现了 vhost-net Protocol 标准，当 Kernel 加载 vhost-net 后，会暴露一个设备接口文件 /dev/vhost-net。

当 QEMU 在 vhost-net 模式下启动时，QEMU（virtio-net Device）首先会 open() 该文件，并通过 ioctl() 与 vhost-net 进行交互，继而完成 vhost-net 实例的 Setup（初始化）。初始化的核心是建立 virtio-net Driver 和 vhost-net 之间的 Data Path 以及 Notification，包括：

Hypervisor Memory Layout（虚拟化内存布局）：用于 Data Path 传输，让 vhost-net 可以在 KVM 的内存空间中找到特定 VM 的 Virtqueues 和 Vrings 的地址空间。

ioeventfd 和 irqfd（文件描述符）：用于 Notification 传输，让 vhost-net 和 KVM 之间可以在 Kernel space 中完成 Notification 的直接交互，不再需要通过 User space 中的 QEMU。

同时，在 vhost-net 实例初始化的过程中，vhost-net 会创建一个 Kernel Thread（vhost worker thread），名为 vhost-$pid（pid 是 QEMU 进程 PID），QEMU 进程就和 vhost-net 实例以此建立了联系。vhost worker thread 用于处理 I/O Event（异步 I/O 模式），包括：

使用 ioeventfd 轮询 Tap 事件和 Notify 事件，并转发数据。

使用 irqfd 允许 vhost-net/KVM 通过对其进行写入来将 vCPU 的 vIRQ 注入到 virtio-net Driver。

综上，在 vhost-net 实例初始化完成之后，virtio-net Device 将不再负责数据包的处理（对 Virtqueues 和 Vrings 的读/写操作），取而代之的是 vhost-net。vhost-net 可以直接访问 VM 的 Virtqueues 和 Vrings 内存空间，也可以通过 KVM 与 virtio-net Driver 进行 Notification 交互。

最后需要注意的是，vhost-net 在某些应用场景中的性能未必就会比 virtio-net Device 更好。例如：从 HostOS 传输到 GuestOS 的 UDP 流量，如果 GuestOS 接受 UDP 数据包的速度比 HostOS 发送的速度要慢，在这种情况下使用 vhost-net 将会导致 GuestOS UDP Socket Receive Buffer 更容易溢出，导致丢包，继而使得 GuestOS 的整体性能出现下降。此时使用慢速的 virtio-net，让 HostOS 和 GuestOS 之间的传输速度稍微慢一点，反而会提高整体的性能。

可见，在虚拟机场景中，全链路的性能均衡需要给予更加全面的考虑。

vhost-user（由 DPDK 实现的用户态后端）

vhost-user 是一个基于 DPDK vhost-user Library 开发的后端，运行在 User space，应用了 DPDK 所提供的 CPU 亲和性，大页内存，轮询模式驱动等数据面转发加速技术。

区别于 vhost-net Protocol，vhost-user Library 实现了一种新的 vhost-user Protocol，两者间最大的区别体现在通信信道的实现方式上。

vhost-net：使用 /dev/vhost-net 字符设备和 ioctl() 实现了 User Process（QEMU）和 Kernel（vhost-net）之间的 Control Plane 通信信道。

vhost-user：使用 Unix Socket 实现了 User Process（QEMU 和 DPDK App）之间的 Control Plane 通信信道。

QEMU 通过 Unix Socket 来完成对 vhost-user 的 Data Plane 配置，包括：

特性协商配置：QEMU（virtio-net Device）与 vhost-user 协商两者间功能特性的交集，确认哪些功能特性是有效的。

内存区域配置：vhost-user 使用 mmap() 来映射分配给 QEMU 的内存区域，建立两者间的直接数据传输通道。

Virtqueues/Vrings 配置：QEMU 将 Virtqueues/Vrings 的数量和访问地址发送给 vhost-user，以便 vhost-user 访问。

Notification 配置：vhost-user 仍然使用 ioeventfd 和 irqfd 来完成和 KVM 之间的通知交互。

目前最常见的 vhost-user DPDK App 就是 OVS-DPDK，除了支持 vhost-user Back-end 之外，还支持 virtio-pmd Front-end。在追求极致性能的 vhost-user / virtio-pmd 架构中，HostOS User space 和 GuestOS User space 都运行着 DPDK。

用户可以自由选择创建 vhost-user 类型的 vSwitch Port（对应一个 vhost-user 实例）。如下图所示。

HW vDPA（使用硬件加速的后端）

目前性能最好的 Data Plane 无疑是 SR-IOV VF Passthrough，但原生的 SR-IOV 缺少控制面逻辑，在实际使用中多有不便。

HW vDPA（Hardware vhost Data Path Acceleration，硬件 vhost 数据面加速）就是一种使用 SR-IOV VF 来充当 Data Plane、使用 vDPA Framework 来充当控制面的软硬件融合加速技术，能够同时兼具软件的可管理性、灵活性以及硬件的高性能。同时也解决了 VF Passthrough 虚拟机不支持热迁移的难题。

NOTE：SW vDPA（e.g. vDPA on OVS-DPDK）不在本文讨论范围中。

下图中展示了 OVS-DPDK 和 HW vDPA 的性能对比。

目前 vDPA Framework 的底层实现方式还尚未统一，从 QEMU 的角度来看，主要有 2 种方式：

适应性更好的 vhost-user + vDPA Driver：在 DPDK vhost-user Library 的基础之上，再实现一个 vDPA Driver 适配层。由 vDPA Driver 完成与 HW Device（e.g. SmartNIC、DPU）之间的交互。从下图中可以看到 QEMU 与 HW 的 Control Plane 通过 vDPA driver 进行传递，并配置好 HW 与 VM 之间的 Passthrough Data Plane。目前 Mellanox MLX5 和 Intel IFC 对应的 vDPA Driver 都已经合入到 DPDK 和 Kernel 社区。（注：IOMMU/VFIO 实现原理请浏览《虚拟化技术 — 硬件辅助的虚拟化技术》。）

架构更合理的 vhost-vdpa：实现一种新的 vhost-vdpa Protocol，QEMU 通过 ioctl() 调用 Kernel 中的 vDPA Module，再由 vDPA Module 通过 vDPA Driver 完成与 HW Device 之间的交互。

目前，随着 SmartNIC / DPU 的快速发展，一种结合了 SW vDPA 和 HW vDPA 特性的 HW vDPA on OVS-DPDK 方案也逐渐成熟中，其实现会更加复杂、但功能也更加完备。值得期待。

审核编辑：刘清