虚拟化篇之前后端驱动分析

前后端驱动是虚拟化的重要组成部分，在我们平时的排查过程中，经常会涉及到这部分的数据，特别是与性能相关的问题类型。举个例子，我们经常会碰到网络抖动的问题，此时我们会在实例内部和后端vif口抓包，如果发现两者之间存在延迟，经常我们就会怀疑到前后端的问题。因此我们需要对其工作原理和排查方法需要有一个全面的了解，其中也涉及到一些调试技巧，如为了确定问题是否与前后端队列有关，需要在实例系统的core dump内解析出内存中的队列数据。

何为前后端：

说到前后端就要提到virtIO，virtIO是IBM提出的实现虚拟机内部和宿主机之前数据交换的一种方式，与之前所谓全虚拟化方式比较即通过qemu在模拟设备的方式，性能有了较大的提升。我们在本文中仅局限于网卡设备，这也是因为在实例案例中网络部分占了主导地位。简单来讲，在virtIO体系中分为前端驱动和后端驱动两个部分，前端驱动我们一般可以理解为虚拟机内部的虚拟网卡的驱动，当然Windows和Linux的驱动是不同的，后端驱动virtIO是宿主机上的部分 的实现可能会有不同的方式，我们常见的是vhost-net，内核模式的vhost，至于其他模式如用户态vhost、qemu等等又有不同，但是本质的功能是类似的，就是将前端驱动发出的报文转发到NC虚拟交换机上，同理将收到的报文传入实例内的前端驱动。

上面这张图表示了前面驱动和后端驱动的关系。简单来讲前端驱动就是虚拟机内的虚拟网卡驱动，而后端驱动是主机上的vhost进程负责将报文转发出来，或者将物理机上接受到的报文转发进虚拟机。这两者其实就是负责了虚拟机内外的数据交换。

前后端之间如何交换数据

总的来说两者是通过vring、或者说virt queue即前后端环形队列进行数据交换。一共存在三个队列：

crash> struct vring
struct vring {
unsigned int num;
struct vring_desc *desc;
struct vring_avail *avail;
struct vring_used *used;
}

1. desc队列 - 放置了所有真正的报文数据。
2. avail队列与used队列 - 在发送报文的时候，前端驱动将报文在desc中的索引放在avail队列中，后端驱动从这个队列里获取报文进行转发，处理完之后将这些报文放入used队列。在接受报文的时候前端驱动将空白的内存块放入avail队列中（当然也只是报文在desc队列中的索引而已），后端接受报文将内容填充后，将这些含数据的报文放入used队列。

这三个队列都是固定长度的环形队列，当然实现仅仅是对相应索引号对最大长度去余而已。下面这张图形象地表明三个队列和前后端驱动的关系：

主要的数据结构

我们以前端的发送队列为例，注意所有的结构信息都是在虚拟机内部可见的，可以通过core dump查看：

struct vring_virtqueue {
vq = {
list = {
next = 0xffff881027e3d800,
prev = 0xffff881026d9b000
},
callback = 0xffffffffa0149450,
name = 0xffff881027e3ee88 "output.0", ->>表明是发送队列
vdev = 0xffff881023776800,
priv = 0xffff8810237d03c0
},
vring = {
num = 256, ->>所有的队列长度
desc = 0xffff881026d9c000, ->> desc队列
avail = 0xffff881026d9d000, ->> avail队列
used = 0xffff881026d9e000 ->> used队列
},
broken = false,
indirect = true,
event = true,
num_free = 0, ->> 队列目前有多少空闲元素了，如果已经为0表明队列已经阻塞，前端将无法发送报文给后端
free_head = 0, ->> 指向下一个空闲的desc元素
num_added = 0, ->>是最近一次操作向队列中添加报文的数量
last_used_idx = 52143, 这是前端记录他看到最新的被后端用过的索引(idx)，是前端已经处理到的used队列的idx。前端会把这个值写到avail队列的最后一个元素，这样后端就可以得知前端已经处理到used队列的哪一个元素了。

<> ->> last_avail_idx 前端不会碰，而且前端的virtqueue结构里就没有这个值，这个代表后端已经处理到avail队列的哪个元素了，前端靠这个信息来做限速，后端是把这个值写在used队列的最后一个元素，这样前端就可以读到了。

notify = 0xffffffffa005a350,
queue_index = 1,
data = 0xffff881026d9f078
}

crash> struct vring_avail 0xffff881026d9d000
struct vring_avail {
flags = 0,
idx = 52399, ->> avail队列的下个可用元素的索引
ring = 0xffff881026d9d004 ->> 队列数组
}

crash> struct vring_used
struct vring_used {
__u16 flags;
__u16 idx; ->> used队列的下个可用元素的索引
struct vring_used_elem ring[]; ->> 队列数组
}

报文发送的具体流程

相比接受，报文发送是我们处理案例中主要遇到问题的部分，所以我们将其流程单独拿出来详细分析一下。

主要以前端驱动（Linux版本）的行为为主，后端行为设计到阿里云源码实现暂不做分析，但是从前端行为基本可以判断后端的大致行为：

1. 保存head = vq->free_head。

