virtio-networking 5: 介绍 vDPA kernel framework

该文章于 2020 年 8 月 12 日发布，介绍了 2020 年 3 月合并到 Linux 内核的vDPA（virtio data path acceleration）内核框架，它是端到端 vDPA 解决方案产品化的核心，能让 NIC 厂商集成其 vDPA NIC 内核驱动；

文章先回顾 vDPA 概念（数据路径符合 virtio 规范、控制路径厂商特定
数据平面直接从客户机 / 容器化应用映射到物理 NIC 的 VF）
对比了 VM 与容器场景下控制平面 API 的差异，接着分析现有 vDPA DPDK（主机）框架的局限（依赖 DPDK 库、无法连接内核子系统、无 HW 配置控制工具）及被社区否决的 mdev 方案
阐述了 2020 年合并到 Linux 5.7 主线的独立 vDPA 内核框架的架构（隐藏硬件复杂度、提供统一接口，利用 vhost 和 virtio 子系统）、工作机制，
还说明了 vDPA 硬件驱动需实现的能力
最后提及后续将深入探讨该框架技术细节。

1. 引言与 vDPA 内核框架基础

文章发布于2020 年 8 月 12 日 ，聚焦于vDPA（virtio data path acceleration）内核框架 ，该框架于2020 年 3 月合并到 Linux 内核，是端到端 vDPA 解决方案产品化的关键支柱，其核心作用是让 NIC（网络接口控制器）厂商能够将自身的 vDPA NIC 内核驱动集成到该框架中，推进产品化进程。
本文是对 2019 年 10 月发布的《How deep does the vDPA rabbit hole go?》一文的重要更新，因 vDPA 最终设计发生了多项变更，后续还将总结两种方案在架构上的关键差异；同时，若需了解 vDPA 通用信息，可参考此前文章《Achieving network wirespeed in an open standard manner: introducing vDPA》。

正如之前的文章中所提及的，virtio 数据平面 会从客户机应用（guest application）直接映射到物理网卡（physical NIC）中的虚拟功能（VF，Virtual Function）。

下图展示了 vDPA 内核框架如何为主机上运行的容器（container），在网卡供应商控制平面（NIC vendor control plane）与 virtio 控制平面接口（virtio control plane interface）之间提供转换：

Figure: vDPA kernel framework translating between NIC and virtio

与虚拟机（VM）的情况类似，virtio 数据平面会从容器化应用（containerized application）直接映射到物理网卡（physical NIC）中的虚拟功能（VF，Virtual Function）。

对比虚拟机（VM）和容器（container）这两种使用场景下的控制平面可见：尽管二者均使用相同的 virtio-net-pmd 驱动，但该驱动用于控制操作的实际 API（应用程序编程接口）却有所不同：

在虚拟机（VM）使用场景中，由于 QEMU（一种虚拟化仿真工具）会向客户机（guest）暴露一个 virtio PCI 设备，因此 virtio-net-pmd 驱动会在控制平面上使用 PCI 命令，而 QEMU 会将这些命令转换为 vDPA 内核 API（系统调用）。
在容器（container）使用场景中，virtio-net-pmd 驱动会直接调用 vDPA 内核 API（系统调用）。

要么 QEMU 干活，要么内核干活，只要保证只有一个干活就是最搞笑的。

2. vDPA 概念回顾

2.1 核心定义

"vDPA 设备" 指数据路径（datapath）符合 virtio 规范，但控制路径（control path）为厂商特定的一类设备。

下图展示了 vDPA 内核框架如何为主机上运行的虚拟机（VM）在网卡（NIC）供应商控制平面与 virtio 控制平面接口之间提供转换：

Figure: vDPA kernel framework translating between NIC and virtio in a virtual machine

2.2 数据平面映射

无论是 VM（虚拟机）还是容器场景，virtio 数据平面均直接从对应的应用（客户机应用 / 容器化应用）映射到物理 NIC 的 VF（虚拟功能）上，保障数据传输效率。

2.3 VM 与容器场景控制平面 API 差异

场景	virtio-net-pmd 驱动控制平面 API 使用情况
VM 场景	QEMU 向客户机暴露 virtio PCI 设备，virtio-net-pmd 使用 PCI 命令，QEMU 将其转译为 vDPA 内核 API（系统调用）
容器场景	virtio-net-pmd 直接调用 vDPA 内核 API（系统调用）

3. 现有 vDPA 相关框架及问题

3.1 vDPA DPDK（主机）框架

