Linux虚拟化KVM-Qemu分析(八)之virtio初探

目录

概述

1. 网卡

1.1 网卡工作原理

1.2 Linux网卡驱动

2. 网卡全虚拟化

2.1 全虚拟化方案

2.2 弊端

3. 网卡半虚拟化

3.1 virtio

3.2 半虚拟化方案

参考


 

Linux虚拟化KVM-Qemu分析(一)

Linux虚拟化KVM-Qemu分析(二)之ARMv8虚拟化

Linux虚拟化KVM-Qemu分析(三)之KVM源码(1)

Linux虚拟化KVM-Qemu分析(四)之CPU虚拟化(2)

Linux虚拟化KVM-Qemu分析(五)之内存虚拟化

Linux虚拟化KVM-Qemu分析(六)之中断虚拟化

Linux虚拟化KVM-Qemu分析(七)之timer虚拟化

Linux虚拟化KVM-Qemu分析(八)之virtio初探

Linux虚拟化KVM-Qemu分析(九)之virtio设备

virtio 网络的演化

在CentOS上进行虚拟化:QEMU、Xen、KVM、LibVirt、oVirt

ARM SMMU原理与IOMMU技术(“VT-d” DMA、I/O虚拟化、内存虚拟化)

OpenVZ,Xen,KVM等:虚拟化解决方案

KVM Virtio: An I/O virtualization framework for Linux(Linux虚拟IO框架)

ARM SMMU原理与IOMMU技术(“VT-d” DMA、I/O虚拟化、内存虚拟化)

用QEMU构建嵌入式LINUX系统

疫情下的远程办公:理解Linux虚拟网络设备之tun/tap

Linux虚拟网络设备之tun/tap

Tun/Tap接口教材-[翻译:Tun/Tap interface tutorial]

Linux的TUN/TAP编程

 

说明:

  1. KVM版本:5.9.1
  2. QEMU版本:5.0.0
  3. 工具:Source Insight 3.5, Visio

概述

  • 从本文开始将研究一下virtio;
  • 本文会从一个网卡虚拟化的例子来引入virtio,并从大体架构上进行介绍,有个宏观的认识;
  • 细节的阐述后续的文章再跟进;

1. 网卡

1.1 网卡工作原理

先来看一下网卡的架构图(以Intel的82540为例):

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • OSI模型,将网络通信中的数据流划分为7层,最底下两层为物理层和数据链路层,对应到网卡上就是PHYMAC控制器
  • PHY:对应物理层,负责通信设备与网络媒介(网线)之间的互通,它定义传输的光电信号、线路状态等;
  • MAC控制器:对应数据链路层,负责网络寻址、错误侦测和改错等;
  • PHYMAC通过MII/GMII(Media Independent Interface)MDIO(Management Data Input/output)相连;
  • MII/GMII(Gigabit MII):由IEEE定义的以太网行业标准,与媒介无关,包含数据接口和管理接口,用于网络数据传输;
  • MDIO接口,也是由IEEE定义,一种简单的串行接口,通常用于控制收发器,并收集状态信息等;
  • 网卡通过PCI接口接入到PCI总线中,CPU可以通过访问BAR空间来获取数据包,也有网卡直接挂在内存总线上;
  • 网卡还有一颗EEPROM芯片,用于记录厂商ID、网卡的MAC地址、配置信息等;

我们主要关心它的数据流,所以,看看它的工作原理吧:

ddr,即双倍速率同步动态随机存储器,是内存的其中一种。

BAR(base address register)

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • 网络包的接收与发送,都是典型的生产者-消费者模型,简单来说,CPU会在内存中维护两个ring-buffer,分别代表RXTXring-buffer中存放的是描述符,描述符里包含了一个网络包的信息,包括了网络包地址、长度、状态等信息;
  • ring-buffer有头尾两个指针
    • 发送端为:TDH(Transmit Descriptor Head)和TDT(Transmit Descriptor Tail)
    • 接收端为:RDH(Receive Descriptor Head)和RDT(Receive Descriptor Tail)
    • 在数据传输时,由CPU和网卡来分开更新头尾指针的值,这也就是生产者更新尾指针,消费者更新头指针,永远都是消费者追着生产者跑,ring-buffer也就能转起来了;
  • 数据的传输,使用DMA来进行搬运,CPU的拷贝显然是一种低效的选择。在之前PCI系列分析文章中分析过,PCI设备有自己的BAR空间,可以通过DMA在BAR(base address register)空间和DDR(双倍速率同步动态随机存储器)空间内进行搬运;

1.2 Linux网卡驱动

