virtio_net与vhost协议feature过程

最新推荐文章于 2024-05-27 17:15:04 发布
最新推荐文章于 2024-05-27 17:15:04 发布
阅读量252 收藏 1
点赞数 2
分类专栏： 虚拟化 文章标签： linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_44376670/article/details/138077284
版权

本文以vhost_user后端为例进行描述，kernel的vhost_net与vhost_user类似，只是在qemu中注册了不同接口而已。
参考链接，本文是对下面文章的总结。
http://blog.chinaunix.net/uid-28541347-id-5787244.html

协商核心：协商的目的是为了对guest的virtio_net设备与后端的vhost_user之间协商共同支持的feature集合，以最终确定整个流程中启用的最终feature集合，
但qemu-kvm架构中，guest与vhost_user(一般是ovs-dpdk进程)是不直接通信的，所以他们之间的feature需要一个中间人，即：qemu模块。

协商涉及4个核心模块： guest:virtio_net《》qemu:virtio_net代理《》qemu:vhost_user《====》dpdk:vhost_user

QEMU源码全解析 —— virtio（27）
phmatthaus的专栏
03-06 813
QEMU源码全解析 —— virtio（27）
virtio协议1.0 -- 网络设备
六六哥的博客
10-12 2626
引子 virtio network device 是一种虚拟以太网卡 迄今为止virtio支持的最复杂的设备（其他设备可挖掘的内容很多） 空缓冲区被提前放置在RX virtqueue中用于接收数据包，收包一个队列 发送的数据包被排队到TX virtqueue中以便按该顺序传输，发送一个队列 控制队列用于控制和高级过滤功能 Device ID 1 Virtqueues 队列分布布局 如果VIRTIO_NET_F_MQ 没有协商，N = 1 如果VIRTIO_NET_F_MQ 协商了，..
virtio网络Data Plane卸载原理 —— vhost协议协商流程
Take Easy，Work Hard！
07-09 2879
本文主要分析vhost协议前后端协商流程
深入分析vhost-user网卡实现原理 —— VirtIO Features协商
Take Easy，Work Hard！
10-04 4540
本文深入分析vhost-user网卡实现原理，由于features在各数据结构中多有出现惹人疑惑，因此主要解释在vhost-user网卡生命周期内各个features的作用
virtio network驱动分析
majieyue的专栏
05-10 1万+
本文以virtio网络驱动为例，分析virtio驱动是如何处理网络IO的，驱动的定义如下 static struct virtio_device_id id_table[] = { { VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID }, { 0 }, }; static unsigned int features[] = { VIRTIO_NET_F
virtio-net的前后端分析
weixin_48329334的博客
05-27 1146
注：MSI-X表放在一个单独一个BAR空间中，设置为non-prefetchable，因为里面的pending为是读清的操作，不可以设置为prefetchable（从目前的BSC卡的实现来看，由于virtio设备用不到msix的pending，因此可以设置为prefetchable）。其他的virtio配置寄存器放在另外一个BAR空间中，设置为prefetchable，在一些pcie的硬件架构下，可以提高访问的性能。驱动通过读写CommonCfg中的feature相关的字段来协商特性。
ovs+dpdk，前后端feature协商过程
zheng的博客
07-29 728
1、qemu与vhost_user建立sock通信 vhost_user_start （qemu） vhost_dev_init vhost_user_get_features （VHOST_USER_GET_FEATURES） vhost_user_get_features（获取dpdk端的feature） rte_...
浅析virtio技术（2）virtio设备管理
Aspiresky的专栏
07-23 2248
virtio协议定义了virtio通信遵循的接口，包含设备状态、设备支持的特性以及前后端数据传输的通道（virtqueue）。目前在使用的virtio规范有三个版本0.95、1.0和1.1。0.95版本是目前广泛在使用的版本，称为传统模式；1.0版本中协议将设备的配置部分做了一些调整，被称为现代模式；1.1版本则主要是新增了packedvirtqueue的支持。本文重点关注于virtio设备相关的规范定义。...
【Linux4.1.12源码分析】virtio_net之中断注册
one_clouder的专栏
11-22 3342
virtio_net作为虚拟网卡驱动，最主要的就是实现网路报文收发，对比物理网卡，当收到网络报文时会产生中断，由中断处理函数接收网络报文，这一点可以类比到virtio_net。实际上，virtio_net设备的中断注册是在驱动的probe函数中完成的。 virtnet_probe函数 static int virtnet_probe(struct virtio_device *vdev)
【Linux4.1.12源码分析】virtio_net之NAPI机制
one_clouder的专栏
11-24 2140
在虚拟化场景，中断的开销更大，所以要尽可能的少用中断，我们从中断处理函数开始看。 skb_recv_done函数 static void skb_recv_done(struct virtqueue *rvq) { struct virtnet_info *vi = rvq->vdev->priv; struct receive_queue *rq = &vi->rq[vq2rxq(r
virtio协议1.0 -- 基础组件
六六哥的博客
09-28 1622
这里描述符的是virito的通用基础组件，不依赖于总线类型，如PCI,MMIO, Channel IO 等 0. virtio基本基础组件 Device status 域 Feature bits Device Configuration space 一个或多个 virtqueues 1.Device status 域 驱动在发现和加载设备过程中，会经历一系列加载步骤，device status 就是在底层提示加载步骤的完成状态，底层设备通过这些状态值，知道需要完成的事情 状态 ACKN.
DPDK18.08上对VIRTIO IN ORDER 功能所做的优化
lingshengxiyou的博客
09-03 376
作为对应的实现，18.08中virtio user pmd中加入了两个新的收发函数：virtio_recv_mergeable_pkts_inorder和virtio_xmit_pkts_inorder。还有一个是in_order用来配置VIRTIO_F_IN_ORDERfeature，默认配置也是打开。所以现在如果在dpdk生成一个virtio虚拟设备，它的默认参数会是“queues=1，queue_size=256，server=0,mrg_rxbuf=1，in_order=1”。
qemu前后端features协商过程分析（vhost_user后端）
hzj_001的博客
06-29 2601
约定： 1)协商过程涉及的核心是：dpdk(ovs)vhost_user，qemu:vhost_user，qemu:virtio_net，guest virtio_net，共4个模块，每个模块都有自己的feature； 2)由于整个协商是自后端到前端，再由前端到后端的，即dpdk(dvs)->qemu->gues...
virtio一个KVM虚拟环境下针对I/O虚拟化通用框架
IT小小鸟
06-07 3393
virtio一个KVM虚拟环境下针对I/O虚拟化通用框架 摘要：virtio 是 KVM 虚拟环境下针对 I/O 虚拟化的最主要的一个通用框架。virtio 提供了一套有效、易维护、易开发、易扩展的中间层 API。本文主要介绍一下相关的基本概念和实现机制，还有 virtio 设备的操作过程
virtio-net 实现机制
10-08 9073
virtio 前端驱动详解
网络虚拟化——virtio
热门推荐
dillanzhou的博客
09-28 1万+
前言 在上一篇文章（网络虚拟化——QEMU虚拟网卡）中，讨论了经典的网络设备全虚拟化技术。这种技术不需要guest内核对虚拟网络设备有任何的感知和特殊处理，但性能较差，一次读写操作可能会产生多次需要Hypervisor模拟实现的行为。 为了改善虚拟网络设备的性能，各类Hypervisor都提供了自己的半虚拟化网络技术。在这种模式下，guest内核中使用的网络设备和驱动是为虚拟化场景特殊设计和实现的，驱动的实现特别适配了Hypervisor的一些特性，尽量减少了需要Hypervisor介入进行模拟实现的指
VIRTIO0.95与1.1控制面协议简析
leiyanjie8995的博客
01-14 3891
virtio最初的设计目的就是在guest和host之间建立一个通道，达到更高效的数据传输。传统的模拟io的方式，guest可以不感知，称为全虚拟化，但是guest每次向设备写入数据都需要做一次VM-exit，效率极低；virtio称为半虚拟化的方式，guest是会感知的，因为他需要专门的内核驱动（前端VIRTIO驱动），而不是原本的网卡驱动。 在guest侧，virtio模拟的设备显示出来是virtio-net/virtio-blk这样的设备类型。 所以本质上，VIRTIO就是一种协议，目的就是令
DPDK系列之十二：基于virtio、vhost和OVS-DPDK的容器数据通道
cloudvtech的博客
06-09 7580
一、前言
virtio的理解和guest中的virtio-blk分析
jason的笔记
04-13 7314
virtio 有分为guest 中的前端程序和qemu中的后端程序 virtio中的五种前端程序为 virtio-blk:/drivers/block/virtio-blk.c virtio-net:/drivers/net/virtio-net.c virtio-pci:/drivers/virtio/virtio-pci.c virtio-ballon:/drivers/virtio
static const struct { int valid; enum virtio_ib_qp_attr_mask req_param[VIRTIO_IB_QPT_UD + 1]; enum virtio_ib_qp_attr_mask opt_param[VIRTIO_IB_QPT_UD + 1]; } qp_state_table[VIRTIO_IB_QPS_ERR + 1][VIRTIO_IB_QPS_ERR + 1] = { [VIRTIO_IB_QPS_RESET] = { [VIRTIO_IB_QPS_RESET] = { .valid = 1 }, [VIRTIO_IB_QPS_INIT] = { .valid = 1, .req_param = { [VIRTIO_IB_QPT_UD] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_UC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_RC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_SMI] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_GSI] = VIRTIO_IB_QP_QKEY, } }, }, [VIRTIO_IB_QPS_INIT] = { [VIRTIO_IB_QPS_RESET] = { .valid = 1 }, [VIRTIO_IB_QPS_ERR] = { .valid = 1 }, [VIRTIO_IB_QPS_INIT] = { .valid = 1, .opt_param = { [VIRTIO_IB_QPT_UD] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_UC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_RC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_SMI] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_GSI] = VIRTIO_IB_QP_QKEY, } }, [VIRTIO_IB_QPS_RTR] = { .valid = 1, .req_param = { [VIRTIO_IB_QPT_UC] = (VIRTIO_IB_QP_AV | VIRTIO_IB_QP_PATH_MTU | VIRTIO_IB_QP_DEST_QPN | VIRTIO_IB_QP_RQ_PSN), [VIRTIO_IB_QPT_RC] = (VIRTIO_IB_QP_AV | VIRTIO_IB_QP_PATH_MTU | VIRTIO_IB_QP_DEST_QPN | VIRTIO_IB_QP_RQ_PSN | VIRTIO_IB_QP_MAX_DEST_RD_ATOMIC | VIRTIO_IB_QP_MIN_RNR_TIMER), }, .opt_param = { [VIRTIO_IB_QPT_UD] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_UC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_RC] = VIRTIO_IB_QP_ACCESS_FLAGS, [VIRTIO_IB_QPT_SMI] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_GSI] = VIRTIO_IB_QP_QKEY, }, }, }, [VIRTIO_IB_QPS_RTR] = { [VIRTIO_IB_QPS_RESET] = { .valid = 1 }, [VIRTIO_IB_QPS_ERR] = { .valid = 1 }, [VIRTIO_IB_QPS_RTS] = { .valid = 1, .req_param = { [VIRTIO_IB_QPT_UD] = VIRTIO_IB_QP_SQ_PSN, [VIRTIO_IB_QPT_UC] = VIRTIO_IB_QP_SQ_PSN, [VIRTIO_IB_QPT_RC] = (VIRTIO_IB_QP_TIMEOUT | VIRTIO_IB_QP_RETRY_CNT | VIRTIO_IB_QP_RNR_RETRY | VIRTIO_IB_QP_SQ_PSN | VIRTIO_IB_QP_MAX_QP_RD_ATOMIC), [VIRTIO_IB_QPT_SMI] = VIRTIO_IB_QP_SQ_PSN, [VIRTIO_IB_QPT_GSI] = VIRTIO_IB_QP_SQ_PSN, }, .opt_param = { [VIRTIO_IB_QPT_UD] = (VIRTIO_IB_QP_CUR_STATE | VIRTIO_IB_QP_QKEY), [VIRTIO_IB_QPT_UC] = (VIRTIO_IB_QP_CUR_STATE | VIRTIO_IB_QP_ACCESS_FLAGS), [VIRTIO_IB_QPT_RC] = (VIRTIO_IB_QP_CUR_STATE | VIRTIO_IB_QP_ACCESS_FLAGS | VIRTIO_IB_QP_MIN_RNR_TIMER), [VIRTIO_IB_QPT_SMI] = (VIRTIO_IB_QP_CUR_STATE | VIRTIO_IB_QP_QKEY), [VIRTIO_IB_QPT_GSI] = (VIRTIO_IB_QP_CUR_STATE | VIRTIO_IB_QP_QKEY), } } },
最新发布
04-09
<think>嗯，我现在需要解释用户提供的这个C语言结构体。看起来这是一个关于虚拟化InfiniBand队列对（QP）状态转换的表格。首先，我得理解这个结构体的各个部分。 首先，结构体是static const的，说明它是静态且不可修改的。内部有三个成员：valid、req_param和opt_param，它们都是数组。外层是一个二维数组qp_state_table，索引是两个状态，可能代表从当前状态到目标状态的转换规则。 接下来，枚举类型如enum virtio_ib_qp_attr_mask可能表示不同的QP属性掩码，用于标识必需或可选的参数。数组的维度是[VIRTIO_IB_QPS_ERR + 1][VIRTIO_IB_QPS_ERR + 1]，说明状态包括RESET、INIT、RTR、RTS、ERR等，每个状态之间的转换都有对应的规则。 然后，初始化部分。例如，当从RESET状态转换到INIT状态时，req_param数组根据不同的QP类型（UD、UC、RC等）设置不同的必需参数。比如UD类型的QP需要QKEY，而UC和RC需要访问权限标志。 在状态转换到RTR时，req_param可能包括地址向量（AV）、路径MTU、目标QP号等。而opt_param可能包含一些可选参数，比如访问标志或QKEY。 当从RTR转换到RTS时，必需参数可能包括SQ_PSN，对于RC类型还有超时、重试计数等。可选参数可能包含当前状态和一些其他标志。 我需要确保解释清楚每个状态转换的条件，以及不同QP类型所需的参数。同时，要说明valid字段的作用，可能表示该状态转换是否有效。例如，从RESET到INIT有效，而从RESET到其他状态可能无效。 可能还需要提到，这种表格用于验证QP状态转换时的参数是否符合规范，确保驱动程序在修改QP状态时提供必要的参数，避免错误。 需要注意的是，VIRTIO_IB_QPT_UD等是QP类型，而VIRTIO_IB_QP_QKEY等是属性掩码，使用位或操作组合。这表示在设置QP属性时，可能需要同时满足多个条件。 用户可能想知道这个结构体在代码中的作用，以及如何被使用。比如，当尝试将QP从当前状态转换到目标状态时，系统会检查该表格，确认valid是否为1，并检查req_param和opt_param是否满足。 可能存在一些错误处理，比如无效的状态转换会导致错误码返回，或者触发异常处理流程。 总结来说，这个结构体是一个状态机表格，管理不同QP类型在不同状态转换时的参数要求，确保状态转换的合法性。</think>以下是对该数据结构的详细分步解释： ### 一、结构体定义分析 ```c static const struct { int valid; // 状态转换有效性标志 enum virtio_ib_qp_attr_mask req_param[VIRTIO_IB_QPT_UD + 1]; // 必需参数掩码 enum virtio_ib_qp_attr_mask opt_param[VIRTIO_IB_QPT_UD + 1]; // 可选参数掩码 } qp_state_table[VIRTIO_IB_QPS_ERR + 1][VIRTIO_IB_QPS_ERR + 1] = { ... }; ``` #### 关键要素 1. **二维状态转换表** - 第一维表示当前QP状态 - 第二维表示目标QP状态 - 索引范围：`[VIRTIO_IB_QPS_RESET]`到`[VIRTIO_IB_QPS_ERR]` 2. **成员说明** | 成员 | 说明 | |------------|----------------------------------------------------------------------| | `valid` | 值为1表示允许此状态转换 | | `req_param`| 按QP类型存储必须提供的参数（位掩码） | | `opt_param`| 按QP类型存储可选提供的参数（位掩码） | ### 二、状态转换规则 #### 1. RESET状态转换规则 ```c [VIRTIO_IB_QPS_RESET] = { [VIRTIO_IB_QPS_RESET] = { .valid = 1 }, // 允许保持RESET状态 [VIRTIO_IB_QPS_INIT] = { .valid = 1, .req_param = { // 不同类型QP的必须参数 [VIRTIO_IB_QPT_UD] = VIRTIO_IB_QP_QKEY, [VIRTIO_IB_QPT_UC] = VIRTIO_IB_QP_ACCESS_FLAGS, ... } } } ``` - **典型场景**：当QP从RESET切换到INIT状态时 - **UD类型QP**必须提供：$QKEY$ - **UC/RC类型QP**必须提供：$访问权限标志$ #### 2. INIT状态转换规则 ```c [VIRTIO_IB_QPS_INIT] = { [VIRTIO_IB_QPS_RTR] = { .valid = 1, .req_param = { // RC类型需要5个必要参数 [VIRTIO_IB_QPT_RC] = VIRTIO_IB_QP_AV | VIRTIO_IB_QP_PATH_MTU | ... } } } ``` - **RC类型QP**需要： $$ \text{AV} \ | \ \text{Path MTU} \ | \ \text{Dest QPN} \ | \ \text{RQ PSN} \ | \ \cdots $$ #### 3. RTR→RTS转换规则 ```c [VIRTIO_IB_QPS_RTR] = { [VIRTIO_IB_QPS_RTS] = { .req_param = { [VIRTIO_IB_QPT_RC] = VIRTIO_IB_QP_TIMEOUT | VIRTIO_IB_QP_RETRY_CNT | ... } } } ``` - **RC类型QP**进入RTS状态必须提供： $$ \text{Timeout} \ | \ \text{Retry Count} \ | \ \text{RNR Retry} \ | \ \cdots $$ ### 三、设计特点分析 1. **类型敏感参数要求** 通过`[VIRTIO_IB_QPT_UD]`等索引区分不同传输类型的参数需求 2. **位掩码组合** 使用`|`运算符组合多个参数要求，例如： $$ \text{VIRTIO\_IB\_QP\_AV} \ | \ \text{VIRTIO\_IB\_QP\_PATH\_MTU} $$ 3. **状态机完整性** 包含`[VIRTIO_IB_QPS_ERR]`处理，确保错误状态可恢复 ### 四、典型应用场景 1. **QP修改操作验证** 驱动程序调用`ib_modify_qp()`时，内核通过此表： - 检查`valid`字段 - 验证是否提供了所有`req_param` - 处理`opt_param` 2. **协议兼容性保证** 确保不同virtio后端实现遵循相同的状态转换规则 该数据结构体现了InfiniBand规范中QP状态机的严格管理要求，通过编译期确定的常量数据，实现了高效的状态转换验证。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值