基础情况：vDPA 在主机 DPDK 中通过标准 vhost-user 协议有基础支持，需区分主机 DPDK 部分（如 OVS-DPDK、其他 DPDK 守护进程）与客户机 DPDK（运行在客户机 / 容器中的 PMD 驱动）。
优势：QEMU 可借助该框架将 vDPA 硬件当作另一个 vhost-user 后端连接，目前主流 NIC 厂商已实现相关 vDPA DPDK（主机）驱动。
局限：
1. 支持该框架需依赖主机端的 DPDK 库，增加了额外依赖项。
2. vhost-user 仅提供用户空间 API，无法与内核子系统连接，导致 vDPA 接口的使用者会丢失 eBPF 等内核功能支持。
3. DPDK 聚焦数据路径，未提供硬件配置和控制的工具，该问题也存在于 vDPA DPDK 框架中。

3.2 mdev 方案

基础：此前在《How deep does the vDPA rabbit hole go?》中提出基于 mdev 的内核 vDPA 框架方案，mdev 是 VFIO mediator 设备框架，用于在厂商特定命令与模拟 PCI 设备间进行转换。
结局：经上游社区讨论后，该方案被否决，转而开发独立于 VFIO 的子系统。
否决原因：
1. VFIO 和 mdev 提供的是低级别的设备抽象，而 vDPA 基于 virtio，提供高级别的设备抽象，将高级 API 引入 VFIO 并非合理方式。
2. 行业内开发的部分 NIC 设备与 VFIO IOMMU 模型契合度低，难以基于该方案支持 vDPA。

4. vDPA 内核框架架构

4.1 核心目标

隐藏 vDPA 硬件实现的复杂性，为内核和用户空间子系统提供安全且统一的访问接口。

4.2 支持的硬件实现形式

vDPA 的硬件实现形式多样，包括：

PCI 相关：物理功能（PF）、虚拟功能（VF）、厂商特定的 PF 切片（如子功能 SF）。
非 PCI 设备。
软件模拟设备。
且不同设备可能有各自的厂商特定接口和 DMA 模型，进一步增加了硬件复杂性。

如下图所示，vDPA 框架对 vDPA 硬件的通用属性进行抽象，并利用现有的 vhost 和 virtio 子系统：

Figure: vDPA framework overview

4.3 依赖的关键子系统

子系统	作用
vhost 子系统	内核内 virtio 的历史数据路径实现，用于在主机端模拟 virtio 设备的数据路径；暴露成熟的用户空间 API，通过 vhost 设备（字符设备）搭建内核数据路径；已有多种后端支持不同类型 vDPA 设备（如网络、SCSI），vDPA 内核框架借助其 API 工作
virtio 子系统	历史 virtio 内核驱动框架，用于将客户机 / 进程与 virtio 设备连接，曾用于在客户机端控制模拟的 virtio 设备；支持特殊场景（如 XDP）下，主机内核同时运行 virtio 设备和 virtio 驱动，使得依赖 vDPA（通过 vhost 子系统）和不依赖 vDPA（通过 virtio 子系统）的应用可在同一物理 vDPA NIC 上运行

4.4 关键特性

热迁移支持：通过现有 vhost API 实现设备状态的保存与恢复，满足热迁移需求。
可扩展性：易于扩展以支持硬件级脏页跟踪，或由用户空间驱动实现软件辅助脏页跟踪；相较于 IOMMU 等其他内核子系统，更易扩展支持 SVA（Shared Virtual Address）和 PASID（Process Address Space ID）等技术。
安全性：仅允许门铃寄存器（用于通知硬件执行任务）直接进行硬件寄存器映射；需在主机与客户机间的用户空间设置设备中介层（如 QEMU），相比 SR-IOV 中使用的设备透传方式，减少了来自通用寄存器的攻击面。
适配新技术：更契合 Scalable IOV、子功能（SF）等新设备切片技术，这些技术同样需要软件中介层。

5. vDPA 内核框架工作机制

5.1 对用户空间驱动

vDPA 框架会呈现一个 vhost 字符设备，用户空间 vhost 驱动可将 vDPA 设备当作 vhost 设备进行控制。典型应用场景为 QEMU 连接 vDPA 设备，将其作为 vhost 后端，供客户机内运行的 virtio 驱动使用。

5.2 对内核 virtio 驱动

vDPA 框架会呈现一个 virtio 设备，内核 virtio 驱动可将 vDPA 设备当作标准 virtio 设备进行控制，各类内核子系统可与 virtio 设备连接，供用户空间应用使用。

5.3 中断与性能保障

框架会将 vDPA 硬件产生的中断转发给用户空间 vhost 驱动和内核 virtio 驱动。
支持门铃和中断透传，以实现设备的原生性能。

6. vDPA 硬件驱动要求

vDPA 内核框架旨在简化硬件 vDPA 驱动程序的开发与集成。下图对此进行了说明：

6.1 核心实现能力

vDPA 框架抽象了 vDPA 设备的通用属性和配置操作，因此典型的 vDPA 驱动需实现以下能力：