2. 首先为报文分配desc，即报文的描述块，包含映射到内存的报文内容。

3. 判断队列的num_free是否小于要发送desc元素个数，如果是的话，说明队列已经阻塞了，后端驱动无法及时处理，所以此时需要通知（notify）后端驱动，前端通知后端的方法就是写入notification register寄存器。

4. 调整num_free减去已经分配的desc元素数量。

5. 调整free_head指向下一个空闲的desc元素。

6. 计算本次应该用avail ring中的哪个元素（即得出元素索引），avail队列是个环形数组，这里通过(vq->vring.avail->idx) & (vq->vring.num - 1)达到取余的目的。

7. 记录本次逻辑buf的起始desc索引号，即将根据刚才得出的元素索引找到相应在avail中的元素，将该元素的值指向本次分配desc的元素。这样处理之后avail队列中就已经包含了要处理的报文了（当然只是指向desc的索引而已）

8. 调整avail->idx指向了下一次操作使用avail队列的哪个元素。

9. 调整num_added记录增加了几个可用的avail ring元素。

10. 根据skb->xmit_more的值来决定是否"kick"即通知(notify)后端驱动。xmit_more值代表是否后续还有更多的报文需要发送，如果没有，前端驱动就会决定kick，如果有前端驱动会继续等待其他报文进入队列后再一起"kick"。

11. 在决定是否要notify后端驱动时，这里有一个限速逻辑：

    1. 首先提取used队列中最后一个元素，这是后端填入的信息，表示后端驱动处理到哪个avail队列的元素了，将值保存到event_idx。
    2. 记录上一次avail队列idx索引的值到old。
    3. 记录这一次报文进入队列之后avail队列idx索引的值到new_idx。

    4. 于是这里有一个公式来最后决定是否要notify后端驱动，即所谓的限速逻辑：

       (new_idx - event_idx - 1) <(new_idx - old)

用一张图来表示这个限速逻辑：

第一种情况，当前后端处理速度很快，前端应当notify后端驱动：

第二种情况，后端处理速度跟不上前端发送报文速度，暂时不要notify后端：

前端队列的状态分析

这里介绍的主要是通过core dump分析前端队列的方法，后端由于涉及到线上物理机，我们往往无法进行有效的分析。

Linux Core Dump

由于后端缺乏详尽的日志，我们往往需要依赖前端进行分析，而前后端队列的状态是在内核态，因此core dump是成了比较重要的分析手段了。以下介绍怎样通过Linux Core Dump对前后端队列进行分析：

首先通过net命令可以直接获取所有net_device的地址：

crash> net
NET_DEVICE NAME IP ADDRESS(ES)
ffff881028c66020 lo 127.0.0.1
ffff8810225f5020 eth0 172.20.1.13

获取其中的device地址：

crash> struct net_device ffff8810225f5020 -o | grep device
struct net_device {
[ffff8810225f50a0] struct net_device_stats stats;
[ffff8810225f5168] const struct net_device_ops *netdev_ops;
[ffff8810225f5198] struct net_device *master;
[ffff8810225f5408] struct net_device *link_watch_next;
[ffff8810225f5418] void (*destructor)(struct net_device *);
[ffff8810225f5450] struct device dev; --->> device地址

获取其中的parent指针：

crash> struct device ffff8810225f5450 | grep parent
parent = 0xffff881023776810,

将结果减去10就是virtio_device结构：

crash> struct virtio_device ffff881023776800 -o
struct virtio_device {
[ffff881023776800] int index;
[ffff881023776804] bool config_enabled;
[ffff881023776805] bool config_change_pending;
[ffff881023776808] spinlock_t config_lock;
[ffff881023776810] struct device dev;
[ffff881023776a30] struct virtio_device_id id;
[ffff881023776a38] struct virtio_config_ops *config;
[ffff881023776a40] struct list_head vqs; ----->> 所有队列的地址
[ffff881023776a50] unsigned long features[1];
[ffff881023776a58] void *priv;

列出所有队列的地址：

crash> list ffff881023776a40
ffff881023776a40
ffff881026d9b000 ->> input.0 接受队列
ffff881026d9f000 ->> output.0 发送队列
ffff881027e3d800 ->> control控制指令队列

我们一般比较多关注发送队列，因此挑选发送队列来看：

crash> struct vring_virtqueue ffff881026d9f000
struct vring_virtqueue {
vq = {
list = {
next = 0xffff881027e3d800,
prev = 0xffff881026d9b000
},
callback = 0xffffffffa0149450,
name = 0xffff881027e3ee88 "output.0",
vdev = 0xffff881023776800,
priv = 0xffff8810237d03c0
},
vring = {
num = 256,
desc = 0xffff881026d9c000,
avail = 0xffff881026d9d000,
used = 0xffff881026d9e000
},
broken = false,
indirect = true,
event = true,
num_free = 0, ----->> 表明队列已满
free_head = 0,
num_added = 0,
last_used_idx = 52143,
notify = 0xffffffffa005a350,
queue_index = 1,
data = 0xffff881026d9f078
}

当然还可以打出desc、avail和used每个数组的情况。