写在前面

网络虚拟化曾经只是内核虚拟化功能开发者才会关注的技术。但随着云计算模式和云原生概念的推广，云上业务的部署形态都已转向了虚拟机和容器，而两者都依赖网络虚拟化技术提供高性能网络功能，因此虚拟网络已经是云环境下的主流网络形态。而云上的虚拟机和容器对网络虚拟化技术的易用性、功能和性能都提出了更高的要求。

对于云上环境的网络基础设施开发者来说，网络虚拟化已经成为了一种必须掌握的技术。但在学习网络虚拟化技术时，笔者没能找到一个能够完整介绍网络虚拟化技术类型、原理和实现的信息源，特别是中文资料。因此，笔者计划将学习网络虚拟化技术过程中收集到的信息总结一下，形成一系列介绍各种网络虚拟化技术的文章，供后续的学习和工作中参考。每项技术都会从笔者最关心的问题出发，介绍相关知识并尝试回答这些问题。

本文是其中的第一篇，介绍最经典的网络虚拟化技术——QEMU虚拟网卡。

问题

使用QEMU虚拟网卡时，guest系统中是如何使用网卡和网络的？是否感知虚拟化设备的存在，是否需要和运行在物理机上时使用不同的配置？是否需要修改内核？
在guest系统中如何感知和加载网卡？QEMU是如何实现来支持这种功能的？
在guest系统中如何通过网卡收发报文？QEMU是如何实现来支持这种功能的？
guest系统收发的报文，在QEMU和host系统中是如何流转的？通过哪些环节实现guest和host、guest和外部网络间的交互？

QEMU

QEMU是LINUX平台上广泛应用的虚拟机管理器（VMM），它能够模拟多种硬件架构和设备，支持模拟运行多种不同的操作系统。其中，QEMU就支持了对特定网卡设备（例如e1000）的全虚拟化，使得guest操作系统和内核不需要做任何修改就能使用原有的网卡驱动完成网络操作。

QEMU模拟IO设备的原理，可以参考Understanding QEMU devices和High-level introduction to virtualization's low-level。大体上，通过指令翻译或者基于KVM和CPU硬件虚拟化，QEMU可以在guest操作设备，也就是执行访问设备地址空间或寄存器的指令时，中断guest的执行流并模拟出guest操作对设备的影响，之后再恢复guest的执行。

QEMU虚拟网卡

网卡作为一种网络IO设备，在QEMU中的模拟实现和其他IO设备是一样的。通过QEMU的模拟，guest系统中使用虚拟网卡时的使用方法和感受和在物理机上是完全相同的（除了性能之外），不需要修改内核驱动或配置。

guest系统对网卡的感知和加载的模拟和其他设备的模拟也是一样的，对网卡的感知来自于QEMU对PCI/PCIE总线设备的模拟，对网卡的加载、收发包则是对网卡设备的模拟。

QEMU中实现了多种经典网卡设备的模拟，例如e1000、rtl8139、i82559c等。网卡设备和驱动的逻辑都是类似的，这里就以e1000的网络报文收发为例，分析一下guest中网络rx/tx操作的实现逻辑步骤。由于主流的x86架构CPU都已经支持了CPU硬件虚拟化，例如Intel的VT-x和AMD的AMD-V，因此这里只讨论QEMU-KVM场景。

TX：

guest内核将tx报文内容写入skb
guest内核将tx报文信息（例如数据的dma地址、长度等）写入descriptor ring
guest内核修改网卡的tx队列寄存器，通知网卡处理tx报文
触发VM Exit，KVM处理VM Exit事件
KVM发现是IO操作，返回用户态QEMU进程（qemu进程从ioctl中返回）
QEMU处理IO操作，根据descriptor内容将报文转发
QEMU更新虚拟网卡的状态和DMA内存
QEMU重新通过KVM接口恢复guest执行（VM Entry）

RX：

QEMU收到rx报文
QEMU将rx报文内容写入guest指定的DMA地址空间
QEMU将rx报文信息写入descriptor ring
QEMU更新rx队列寄存器（虚拟）
QEMU向guest注入中断
guest处理中断，更新descriptor ring和寄存器，这里又会陷入QEMU

上面只是一个简化的流程，guest处理报文的逻辑和物理机是一样的，可以参考Linux系统下网络数据包的处理流程_dillanzhou的博客-CSDN博客。中断注入原理可以参考High-level introduction to virtualization's low-level。

通过上述流程，guest发送的报文就能够被QEMU转发到host内核或网络上，而从host或网络上发给guest的报文也可以被QEMU转发到guest虚拟网卡上。

QEMU虚拟网络

前面已经介绍了QEMU如何模拟guest的网卡行为，但仍然有一个问题，就是报文在QEMU到host内核/网卡之间是如何流转的？毕竟，guest需要通信的对象并不是QEMU本身。这部分功能称为虚拟网络的后端。

QEMU支持的网络后端模式实现主要有两种：SLIRP(user)和TAP。

SLIRP模式是一种在用户态实现的后端。在这种模式下，QEMU在用户态解析guest收发的网络报文，并向其他guest和host转发。同时SLIRP还支持NAT地址转换。这就要求在SLIRP模式下实现一套TCP/IP协议栈。SLIRP的实现笔者没有看过，也没有找到详细介绍其原理的文章。据找到的个别资料介绍，SLIRP在和host或外部网络通信时，并不是通过raw socket转发报文的形式实现的，而是通过将guest报文的行为翻译成普通socket操作来实现的，例如guest发送了一个SYN包，SLIRP就调用一个到目标地址的connect syscall。这个实现听起来有些不可思议，但SLIRP本身来自于很古老的协议模拟软件，因此也是可以理解的。但这种实现功能必然有限，如果guest发送一些不太标准的报文或SLIRP协议栈不能理解或处理的报文，那么网络功能必然不能正常运行。

TAP模式就比较好理解了。这种模式下QEMU为每个guest创建一个tap设备，直接向这个tap设备收发报文。tap设备可以连接到一个bridge上实现更复杂的路由功能。

其实guest报文到了QEMU用户态逻辑之后，后端的实现方式可以有很多种，例如OVS或OVS-DPDK。这部分的功能与虚拟化其实已经没有太多的关系，更多是网络报文处理转发能力的实现。后续将不再重点讨论这部分技术。