ARM平台下DPDK Virtio PMD使用的驱动绑定与架构相关技术疑问

为什么要将QEMU模拟的virtio-net从内核virtio-pci解绑、绑定到VFIO-PCI驱动 #

• 核心本质来自DPDK的运行模式：DPDK的PMD驱动完全运行在用户态，需要绕过内核网络栈、直接操作设备的寄存器、中断、DMA内存资源，所有被内核态驱动占用的PCI设备，DPDK都无法直接接管。
• 常规场景下内核virtio-pci驱动会持有这个virtio-net设备的所有操作权，负责处理virtqueue的调度、中断响应、数据包收发逻辑，用户态进程无法直接访问设备的MMIO BAR空间，因此必须先把设备从原有内核驱动上解绑。
• 这里需要纠正一个常见认知偏差：VFIO并不是专门用于向客户机透传物理设备的框架，很多人刚接触时会把设备直通当成VFIO的唯一用途，这是对其设计定位的窄化理解——VFIO的核心目标是提供一套安全、通用的用户态设备访问机制，“设备直通给客户机”只是它的典型应用场景之一。
• 绑定到VFIO-PCI驱动后，内核会通过/dev/vfio/下的受控接口，把这个virtio-net设备的配置空间、MMIO寄存器地址、中断资源的访问权限开放给指定的用户态进程。尤其在ARM平台上，VFIO会对接系统的SMMU完成DMA地址映射与权限隔离，为DPDK用户态直接操作设备扫清权限障碍。

VFIO在DPDK virtio-PMD场景下的实际工作逻辑 #

• 整个工作链路和VFIO用于物理设备直通的底层逻辑是完全一致的，和设备本身是物理硬件还是QEMU模拟的虚拟设备没有关系：
  • 第一步由VFIO模块接管目标PCI设备的资源控制权，内核不再通过原有驱动处理设备的业务逻辑
  • 第二步通过IOMMU/SMMU完成用户态大页内存和设备DMA地址的映射，保证用户态申请的内存是设备可直接访问的，同时隔离非法DMA操作避免破坏系统稳定性
  • 第三步将设备的BAR空间、中断资源映射到DPDK进程的用户态地址空间，让virtio-PMD可以直接在用户态读写virtio配置空间、操作virtqueue的描述符环，全程不需要陷入内核态处理收发逻辑
• 要严格区分两个容易混淆的VFIO使用场景：
  • 常规的设备直通场景：把主机上的物理PCI设备绑定到VFIO后，由QEMU把设备透传给客户操作系统使用
  • 当前DPDK的使用场景：virtio-net本身就是QEMU为客户机模拟的虚拟PCI设备，绑定VFIO的动作发生在客户机内部，目的是让客户机内运行的DPDK进程，获得对这个虚拟设备的直接用户态访问权限，完全不需要经过客户机内核的virtio-pci驱动做中转。

使用virtio-PMD是否必须配置vhost-net #

• 明确结论：vhost-net不是virtio-PMD运行的必需依赖，两者在virtio半虚拟化架构中分属不同层级的组件，没有强绑定关系。
• 先理清vhost-net的架构位置与作用：
  • virtio是典型的前后端分离半虚拟化架构，前端是设备驱动（运行在客户机内，不管是内核的virtio-pci还是用户态的virtio-PMD），后端是负责实际数据包收发的实体（运行在宿主机侧）
  • vhost-net是宿主机内核态的virtio-net加速后端模块，最初的设计目的是解决传统QEMU用户态后端的性能损耗：原始路径下，客户机触发virtqueue事件后需要多次完成上下文切换到QEMU用户态，由QEMU完成客户机内存到宿主机网络栈的数据包拷贝，vhost-net把这部分后端处理逻辑搬到宿主机内核态，直接映射客户机内存读写virtqueue，绕过QEMU的用户态拷贝环节，大幅降低收发延迟。
• 不同场景下vhost-net的适配关系：
  • 当客户机内使用内核态virtio-pci驱动时，宿主机侧通常会搭配vhost-net作为后端加速，这是最常见的virtio-net高性能配置
  • 当客户机内使用DPDK virtio-PMD时，如果宿主机侧仍使用vhost-net作为后端，是可以正常工作的，但这属于可选的后端搭配，不是virtio-PMD运行的强制要求——你也可以选择不加载vhost-net，用传统的用户态tap后端对接，只是整体收发性能会有明显下降
  • 如果DPDK运行在宿主机侧、对接客户机的virtio设备，此时更常使用DPDK实现的vhost-user用户态后端，整个路径完全不涉及内核态的vhost-net模块，vhost-net在这类场景下完全不需要配置。

内容的提问来源于stack exchange，提问作者Milan