descriptor ring#

是一个descriptor的环形数组，其中descriptors是一个数据结构，描述一个data buffer

• addr: guest的物理地址(GPA)
• len: data buffer的长度
• flags: 有NEXT,WRITE,INDIRECT等
  • NEXT: 在下一个描述符中还有更多的相关数据
  • WRITE: 这个buffer是不是只写的（设备可写的）
  • INDIRECT: 这个buffer包含这一个间接描述符表
• next: desc.ring中的下一个描述符

当设置了NEXT标志位的时候，表示当前描述符的指向的数据缓冲区的数据的内容，将在next中的数据缓冲区中继续。当一个或多个描述符之间以这样的方式链接这的时候，通常称作descriptor chaining。并且对于descriptor chain来说，他们可以是由全部只读或者全部只写的描述符构成的

只有驱动程序可以向descriptor ring添加描述符，而设备仅当描述符的标志位表明该缓冲区可写，才能向设备可写的缓冲区中写入数据。

一个缓冲区只能是只读或者只写的，不可能同时具有两种属性。

在一个descriptor ring中，一个buffer的GPA和长度不能不能于其他的内存范围相互重叠。而在ring中，索引靠后的描述符指向的内存地址，并不一定就比前面的描述符指向的地址更高

available ring#

是一个指向描述符的循环数组。即available ring中的每个条目都指向一个descriptor ring中的描述符（或描述符链的头）

• flags: 参数标志位
• idx: 下一个可用的avail ring条目的索引
• ring[]: 实际的available ring数组

其中，flags字段表示avail ring的配置及其部分操作。index字段表示可用环中下一个可用的条目，驱动程序将在此放入对descriptor（或描述符链的头）的下一个引用。ring字段表示实际的avail ring数组，驱动程序将descriptor ring的引用存储在这里。

只有驱动程序才会配置并向available ring添加一条条目，而只有对应设备只能从中读取。

当在最开始的时候，在驱动程序向available ring添加第一条条目之前，available ring，没有任何的flag,也没有任何的条目，idx会被配置为0，因为对于这个available ring来说，下一个可用条目的索引就是0

used ring#

类似于available ring，但是它是一个指向descripto ring中已经使用的descriptor的数组（即设备已经写入或读取了一个描述符的数据缓冲区）

• flags: 参数标志位
• idx: used ring中下一个可用的条目的索引
• ring[]: 实际的used ring数组（是一个pair的结构体）
  • id: 当前这个元素在descriptor ring中的索引
  • len: 向descriptor的buffer中写入的数据的长度

与available ring正好相反，只有设备可以配置并且向used ring中添加条目，而对应的驱动程序可以读它

命令virtqueue#

如前文提到的，qemu中的virqueue结构体有一个用来处理输出的回调函数字段，叫做VirtIOHandleOutput handle_output。在virtio-SCSI的命令virtqueue中，这个回调函数字段会指向一个virtio_scsi_handle_cmd()函数

1
static void virtio_scsi_device_realize(DeviceState *dev, Error **errp) {
2
    VirtIODevice *vdev = VIRTIO_DEVICE(dev);
3
    VirtIOSCSI *s = VIRTIO_SCSI(dev);
4
    Error *err = NULL;
5

6
    virtio_scsi_common_realize(dev, virtio_scsi_handle_ctrl, virtio_scsi_handle_event, virtio_scsi_handle_cmd, &err);
7
    // ...
8
}

1
VirtQueue *virtio_add_queue(VirtIODevice *vdev, int queue_size, VirtIOHandleOutput handle_output) {
2
    // ...
3
    vdev->vq[i].vring.num = queue_size;
4
    vdev->vq[i].vring.num_default = queue_size;
5
    vdev->vq[i].vring.align = VIRTIO_PCI_VRING_ALIGN;
6
    vdev->vq[i].handle_output = handle_output;
7
    vdev->vq[i].used_elems = g_malloc0(sizeof(VirtQueueElemen) * queue_size);
8
    return &vdev->vq[i];
9
}