在网卡数据流图中,我们也基本看到了网卡驱动的影子,驱动与网卡之间是异步通信:

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • 驱动程序负责硬件的初始化,以及TX和RX的ring-buffer的创建及初始化;
  • ndo_start_xmit负责将网络包通过驱动程序发送出去,netif_receive_skb负责通过驱动程序接收网络包数据;
  • 数据通过struct sk_buff来存储;
  • 发送数据时,CPU负责准备TX网络包数据以及描述符资源,更新TDT指针,并通知NIC可以进行数据发送了,当数据发送完毕后NIC通过中断信号通知CPU进行下一个包的处理;
  • 接收数据时,CPU负责准备RX的描述符资源,接收数据后,NIC通过中断通知CPU,驱动程序通过调度内核线程来处理网络包数据,处理完成后进行下一包的接收;

2. 网卡全虚拟化

2.1 全虚拟化方案

全虚拟化方案,通过软件来模拟网卡,Qemu+KVM的方案如下图:

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • Qemu中,设备的模拟称为前端,比如e1000,前端与后端通信,后端再与底层通信,我们来分别看看发送和接收处理的流程;

疫情下的远程办公:理解Linux虚拟网络设备之tun/tap

Linux虚拟网络设备之tun/tap

Tun/Tap接口教材-[翻译:Tun/Tap interface tutorial]

Linux的TUN/TAP编程

  • 发送:

    1. Guest OS在准备好网络包数据以及描述符资源后,通过写TDT寄存器,触发VM的异常退出,由KVM模块接管;
    2. KVM模块返回到Qemu后,Qemu会检查VM退出的原因,比如检查到e1000寄存器访问出错,因而触发e1000前端工作;
    3. Qemu能访问Guest OS中的地址内容,因而e1000前端能获取到Guest OS内存中的网络包数据,发送给后端,后端再将网络包数据发送给TUN/TAP驱动,其中TUN/TAP为虚拟网络设备;
    4. 数据发送完成后,除了更新ring-buffer的指针及描述符状态信息外,KVM模块会模拟TX中断;
    5. 当再次进入VM时,Guest OS看到的是数据已经发送完毕,同时还需要进行中断处理;
    6. Guest OS跑在vCPU线程中,发送数据时相当于会打算它的执行,直到处理完后再恢复回来,也就是一个严格的同步处理过程;
  • 接收:

    1. 当TUN/TAP有网络包数据时,可以通过读取TAP文件描述符来获取;
    2. Qemu中的I/O线程会被唤醒并触发后端处理,并将数据发送给e1000前端
    3. e1000前端将数据拷贝到Guest OS的物理内存中,并模拟RX中断,触发VM的退出,并由KVM模块接管;
    4. KVM模块返回到Qemu中进行处理后,并最终重新进入Guest OS的执行中断处理;
    5. 由于有I/O线程来处理接收,能与vCPU线程做到并行处理,这一点与发送不太一样;

一个用户态tap的例子《疫情下的远程办公:理解Linux虚拟网络设备之tun/tap》:

/**
 * TUN/TAP编程示例
 */
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <sys/types.h>
#include <linux/if_tun.h>
#include <stdlib.h>
#include <stdio.h>
 
