Cloud Hypervisor VFIO-user 设备接入指南socket 化的用户态 PCI 设备与热插拔实践【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisorVFIO-user 是一种实验性协议它允许 PCI 设备在独立进程中实现并通过 Unix socket 与虚拟机监控器通信——类比来说VFIO-user 之于 VFIO正如 vhost-user 之于 virtio。本文基于 Cloud Hypervisor 官方文档docs/vfio-user.md结合仓库源码vmm/src/config.rs、vmm/src/device_manager.rs、cloud-hypervisor/src/bin/ch-remote.rs完整讲解--user-device参数的配置语法、GPIO 与 NVMe 两个真实设备示例以及热插拔与已知限制读完即可在本地复现两种 vfio-user 设备接入场景。VFIO-user 与 Cloud Hypervisor 的支持现状VFIO-user 协议允许设备实现者把 PCI 设备的配置空间、MMIO BAR 与 DMA 全部封装进另一个用户态进程中VMM 只需连接该进程暴露的 socket 即可把设备挂到 guest 的 PCI 总线上。这样做的好处是设备模型与 VMM 完全解耦设备可以独立开发、独立部署甚至可以复用 SPDK 等成熟生态中已有的设备实现。Cloud Hypervisor 对这一协议的支持目前仍是实验性的且存在明确的功能边界不支持 virtio-mem内存热插拔类设备无法以 vfio-user 形式接入不支持 iommu源码中UserDeviceConfig::validate()会直接对设置了iommu的配置返回ValidationError::IommuNotSupported见 vmm/src/config.rs。这意味着 vfio-user 设备目前适用于直通式、无 IOMMU 隔离场景的 PCI 外设模拟如 GPIO、NVMe 控制器、网络控制器等。使用方法创建时挂载与运行中热插拔vfio-user 设备有两条接入路径VM 创建时静态挂载使用启动参数--user-device socketpath运行中热插拔使用ch-remote add-user-device socketpath通过 HTTP APIPUT /vm.add-user-device动态加入该端点定义见 vmm/src/api/http/mod.rs对应 OpenAPI 定义见 vmm/src/api/openapi/cloud-hypervisor.yaml。参数完整语法与源码解析--user-device在 CLI 定义中支持重复出现num_args(1..)ArgAction::Append见 cloud-hypervisor/src/main.rs即一个 VM 可以挂载多个 vfio-user 设备。其完整语法在源码中声明为见 vmm/src/config.rs--user-device socketsocket_path,iddevice_id,pci_segmentsegment_id,pci_device_idpci_slot各字段含义与约束如下参数是否必选说明socket必选vfio-user 设备进程监听的 Unix socket 路径。缺失时parse()会返回ParseUserDeviceSocketMissing错误vmm/src/config.rsid可选设备标识符用于后续设备管理与去重校验validate_identifier保证 id 全局唯一见 vmm/src/config.rspci_segment可选设备所在 PCI 段号pci_device_id可选设备在 PCI 总线上的槽位号BDF 中的 device 号其中id、pci_segment、pci_device_id是PciDeviceCommonConfig的通用 PCI 选项见 vmm/src/config.rs。内存要求必须共享内存使用 vfio-user 设备时guest 内存必须开启共享。源码校验逻辑为只要配置了 user devices 且内存未开启共享就返回ValidationError::UserDevicesRequireSharedMemory见 vmm/src/config.rs。原因在于 vfio-user 设备进程需要通过共享内存直接访问 guest 物理内存以完成 DMA 读写。因此无论哪个示例启动参数都必须包含--memory size1G,sharedon示例一接入 libvfio-user 的 GPIO 设备libvfio-user 仓库自带一个简单的 GPIO 设备示例gpio-pci-idio-16适合作为第一个上手实验它演示了 vfio-user 的最小闭环——设备进程监听 socket、VMM 连接、guest 内驱动访问。第 1 步运行设备进程rm /tmp/vfio-user.sock ./build/dbg/samples/gpio-pci-idio-16 -v /tmp/vfio-user.sock 先删除可能残留的旧 socket 文件再以 verbose 模式把 GPIO 设备进程挂在/tmp/vfio-user.sock上。第 2 步启动 Cloud Hypervisortarget/debug/cloud-hypervisor \ --memory size1G,sharedon \ --disk path~/images/focal-server-cloudimg-amd64.raw,image_typeraw \ --kernel ~/src/linux/vmlinux \ --cmdline root/dev/vda1 consolehvc0 \ --user-device socket/tmp/vfio-user.sock注意--memory必须带sharedon原因见上文--user-device的 socket 路径要与设备进程的监听路径完全一致。第 3 步在 guest 内验证设备启动后guest 内核会枚举到该 GPIO 控制器gpiochip480。导出并读取引脚状态cat /sys/class/gpio/gpiochip480/base /sys/class/gpio/export for ((i0;i12;i)); do cat /sys/class/gpio/OUT0/value; done第一条命令把 GPIO 控制器的基础编号写入 export 导出设备循环依次读取 12 路输出OUT0的当前电平值验证 guest 与用户态设备进程之间的 MMIO/DMA 通路是否正常工作。示例二用 SPDK 提供 NVMe 控制器SPDKStorage Performance Development Kit原生支持 vfio-user可以把一个 AIO 块设备封装成 NVMe 控制器暴露给 Cloud Hypervisor从而为 guest 提供一块基于用户态 NVMe 协议的磁盘。这是 vfio-user 在真实存储场景中最典型的用法。第 1 步编译带 vfio-user 支持的 SPDK./configure --with-vfio-user第 2 步准备后端块设备并启动 NVMe-oF targetsudo scripts/setup.sh rm ~/images/test-disk.raw truncate ~/images/test-disk.raw -s 128M mkfs.ext4 ~/images/test-disk.raw sudo killall ./build/bin/nvmf_tgt sudo ./build/bin/nvmf_tgt -i 0 -e 0xFFFF -m 0x1 sleep 2 sudo ./scripts/rpc.py nvmf_create_transport -t VFIOUSER sudo rm -rf /tmp/nvme-vfio-user sudo mkdir -p /tmp/nvme-vfio-user sudo ./scripts/rpc.py bdev_aio_create ~/images/test-disk.raw test 512 sudo ./scripts/rpc.py nvmf_create_subsystem nqn.2019-07.io.spdk:cnode -a -s test sudo ./scripts/rpc.py nvmf_subsystem_add_ns nqn.2019-07.io.spdk:cnode test sudo ./scripts/rpc.py nvmf_subsystem_add_listener nqn.2019-07.io.spdk:cnode -t VFIOUSER -a /tmp/nvme-vfio-user -s 0 sudo chown $USER.$USER -R /tmp/nvme-vfio-user这段脚本逐步完成创建 128M 的 raw 测试盘并格式化为 ext4 → 以指定 CPU 亲和性启动nvmf_tgt→ 创建 VFIOUSER 传输类型 → 用 AIO 后端把测试盘注册为名为test的 bdev → 创建 NVMe 子系统并添加命名空间 → 在/tmp/nvme-vfio-user目录上添加 VFIOUSER 监听器 → 最后把 socket 目录的所有权还给当前用户否则 Cloud Hypervisor 进程无法连接。监听器最终会生成/tmp/nvme-vfio-user/cntrl这个控制 socket。第 3 步启动 Cloud Hypervisortarget/debug/cloud-hypervisor \ --memory size1G,sharedon \ --disk path~/images/focal-server-cloudimg-amd64.raw,image_typeraw \ --kernel ~/src/linux/vmlinux \ --cmdline root/dev/vda1 consolehvc0 \ --user-device socket/tmp/nvme-vfio-user/cntrlguest 内会枚举出一块 NVMe 磁盘通常为/dev/nvme0n1可正常分区、格式化与读写。SPDK bdev 的更多配置选项与 NVMe-oF target 的详细设置分别对应 SPDK 官方文档中的 bdev 与 nvmf 两节可按需查阅。运行机制与源码级补充说明设备添加流程VM 启动时DeviceManager::add_user_devices()会遍历配置中的所有UserDeviceConfig逐个调用add_vfio_user_device()创建设备见 vmm/src/device_manager.rs。设备以 PCI 设备形式挂到总线上因此同样受id唯一性与 PCI 资源分配约束。socket 冲突检查热插拔时若目标 socket 已被某设备占用会返回DeviceManagerError::UserDeviceSocketInUse避免同一 socket 被重复使用见 vmm/src/device_manager.rs。测试覆盖仓库集成测试中包含对add-user-device热插拔路径的验证见 cloud-hypervisor/tests/integration.rs可作为复现与排查问题的参考。已知限制与注意事项实验性特性协议与 Cloud Hypervisor 侧实现均处于实验阶段API 与行为可能随版本演进变化不支持 iommu配置中不得设置iommu选项否则启动校验直接失败不支持 virtio-mem内存热插拔类场景无法使用 vfio-user 设备必须sharedon缺少共享内存配置将导致启动校验失败socket 生命周期必须先启动设备进程并确保 socket 就绪再启动 Cloud Hypervisor清理环境时需先删除残留 socket 文件。总结通过--user-device与ch-remote add-user-deviceCloud Hypervisor 可以在创建 VM 时或运行中以热插拔方式接入基于 vfio-user 协议的用户态 PCI 设备。本文给出的 GPIO 示例用于验证最小通路SPDK NVMe 示例则展示了如何将成熟的用户态存储栈以 NVMe 控制器形式接入 guest。若希望在项目中使用该特性请先对照本文的已知限制评估适用性并确保使用支持sharedon的共享内存配置。【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloud Hypervisor VFIO-user 设备接入指南：socket 化的用户态 PCI 设备与热插拔实践
Cloud Hypervisor VFIO-user 设备接入指南socket 化的用户态 PCI 设备与热插拔实践【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisorVFIO-user 是一种实验性协议它允许 PCI 设备在独立进程中实现并通过 Unix socket 与虚拟机监控器通信——类比来说VFIO-user 之于 VFIO正如 vhost-user 之于 virtio。本文基于 Cloud Hypervisor 官方文档docs/vfio-user.md结合仓库源码vmm/src/config.rs、vmm/src/device_manager.rs、cloud-hypervisor/src/bin/ch-remote.rs完整讲解--user-device参数的配置语法、GPIO 与 NVMe 两个真实设备示例以及热插拔与已知限制读完即可在本地复现两种 vfio-user 设备接入场景。VFIO-user 与 Cloud Hypervisor 的支持现状VFIO-user 协议允许设备实现者把 PCI 设备的配置空间、MMIO BAR 与 DMA 全部封装进另一个用户态进程中VMM 只需连接该进程暴露的 socket 即可把设备挂到 guest 的 PCI 总线上。这样做的好处是设备模型与 VMM 完全解耦设备可以独立开发、独立部署甚至可以复用 SPDK 等成熟生态中已有的设备实现。Cloud Hypervisor 对这一协议的支持目前仍是实验性的且存在明确的功能边界不支持 virtio-mem内存热插拔类设备无法以 vfio-user 形式接入不支持 iommu源码中UserDeviceConfig::validate()会直接对设置了iommu的配置返回ValidationError::IommuNotSupported见 vmm/src/config.rs。这意味着 vfio-user 设备目前适用于直通式、无 IOMMU 隔离场景的 PCI 外设模拟如 GPIO、NVMe 控制器、网络控制器等。使用方法创建时挂载与运行中热插拔vfio-user 设备有两条接入路径VM 创建时静态挂载使用启动参数--user-device socketpath运行中热插拔使用ch-remote add-user-device socketpath通过 HTTP APIPUT /vm.add-user-device动态加入该端点定义见 vmm/src/api/http/mod.rs对应 OpenAPI 定义见 vmm/src/api/openapi/cloud-hypervisor.yaml。参数完整语法与源码解析--user-device在 CLI 定义中支持重复出现num_args(1..)ArgAction::Append见 cloud-hypervisor/src/main.rs即一个 VM 可以挂载多个 vfio-user 设备。其完整语法在源码中声明为见 vmm/src/config.rs--user-device socketsocket_path,iddevice_id,pci_segmentsegment_id,pci_device_idpci_slot各字段含义与约束如下参数是否必选说明socket必选vfio-user 设备进程监听的 Unix socket 路径。缺失时parse()会返回ParseUserDeviceSocketMissing错误vmm/src/config.rsid可选设备标识符用于后续设备管理与去重校验validate_identifier保证 id 全局唯一见 vmm/src/config.rspci_segment可选设备所在 PCI 段号pci_device_id可选设备在 PCI 总线上的槽位号BDF 中的 device 号其中id、pci_segment、pci_device_id是PciDeviceCommonConfig的通用 PCI 选项见 vmm/src/config.rs。内存要求必须共享内存使用 vfio-user 设备时guest 内存必须开启共享。源码校验逻辑为只要配置了 user devices 且内存未开启共享就返回ValidationError::UserDevicesRequireSharedMemory见 vmm/src/config.rs。原因在于 vfio-user 设备进程需要通过共享内存直接访问 guest 物理内存以完成 DMA 读写。因此无论哪个示例启动参数都必须包含--memory size1G,sharedon示例一接入 libvfio-user 的 GPIO 设备libvfio-user 仓库自带一个简单的 GPIO 设备示例gpio-pci-idio-16适合作为第一个上手实验它演示了 vfio-user 的最小闭环——设备进程监听 socket、VMM 连接、guest 内驱动访问。第 1 步运行设备进程rm /tmp/vfio-user.sock ./build/dbg/samples/gpio-pci-idio-16 -v /tmp/vfio-user.sock 先删除可能残留的旧 socket 文件再以 verbose 模式把 GPIO 设备进程挂在/tmp/vfio-user.sock上。第 2 步启动 Cloud Hypervisortarget/debug/cloud-hypervisor \ --memory size1G,sharedon \ --disk path~/images/focal-server-cloudimg-amd64.raw,image_typeraw \ --kernel ~/src/linux/vmlinux \ --cmdline root/dev/vda1 consolehvc0 \ --user-device socket/tmp/vfio-user.sock注意--memory必须带sharedon原因见上文--user-device的 socket 路径要与设备进程的监听路径完全一致。第 3 步在 guest 内验证设备启动后guest 内核会枚举到该 GPIO 控制器gpiochip480。导出并读取引脚状态cat /sys/class/gpio/gpiochip480/base /sys/class/gpio/export for ((i0;i12;i)); do cat /sys/class/gpio/OUT0/value; done第一条命令把 GPIO 控制器的基础编号写入 export 导出设备循环依次读取 12 路输出OUT0的当前电平值验证 guest 与用户态设备进程之间的 MMIO/DMA 通路是否正常工作。示例二用 SPDK 提供 NVMe 控制器SPDKStorage Performance Development Kit原生支持 vfio-user可以把一个 AIO 块设备封装成 NVMe 控制器暴露给 Cloud Hypervisor从而为 guest 提供一块基于用户态 NVMe 协议的磁盘。这是 vfio-user 在真实存储场景中最典型的用法。第 1 步编译带 vfio-user 支持的 SPDK./configure --with-vfio-user第 2 步准备后端块设备并启动 NVMe-oF targetsudo scripts/setup.sh rm ~/images/test-disk.raw truncate ~/images/test-disk.raw -s 128M mkfs.ext4 ~/images/test-disk.raw sudo killall ./build/bin/nvmf_tgt sudo ./build/bin/nvmf_tgt -i 0 -e 0xFFFF -m 0x1 sleep 2 sudo ./scripts/rpc.py nvmf_create_transport -t VFIOUSER sudo rm -rf /tmp/nvme-vfio-user sudo mkdir -p /tmp/nvme-vfio-user sudo ./scripts/rpc.py bdev_aio_create ~/images/test-disk.raw test 512 sudo ./scripts/rpc.py nvmf_create_subsystem nqn.2019-07.io.spdk:cnode -a -s test sudo ./scripts/rpc.py nvmf_subsystem_add_ns nqn.2019-07.io.spdk:cnode test sudo ./scripts/rpc.py nvmf_subsystem_add_listener nqn.2019-07.io.spdk:cnode -t VFIOUSER -a /tmp/nvme-vfio-user -s 0 sudo chown $USER.$USER -R /tmp/nvme-vfio-user这段脚本逐步完成创建 128M 的 raw 测试盘并格式化为 ext4 → 以指定 CPU 亲和性启动nvmf_tgt→ 创建 VFIOUSER 传输类型 → 用 AIO 后端把测试盘注册为名为test的 bdev → 创建 NVMe 子系统并添加命名空间 → 在/tmp/nvme-vfio-user目录上添加 VFIOUSER 监听器 → 最后把 socket 目录的所有权还给当前用户否则 Cloud Hypervisor 进程无法连接。监听器最终会生成/tmp/nvme-vfio-user/cntrl这个控制 socket。第 3 步启动 Cloud Hypervisortarget/debug/cloud-hypervisor \ --memory size1G,sharedon \ --disk path~/images/focal-server-cloudimg-amd64.raw,image_typeraw \ --kernel ~/src/linux/vmlinux \ --cmdline root/dev/vda1 consolehvc0 \ --user-device socket/tmp/nvme-vfio-user/cntrlguest 内会枚举出一块 NVMe 磁盘通常为/dev/nvme0n1可正常分区、格式化与读写。SPDK bdev 的更多配置选项与 NVMe-oF target 的详细设置分别对应 SPDK 官方文档中的 bdev 与 nvmf 两节可按需查阅。运行机制与源码级补充说明设备添加流程VM 启动时DeviceManager::add_user_devices()会遍历配置中的所有UserDeviceConfig逐个调用add_vfio_user_device()创建设备见 vmm/src/device_manager.rs。设备以 PCI 设备形式挂到总线上因此同样受id唯一性与 PCI 资源分配约束。socket 冲突检查热插拔时若目标 socket 已被某设备占用会返回DeviceManagerError::UserDeviceSocketInUse避免同一 socket 被重复使用见 vmm/src/device_manager.rs。测试覆盖仓库集成测试中包含对add-user-device热插拔路径的验证见 cloud-hypervisor/tests/integration.rs可作为复现与排查问题的参考。已知限制与注意事项实验性特性协议与 Cloud Hypervisor 侧实现均处于实验阶段API 与行为可能随版本演进变化不支持 iommu配置中不得设置iommu选项否则启动校验直接失败不支持 virtio-mem内存热插拔类场景无法使用 vfio-user 设备必须sharedon缺少共享内存配置将导致启动校验失败socket 生命周期必须先启动设备进程并确保 socket 就绪再启动 Cloud Hypervisor清理环境时需先删除残留 socket 文件。总结通过--user-device与ch-remote add-user-deviceCloud Hypervisor 可以在创建 VM 时或运行中以热插拔方式接入基于 vfio-user 协议的用户态 PCI 设备。本文给出的 GPIO 示例用于验证最小通路SPDK NVMe 示例则展示了如何将成熟的用户态存储栈以 NVMe 控制器形式接入 guest。若希望在项目中使用该特性请先对照本文的已知限制评估适用性并确保使用支持sharedon的共享内存配置。【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考