virtqueue的输出处理函数的调用方式取决于具体的virtio设备以及该virtqueue在设备中的角色。在virtio-SCSI的命令virtqueue的情况下，当一个virtio-SCSI驱动程序向qemu发送一个通知，告诉qemu去通知对应的设备在available vring上有一个SCSI命令数据准备就绪需要处理的时候，该virtqueue的输出处理函数就会被调用。

• 一个virtio设备直到对其对应的virtio驱动程序完成以下操作后，才会参与到vring的操作中
  1. 向descriptor ring中添加了新的描述符
  2. 把对这个新的描述符的引用添加到了available ring中
  3. 通知设备available ring已经准备就绪，等待处理

换句话说，当执行到了virtio_scsi_handle_cmd()函数的时候，意味着virtio-SCSI设备已经从它的驱动程序处收到了通知，并且开始准备处理它的命令virtqueue的available ring中的数据了。

virtio_scsi_handle_cmd()函数就基本上是一个对于virtio_scsi_handle_cmd_vq()函数的封装

1
bool virtio_scsi_handle_cmd_vq(VirtIOSCSI *s, VirtQueue *vq) {
2
    VirtIOSCSIReq *req, *next;
3
    int ret = 0;
4
    bool suppress_notifications = virtio_queue_get_notification(vq);
5
    bool progress = false;
6

7
    QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs);
8

9
    do {
10
        if (suppress_notifications) {
11
            virtio_queue_set_notification(vq, 0);
12
        }
13
        while ((req = virtio_scsi_pop_req(s, vq))) {
14
            progress = true;
15
            ret = virtio_scsi_handle_cmd_req_prepare(s, req);
16
            if (!ret) {
17
                QTAILQ_INSERT_TAIL(&reqs, req, next);
18
            } else if (ret == -EINVAL) {
19
                /* th device is broken and shouldn't process any request */
20
                while (!QTAILQ_EMPTY(&reqs)) {
21
                    // ....
22
                }
23
            }
24
        }
25
        if (supress_notifications) {
26
            virtio_queue_set_notification(vq, 1);
27
        }
28
    } while (ret != -EINVAL && !virtio_queue_empty(vq));
29

30
    QTAILQ_FOREACH_SAFE(req, &reqs, next, next) {
31
        virtio_scsi_handle_cmd_req_submit(s, req);
32
    }
33
    return progress
34
}

这个函数告诉了我们virtio-SCSI的命令virtqueue将如何处理它的available ring上的数据

在接下来的场景中，首先回顾一下，已经协商了VIRTIO_VRING_F_EVENT_IDX功能位。对于设备而言，这意味着只有当used ring中的idx等于available ring中的idx的时候，才会通知驱动程序。

换句话来说，如果驱动程序在available ring上添加了20条条目，索引从0到19，则available ring的idx在添加完最后一条条目(ring[19])之后将变为20。在设备处理完了available ring中的最后一条条目(ring[19])并且把它放到了对应的used ring中后，used ring的idx也将变为20。这时候，几乎立刻在添加完最后一条条目到used ring中后，设备要立刻通知它对应的驱动程序。

回到virtio_scsi_handle_cmd_vq()。

在函数开始的时候，一个virtio-SCSI请求(VirtIOSCSIReq)的队列reqs，被初始化了

1
QTAILQ_HEAD(, VirtIOSCSIReq) reqs = QTAILQ_HEAD_INITIALIZER(reqs);

对于virtio-SCSI的命令virtqueue，它的available ring上的每一个条目都被转变成了一个VirtIOSCSIReq对象并被添加到reqs队列的末尾。

在开始读取avaialble ring之前，首先要抑制设备向驱动程序发送的通知，毕竟设置了VIRTIO_VRING_F_EVENT_IDX。接下来，进入到第二个while循环\while ((req = virtio_scsi_pop_req(s, vq)))。在这个while循环里面，我们遍历available ring，并对每一个条目，都把它转变为一个VirtIOSCSIReq对象并添加到了reqs队列的尾部