int tun_alloc(int flags)
{
 
    struct ifreq ifr;
    int fd, err;
    char *clonedev = "/dev/net/tun";
 
    //打开tun设备
    if ((fd = open(clonedev, O_RDWR)) < 0) {
        return fd;
    }
 
    memset(&ifr, 0, sizeof(ifr));
    ifr.ifr_flags = flags;
 
    if ((err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0) {
        close(fd);
        return err;
    }
 
    printf("Open tun/tap device: %s for reading...\n", ifr.ifr_name);
 
    return fd;
}
 
int main()
{
 
    int tun_fd, nread;
    char buffer[1500];
 
    /* Flags: IFF_TUN   - TUN device (no Ethernet headers)
     *        IFF_TAP   - TAP device
     *        IFF_NO_PI - Do not provide packet information
     */
    tun_fd = tun_alloc(IFF_TUN | IFF_NO_PI);
 
    if (tun_fd < 0) {
        perror("Allocating interface");
        exit(1);
    }
 
    while (1) {
        //从tun设备读取数据
        nread = read(tun_fd, buffer, sizeof(buffer));
        if (nread < 0) {
            perror("Reading from interface");
            close(tun_fd);
            exit(1);
        }
 
        printf("Read %d bytes from tun/tap device\n", nread);
    }
 
    return 0;
}

2.2 弊端

  • Guest OS去操作寄存器的时候,会触发VM退出,涉及到KVM和Qemu的处理,并最终再次进入VM,overhead较大;
  • 不管是在Host还是Guest中,中断处理的开销也很大,中断涉及的寄存器访问也较多;
  • 软件模拟的方案,吞吐量性能也比较低,时延较大;

所以,让我们大声喊出本文的主角吧!

 

3. 网卡半虚拟化

在进入主题前,先思考几个问题:

  1. 全虚拟化下Guest可以重用驱动、网络协议栈等,但是在软件全模拟的情况下,我们是否真的需要去访问寄存器吗(比如中断处理),真的需要模拟网卡的自协商机制以及EEPROM等功能吗?
  2. 是否真的需要模拟大量的硬件控制寄存器,而这些寄存器在软件看来毫无意义?
  3. 是否真的需要生产者/消费者模型的通知机制(寄存器访问、中断)?

3.1 virtio

网卡的工作过程是一个生产者消费者模型,但是在前文中可以看出,在全虚拟化状态下存在一些弊端,一个更好的生产者消费者模型应该遵循以下原则:

  1. 寄存器只被生产者使用去通知消费者ring-buffer有数据(消费者可以继续消费),而不再被用作存储状态信息;
  2. 中断被消费者用来通知生产者ring-buffer是非满状态(生产者可以继续生产);
  3. 生产者和消费者的状态信息应该存储在内存中,这样读取状态信息时不需要VM退出,减少overhead;
  4. 生产者和消费者跑在不同的线程中,可以并行运行,并且尽可能多的处理任务;
  5. 非必要情况下,相互之间的通知应该避免使用;
  6. 忙等待(比如轮询)不是一个可以接受的通用解决方案;

基于上述原则,我们来看看从特殊到一般的过程:

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • 第一行是针对网卡的实现,第二行更进一步的抽象,第三行是通用的解决方案了,对I/O操作的虚拟化通用支持;

所以,在virtio的方案下,网卡的虚拟化看上去就是下边这个样子了:

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • Hypervisor和Guest都需要实现virtio,这也就意味着Guest的设备驱动知道自己本身运行在VM中;
  • virtio的目标是高性能的设备虚拟化,已经形成了规范来定义标准的消息传递API,用于驱动和Hypervisor之间的传递,不同的驱动和前端可以使用相同的API;
  • virtio驱动(比如图中的virtio-net driver)的工作是将OS-specific的消息转换成virtio格式的消息,而对端(virtio-net frontend)则是做相反的工作;

virtio的数据传递使用scatter-gather list(sg-list)

(番外:传统的block DMA 一次只能传输物理上连续的一个块的数据, 完成传输后发起中断。而scatter-gather DMA允许一次传输多个物理上不连续的块,完成传输后只发起一次中断。 )

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • sg-list是概念上的(物理)地址和长度对的链表,通常作为数组来实现;
  • 每个sg-list描述一个多块的buffer,消费者用它来作为输入或输出操作;

 
virtio的核心是virtqueue(VQ)的抽象:

  • VQ是队列,sg-list会被Guest的驱动放置到VQ中,以供Hypervisor来消费;
  • 输出sg-list用于向Hypervisor来发送数据,而输入sg-list用于接收Hypervisor的数据;
  • 驱动可以使用一个或多个virqueue

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  1. 当Guest的驱动产生一个sg-list时,调用add_buf(SG, Token)入列;
  2. Hypervisor进行出列操作,并消费sg-list,并将sg-list push回去;
  3. Guest通过get_buf()进行清理工作;

上图说的是数据流方向,那么事件的通知机制如下:

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • 当Guest驱动想要Hypervisor消费sg-list时,通过VQ的kick来进行通知;
  • 当Hypervisor通知Guest驱动已经消费完了,通过interupt来进行通知;

大体的数据流和控制流讲完了,细节实现后续再跟进了。

 

3.2 半虚拟化方案

那么,半虚拟化框架下的网卡虚拟化数据流是啥样的呢?

  • 发送

Linux虚拟化KVM-Qemu分析(八)之virtio初探

  • 接收

Linux虚拟化KVM-Qemu分析(八)之virtio初探

相信你应该对virtio有个大概的了解了,好了,收工。

 

参考

《Virtio networking: A case study of I/O paravirtualization》
《 PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer's Manual》

欢迎关注个人公众号,不定期更新Linux相关技术文章。

转自公众号

Linux虚拟化KVM-Qemu分析(八)之virtio初探

作者:LoyenWang
出处:https://www.cnblogs.com/LoyenWang/
公众号:LoyenWang
版权:本文版权归作者和博客园共有
转载:欢迎转载,但未经作者同意,必须保留此段声明;必须在文章中给出原文连接;否则必究法律责任

上一篇:VMware Ubuntu使用Qemu模拟开发板


下一篇:ubuntu下使用qemu虚拟机