设备探测 / 移除：执行厂商特定的设备探测和移除流程。
中断处理：进行厂商或平台特定的中断分配与处理。
vDPA 设备抽象：实现 vDPA 框架所需的函数，其中大部分是 virtio 控制命令与厂商特定设备接口的转换，并将 vDPA 设备注册到框架中。
DMA 操作：对于具备自身 DMA 转换逻辑的设备，可要求框架将 DMA 映射传递给驱动，以实现厂商特定的 DMA 转换。

6.2 驱动特点

由于数据路径已卸载到 vDPA 硬件，硬件 vDPA 驱动变得精简且易于实现。用户空间 vhost 驱动或内核 virtio 驱动会通过 vhost ioctl（输入输出控制）或 virtio 总线命令（取决于所选子系统）控制和搭建硬件数据路径，vDPA 框架再将 virtio/vhost 命令转发给硬件 vDPA 驱动，由驱动以厂商特定方式执行命令。

7. 后续内容规划

后续文章将深入探讨 vDPA 框架的技术细节，包括 vDPA 总线、与 QEMU / 容器的集成、支持带有 / 不带有 IOMMU 的硬件等内容，展示框架底层的实际工作原理。

四、关键问题

问题 1：vDPA 内核框架相较于之前的 vDPA DPDK（主机）框架，主要解决了哪些关键问题？

答案

vDPA 内核框架主要解决了 vDPA DPDK（主机）框架的三大关键问题：

依赖问题：vDPA DPDK（主机）框架需依赖主机端的 DPDK 库，增加了额外的依赖项；而 vDPA 内核框架无需依赖 DPDK 等额外库，降低了使用门槛。
内核功能丢失问题：vDPA DPDK（主机）框架基于 vhost-user 协议，仅提供用户空间 API，无法与内核子系统连接，导致使用者丢失 eBPF 等内核功能；vDPA 内核框架可与内核子系统（如网络、块设备子系统）连接，保障了内核功能的正常使用。
硬件管理工具缺失问题：DPDK 聚焦数据路径，vDPA DPDK（主机）框架未提供硬件配置和控制的工具；vDPA 内核框架可集成 sysfs、netlink 等标准 API，能更好地支持硬件的配置与控制。

问题 2：vDPA 内核框架为何选择开发独立于 VFIO 的子系统，而非采用此前基于 mdev 的方案？

答案

vDPA 内核框架放弃基于 mdev 的方案、选择开发独立于 VFIO 的子系统，主要基于两点原因：

设备抽象层级不匹配：VFIO 和 mdev 提供的是低级别设备抽象，主要用于处理与硬件底层相关的命令转换（如厂商特定命令与模拟 PCI 设备间的转换）；而 vDPA 基于 virtio 规范，提供的是高级别设备抽象，核心关注数据路径符合 virtio 标准、控制路径厂商特定。将高级 API 引入以低级别抽象为核心的 VFIO 体系中，不符合技术设计的自然逻辑。
硬件兼容性问题：行业内部分 NIC 设备的设计与 VFIO IOMMU（输入输出内存管理单元）模型契合度较低，若基于 mdev 方案（依赖 VFIO）实现 vDPA 支持，会面临极大的技术挑战，难以兼容这类 NIC 设备；而独立子系统可摆脱 VFIO IOMMU 模型的限制，更好地适配各类 NIC 设备。

问题 3：在 vDPA 内核框架架构中，vhost 子系统和 virtio 子系统分别扮演什么角色，二者如何配合支持 vDPA 功能？

答案

vhost 子系统的角色

vhost 子系统是内核内 virtio 的历史数据路径实现，主要作用是在主机端模拟 virtio 设备的数据路径。它暴露成熟的用户空间 API，通过 vhost 设备（字符设备）帮助搭建内核数据路径，且已有多种后端支持网络、SCSI 等不同类型的 vDPA 设备。vDPA 内核框架借助其 API，让用户空间驱动（如 QEMU）可将 vDPA 设备当作 vhost 设备控制，实现用户空间对 vDPA 硬件的访问。

virtio 子系统的角色

virtio 子系统是历史 virtio 内核驱动框架，核心作用是将客户机 / 进程与 virtio 设备连接，最初用于在客户机端控制模拟的 virtio 设备。它支持特殊场景（如 XDP），允许主机内核同时运行 virtio 设备和 virtio 驱动，使得不依赖 vDPA 的应用可通过该子系统在物理 vDPA NIC 上运行。

二者配合方式

vhost 子系统面向用户空间驱动，提供 vDPA 设备的用户空间访问接口；virtio 子系统面向内核驱动，提供 vDPA 设备的内核访问接口。通过这种分工，vDPA 内核框架实现了对用户空间和内核空间的全面覆盖，使得依赖 vDPA（通过 vhost 子系统）和不依赖 vDPA（通过 virtio 子系统）的应用，可在同一物理 vDPA NIC 上同时运行，充分发挥 vDPA 硬件的能力。

参考：

www.redhat.com/en/blog/int...