在读取完了能够从available ring中读取的所有内容后，便会重新启用通知，以便设备在处理完请求并将其放入used ring中后，能够通知驱动程序有已经处理了的数据。需要注意的是，这里仅仅是启用了通知，并没有发送通知。在我们的场景下(VIRTIO_VRING_F_EVENT_IDX)，这仅仅是做好了准备，一旦我们将所有已处理请求的数据都放入used ring后，就可以通知设备

在提交请求之前，可以看到我们仍然在do-while循环中，只有当设备出问题或者我们没有在available ring中留有未读数据的时候才会退出循环。这是为了防止在我们读完了available ring中的最后一条条目后又有新的数据添加了进来

现在设备已经读完了它在available ring中可以督导的所有数据并把每一条条目都添加到了它自己的VirtIOSCSIReq对象中，我们接下来就遍历reqs并一条一条的把请求提交给真正的SCSI硬件设备去处理。

一旦一个请求被host上的SCSI设备完成，将会去执行virtio_scsi_command_complete()，然后是virtio_scsi_complet_cmd_req()，最后到virtio_scsi_complete_req()。其中比较有趣的函数是virtio_scsi_complete_req()，因为这个函数是设备把使用了的数据放入used ring中的地方。

1
static void virtio_scsi_complete_req(VirtIOSCSIReq *req) {
2
    VirtIOSCSI *s = req->dev;
3
    VirtQueue *vq = req->vq;
4
    VirtIODevice *vdev = VIRTIO_DEVICE(s);
5

6
    qemu_iovec_from_buf(&req->resp_iov, 0, &req->resp, req->resp_size);
7
    /* Push used request data onto used ring */
8
    virtqueue_push(vq, &req->elem, req->qsgl.size + req->resp_iov.size);
9
    /* Determin if we need to notify the driver */
10
    if (s->dataplane_started && !s->dataplane_fenced) {
11
        virtio_notify_irqfd(vdev, vq);
12
    } else {
13
        virtio_notify(vdev, vq);
14
    }
15

16
    if (req->sreq) {
17
        req->sreq->hba_private = NULL;
18
        scsi_req_unref(req->sreq);
19
    }
20
    virtio_scsi_free_req(req);
21
}

为了完成一个请求，virtio-SCSI设备必须通过把处理了的数据放到used_ring上(virtqueue_push())来使驱动程序能够访问这些数据。需要注意的是，真正的数据现在已经被写入了描述符的buffer中。我们现在做的是告诉驱动程序去去descriptor ring的哪里去寻找，以及（如果有）我们向它的data buffer中写了多少数据。

Guest=>Host transmit path#

• virtio-net驱动程序把数据放入virtio-net Tx VirtQueue中
• virtio-net驱动程序向doorbel register执行写操作，告诉host(KVM)去唤醒virtio-net设备
  • VM-Exit(Guest->Host Kernel): 向doorbell register执行写操作导致CPU退出guest模式，陷入KVM并进入到host kernel中
• KVM拦截消息并知道了virtio-net设备(qemu中)需要被唤醒
• KVM转发这这一唤醒消息给qemu这样virtio-net设备就可以处理新的Tx virtqueue中的数据
  • 上下文切换(Host kernel->userspace): 唤醒Qemu意味着CPU需要切换上下文到Qemu进程(在用户态中)
• virtio-net设备从virtio-net Tx virtqueue中读取数据
• Qemu通过一个系统调用，把数据复制到host内核中的网络栈中
  • 这是一种内核态与用户态之间的环级切换，而非上下文切换——CPU现在仍然在Qemu的执行上下文中，只是在执行内核代码
• TAP/物理网卡把这个包发送到网络中
  • VM-Entry(Host->Guest): host执行结束后就返回到Guest中

Host=>Guest receive path#

• TAP/物理网卡从网络中收到了数据
• TAP/物理网卡把数据追加到host内核网络协议栈并通过一个文件描述符通知qemu
  • 上下文切换(Host Kernel=>Userspace): 当数据准备好了，内核唤醒Qemu并且CPU上下文切换到Qemu所在的用户态进程
• Qemu使用一个系统调用(e.g.,read()/recvmsg())来把数据从TAP设备中复制出来
• Qemu把数据写入到virtio-net的Rx virtqueue中
• Qemu发出一个系统调用(ioctl())给KVM，请求给Guest注入一个中断
  • 这是一个环级切换，不是一个上下文切换——CPU现在仍然Qemu的执行上下文中，只是在执行内核的代码（为了处理中断）
• KVM手动给guest注入一个中断，通知其virtio-net的Rx virtqueue中有新的数据
  • VM-Exit(Guest=>Host Kernel): 如果客户机保持活跃（一般来说都是的），那么CPU需要短暂退出客户机模式，注入中断
  • VM-Entry(Host Kernel=>Guest): 在给guest注入完中断后，KVM导致CPU回到Guest模式（恢复到guest的vCPU的上下文）
• virtio-net驱动程序接收到中断并被告知有新的数据在virtio-net的Rx virtqueue中
• virtio-net驱动程序从Rx virtqueue中读取数据并把它递交给内核的网络协议栈中

开销#

为了突出纯 VirtIO 架构（特别是使用 virtio-net 进行网络通信时）的开销成本，我们将为单个数据包的接收和发送过程建立通用的、近似的开销计算公式。当然，上下文切换和虚拟机退出/进入并不是此处唯一的开销来源。其他开销还包括宿主机内核网络协议栈的处理、Qemu 的处理以及数据拷贝等。然而，需要注意的是，上下文切换和虚拟机退出/进入是主要的开销来源，因此它们的开销权重相比其他开销成本要更高。

• Tx路径的主要开销在
  • 在KVM中处理来自客户机的kick操作所引发的VM-Exit
  • 当qemu被唤醒去处理来自guest的新的Tx数据（如果之前处于休眠状态的话）所引发的上下文切换
  • qemu的处理，包括设备模拟逻辑、系统调用和其他的相关任务
  • qemu把数据从Tx virtqueue中拷贝到可被TAP设备访问到的共享内存中
  • host的内核网络协议栈转发数据到物理NIC上进行处理
  • 最终回到guest的VM-Entry
• Rx路径的主要开销
  • host内核网络协议栈的处理开销，包括从NIC获取数据并把他们准备好以备Qemu取走
  • qemu被唤醒以处理来自TAP设备或物理NIC的新的Rx数据
  • qemu把数据从共享内存复制到Rx virtqueue时候的内存拷贝
  • qemu的处理，包括设备模拟、系统调用和其他的相关任务
  • （如果此前虚拟机正在运行）为了注入中断而导致的VM-Exit
  • guest为了处理中断并处理Rx virtqueue中的数据的VM-Entry

overview#

现在qemu中的virtio-net设备让开了，直接允许virtio-net的数据平面的virtqueue在驱动程序和vhost-net之间共享。因为qemu中的virtio-net设备不在处理数据，因此它只是一个设备模型。它的唯一的功能只和控制平面的操作相关

同样值得注意的是，对于控制平面的操作，qemu中的virtio-net设备模型使用ioctl()系统调用来和vhost-net内核模块通信(e.g.,ioctl(fd, VHOST_SET_MEM_TABLE, mem))。这些调用是用于通知vhost-net一些如下的事情

• guest的内存区域: 虚拟机的哪些内存区域存放了virtqueue
• virtqueue的配置信息: 每个数据平面的virtqueue的地址，大小，eventfd(用来中断和kick)
• feature/offload配置信息: 与guest协商的是否启用或禁用特定的卸载功能(如TSO、校验的卸载)
• 运行时变更与销毁: 更新vring地址，开始或停止virtqueue，销毁时候释放资源，热迁移管理等