I/O软件模拟虚拟化和类虚拟化

I/O虚拟化是SmartNIC/DPU/IPU中最核心的部分，AWS NITRO就是从I/O硬件虚拟化开始，逐渐开启了DPU这个新处理器类型的创新。而Virtio接口，已经是事实上的云计算虚拟化的标准化接口。Virtio成为整个问题的焦点：不管是SPDK/vhost、还是vDPA加速，都是围绕着Virtio接口展开。

1 I/O设备虚拟化：从软件模拟到SR-IOV

I/O虚拟化是计算机虚拟化最复杂的部分，因为涉及到CPU、操作系统、Hypervisor以及I/O设备的相互配合。I/O虚拟化也经历了从软件模拟虚拟化、类虚拟化向完全硬件虚拟化的转变。

a. I/O软件模拟虚拟化和类虚拟化

I/O设备虚拟化场景，既要关注I/O设备模拟，也要关注vCPU和虚拟I/O设备的交互，许多条件交织在一起，使得整个问题变的非常复杂。I/O虚拟化性能代价主要体现在三个方面：驱动访问设备寄存器的代价；设备通过中断和DMA访问驱动的代价；设备模拟本身的代价。因此，I/O虚拟化性能优化主要是通过五个角度：

减少I/O访问寄存器的代价：一方面是把部分I/O的访问变成MMIO访问，这样就不需要陷入Hypervisor；另一方面是优化VM-exit/VM-entry切换的代价。

减少I/O访问的次数：比如简化通知机制，简化虚拟化设备功能等。

优化中断：主要有如APIC的中断硬件虚拟化或者不需要中断的轮询驱动。

减少DMA访问的代价：通过IOMMU等实现Pass Through模式。

减少设备模拟的代价：则主要是通过硬件SR-IOV机制实现硬件设备。

如图1(a)，虚拟机中看到的设备，一般是由Hypervisor模拟出来的。虚拟设备的功能，可以少于也可以多于物理的设备，甚至可以模拟出一些不存在的特性，模拟出不存在的硬件设备。通过I/O软件模拟的方式，我们称之为I/O设备软件模拟虚拟化。在I/O软件模拟虚拟化的解决方案中，客户机VM要使用底层的硬件资源，需要Hypervisor来截获每一条请求指令，然后模拟出这些指令的行为。我们都知道Hypervisor截获指令的动作就是从VM-exit，处理完模拟然后再VM-entry的过程，这个过程的代价很高，每条指令都要如此，带来的性能开销必然是非常庞大的。

如图1(b)所示，Virtio提供的类虚拟化方式，客户机完成设备的前端驱动程序，Hypervisor配合客户机完成相应的后端驱动程序，这样两者之间通过交互机制就可以实现高效的虚拟化过程。

Virtio框架如图2所示，使用Virtqueue来实现其I/O机制，每个Virtqueue就是一个承载大量数据的Queue。VRing是Virtqueue的具体实现方式，针对VRing会有相应的描述符表格进行描述。Virtio是一个通用的驱动和设备接口框架，基于Virtio分别实现了Virtio-net、Virtio-blk、Virtio-scsi等很多不同类型的模拟设备及设备驱动。

Virtio类虚拟化比传统的I/O设备软件模拟的性能优势体现在：很多控制和状态信息不需要通过寄存器读写操作来交互的，而是通过写入Virtqueue的相关数据结构来让驱动（Driver）和设备（Device）双方交互。并且在数据交互的时候，只需要在一定批量数据变化需要对方处理的时候才会通知对方，驱动通知设备是通过写Kick寄存器，设备通知驱动是通过中断。

b. I/O完全硬件虚拟化

评价I/O虚拟化技术的两个指标——性能和通用性。性能，当然是越接近无虚拟化环境下的I/O性能最好；而通用性，则是I/O虚拟化对客户操作系统越透明越好。要想要高性能，最直接的方法就是让客户机直接使用真实的硬件设备；要想要通用性，则是要用想办法让客户机操作系统自带的驱动程序能够发现设备并操作设备。

客户机直接操作设备面临两个问题：第一，如何让客户机直接访问到设备真实的I/O地址空间（包括I/O和MMIO）；第二，如何让设备的DMA直接访问客户机的内存空间。内存硬件虚拟化的EPT技术可以解决第一个问题。而VT-d技术则用来解决第二个问题。VT-d技术主要是引入地址重映射（IOMMU+IOTLB），负责提供重映射和设备直接分配。从设备端的DMA访问，都会进入地址重映射进行地址转换，使得设备可以访问到对应客户机特定的内存区域。

VT-d技术虽然可以将物理的I/O设备直接透传给虚拟机，但是一台计算机系统受限于接口，可以连的物理设备毕竟有限。因此，PCIe SR-IOV技术应运而生。通过PCIe SR-IOV技术，一个物理I/O设备可以虚拟出多个虚拟设备，分配给虚拟机使用。

如图1(c)所示，SR-IOV引入了两个PCIe的功能类型：

PFs（Physical Functions）：包括管理SR-IOV功能在内的所有PCIe设备。

VFs（Virtual Functions）：轻量级的PCIe设备，只能进行必要的配置和数据传输。

Hypervisor把VF分配给虚拟机，通过IOMMU等硬件辅助技术提供的DMA数据映射，直接在虚拟机和硬件设备之间传输数据。

c. I/O虚拟化总结

通过兼容性、性能、成本、扩展性四个方面对I/O虚拟化技术进行总结，详见表1：

表1 不同I/O虚拟化方式对比

I/O虚拟化方式	VM的兼容性	性能	成本	扩展性
设备接口软件模拟	重用已有驱动	频繁的上下文切换	没有额外硬件成本	受设备模拟的性能代价约束
类虚拟化前后端	需要加载特定驱动	基于共享队列的机制减少了前后端交互	没有额外硬件成本	受设备后端的性能代价约束
直接分配VT-d	重用设备驱动	直接访问物理设备，减少虚拟化开销	需要购买额外的较多的硬件	硬件设备独占性，受主板扩展槽限制
直接分配SR-IOV	需要加载VF驱动	直接访问物理设备，减少虚拟化开销	需要购买额外的较少的硬件	硬件设备支持多个虚拟设备，扩展性较好

2 通用接口Virtio

Virtio旨在提供一套高效的、良好维护的通用的Linux驱动，实现虚拟机应用和不同Hypervisor实现的模拟设备之间标准化的接口。Virtio作为类虚拟化的I/O设备接口，广泛应用于云计算虚拟化场景，某种程度上，Virtio已经成为事实上的I/O设备的接口标准。

在上一节介绍I/O虚拟化时，Virtio作为I/O类虚拟化技术做过介绍。本节会略去虚拟化相关的内容，把Virtio作为一个标准的接口进行详细的阐述。

2.1 Virtio寄存器

Virtio寄存器有三种类型：设备状态字、功能特征位以及PCIe配置空间。

a. 设备状态字

如表2所示，设备状态字（Device Status Field）标识了初始化序列步骤的完成情况。

表2 设备状态字描述

Bit位置	状态字值	定义	描述
0	1	ACKNOWLEDGE	表示操作系统已找到该设备并将其识别为有效的Virtio设备
1	2	DRIVER	表示操作系统已找到该设备并将其识别为有效的Virtio设备
2	4	DRIVER_OK	表示已安装驱动程序并准备驱动设备
3	8	FEATURES_OK	表示驱动程序已确认其理解的所有功能，并且功能协商已完成
4	16	保留位	保留位
5	32	保留位	保留位
6	64	DEVICE_NEEDS_RESET	表示设备遇到了无法恢复的错误。
7	128	FAILED	表示操作系统出现问题，或者驱动和设备功能不匹配，或者设备运行过程中出现致命错误等。

基于设备状态字，Virtio协议定义并约束了驱动程序必须按照以下顺序初始化设备：

（1）重置设备。

（2）设置ACKNOWLEDGE状态位，表示OS已发现此设备。

（3）设置DRIVER状态位，表示OS知道如何驱动此设备。

（4）读取设备功能位，并将操作系统和驱动程序可以理解的功能位子集写入设备。

（5）设置FEATURES_OK状态位。

（6）重新读取设备状态，如果FEATURES_OK读取结果依然为1，则表示设备接受了驱动的功能位子集；否则，如果为0，则表示该设备不支持驱动的功能子集，该设备不可用。

（7）执行设备特定的设置，包括发现设备的虚拟队列、读取和可能写入设备的virtio配置空间以及填充虚拟队列等。

（8）将DRIVER_OK状态位设置为1。此时，设备初始化完成，设备处于活动状态。

（9）如果上述这些步骤中的任何一个发生不可恢复的错误，驱动程序会将FAILED状态位设置为1。

b. 功能特征位

每个Virtio设备均提供其支持的所有功能对应的功能特征位。在设备初始化期间，驱动程序将读取此信息并告知设备它接受的子集。

通过这种方式可以实现向前和向后兼容：如果设备增加了新功能位，则较旧的驱动程序就不会将该功能位写回到设备中（意味着此功能不会被开启）。同样，如果驱动程序增加了新的功能，而设备未提供此功能，则同样此功能不会被写回到设备（意味着此功能不会被开启）。

Virtio1.1协议中的功能位分配如下：

比特位0 – 23：特定设备类型的功能位；

比特位24 – 37：保留用于扩展队列和功能协商机制的功能位；

比特位38以上：保留功能位以供将来扩展。

c. 配置空间

Virtio over PCI使用的配置空间与标准的PCI配置空间相比，特殊的地方在于其Vendor ID和Device ID。Virtio的Vendor ID为0x1AF4，其Device ID编号从0x1040-0x107F。

为了跟PCI Capabilities格式兼容，Virtio定义的virtio_pci_cap格式如表3所示。

表3 Virtio的PCI capability结构

	Byte 3	Byte 2	Byte 1	Byte 0
0x0	cfg_type	cap_len	cap_vndr	cap_vndr
0x4	padding	bar
0x8	offset
0xC	Length

其中cfg_type标识virtio_pci_cap类型，共有五种，代表了映射在BAR空间的五组寄存器。virtio_pci_cap类型如表4所示。

表4 Virtio PCI capability类型

类型名称	ID	描述
VIRTIO_PCI_CAP_COMMON_CFG	1	通用配置
VIRTIO_PCI_CAP_NOTIFY_CFG	2	通知
VIRTIO_PCI_CAP_ISR_CFG	3	ISR状态
VIRTIO_PCI_CAP_DEVICE_CFG	4	设备具体的配置
VIRTIO_PCI_CAP_PCI_CFG	5	PCI配置访问

2.2 Virtqueue交互队列

Virtio 1.1引入了Packed Virtqueue的概念，对应的Virtio 1.0的Virtqueue被称为Split Virtqueue。

如图3所示，为Virtio1.0的Split Virtqueue结构。Virtqueue由三部分组成：

描述符表

可用的描述符环

已使用的描述符环

Virtio 1.0的Split Virtqueue具有一些缺点：

如果是虚拟化场景软件模拟Virtio设备的话，因为分散的数据结构，导致Cache利用率较低，每次请求都会有很多Cache不命中；

如果是硬件实现的话，每次描述符需要多次设备DMA访问。

如图4所示，Virtio 1.1引入了Packed Virtqueue的概念。整个描述符只有一个数据结构。这样，如果软件实现Virtio设备模拟的话，可以提升描述符交互的Cache命中率。如果硬件实现的，可以降低设备DMA的访问次数。

2.3 Virtio交互

驱动和设备的交互，符合生产者消费者模型的数据及通知（Notification）的交互行为。驱动把共享队列的队列项准备好，通过写寄存器的方式通知设备。设备收到驱动发送的通知则处理队列项以及相应的数据搬运工作，结束后更新队列状态并通知（设备通知驱动是通过中断）驱动。驱动接收到中断通知时候，把已经使用的队列项释放，并更新队列状态。

一个典型的通用的驱动和设备的交互流程如图5所示。Virtio场景的驱动和设备交互，驱动给设备的通知（Notification）称为Kick，设备给驱动的通知称为Interrupt（中断）。Kick和Interrupt操作是Virtio接口的一部分，在虚拟化场景，Kick和Interrupt需要非常大的CPU切换代价。驱动希望在Kick之前产生尽可能多的待处理缓冲项（一个缓冲项对应一个描述符和描述符指向的数据块）；同样的，设备希望处理尽可能多的缓冲项然后再发送一个中断。通过尽量处理更多的缓冲项的方式，来摊薄通知的代价。

这种策略是一种理想状态，因为大多数时候驱动并不知道下一组缓冲项何时带来，因此不得不每一组缓冲项准备好之后就必须要Kick设备。同样的，设备在处理完相应的缓冲项之后，就尽快的发送中断给驱动，以达到尽可能小的延迟。

如图6所示，在设备模拟的虚拟化场景下，驱动可以暂时禁用中断，设备也可以暂时禁用Kick。通过这样的机制，可以最大限度的减少通知的代价，并且不影响性能和延迟。Virtio 1.1支持两种通知抑制机制，因此共有三种模式：

使能通知模式：完全无抑制，使能通知；

禁用通知模式：如图6所示，可以完全禁止对方发通知给自己；

使能特定的描述符通知模式：告知对方一个特定的描述符，当对方顺序处理到此描述符处理完成时产生通知。

2.4 总结

如图7，Virtio基于分层的设计思想，定义了三层Virtio设备架构：

最下层的总线接口。PCI是最常用的Virtio场景使用的总线，但Virtio协议不仅仅支持PCI，也支持MMIO和Channel IO等。

通用的Virtio交互接口。包括Virtqueue、功能特征位、配置空间等。Virtio交互接口是Virtio最核心的功能，通过Virtio交互接口实现了不同类型设备的标准化。

上层的特定设备接口。在Virtio协议里，定义网络、块、控制台、SCSI、GPU等各种不同类型的设备。

Virtio的优点体现在：

Virtio实现了尽可能多的设计共享。这样，在开发的时候就可以复用很多软件和硬件资源，达到快速开发的目的。

Virtio实现了接口的标准化。标准化体现在两个方面：

(1)一个是通用的Virtio交互接口，统一了不同的设备类型软硬件交互；

(2)另一个是基于Virtio的Virtio-net、Virtio-block等广泛应用于云计算虚拟化场景，Virtio已经成为事实上的标准I/O接口。

而Virtio的缺点，则同样因为Virtio实现了接口的标准化，而忽略了不同设备类型数据传输的特点。因此，在一些大数据量传输的场景，效率比较低下。如果是在类似HPC这样的性能和延迟非常敏感的场景，Virtio就不是一个很好的选择。

3 虚拟化卸载

虚拟化卸载指的是计算机虚拟化中消耗CPU资源较多的接口设备模拟、热迁移、虚拟化管理等任务的卸载。

a. 接口设备的卸载

前面我们介绍了网络、远程存储等IO工作任务的卸载，而虚拟化卸载主要指的是跟IO相关的接口设备的卸载，例如网络、存储等接口设备的卸载。IO接口设备的卸载本身上也是IO硬件虚拟化的过程，比如我们通过VT-d技术实现从VM中pass though访问硬件设备，某种程度上也可以认为是把运行在Hypervisor中的模拟设备 “卸载”到了硬件。因此，IO接口设备的卸载本质上和IO设备硬件虚拟化是一件事情。

如图8，为了实现设备接口的标准化、加速IO处理的性能以及潜在的充分利用现有的虚拟化生态（例如更好的支持设备热迁移）等原因，阿里云在神龙芯片里实现了硬件的Virtio接口设备，通过Virtio接口设备支持Virtio-net网络驱动和Virtio-blk存储驱动等，实现了类虚拟化IO设备Virtio的硬件“卸载”。

AWS的NITRO系统支持网络、本地存储和远程存储，NITRO实现了网络接口设备ENA/EFA（AWS自定义接口）的硬件“卸载”以及存储接口设备NVMe（远程存储EBS使用的是NVMe接口，本地存储也是NVMe接口）的卸载。

b. 接口设备卸载后的迁移问题

当把设备“卸载”到硬件，让VM直接访问硬件设备，这使得VM的设备热迁移变的非常有挑战。vDPA（vhost Data Path Acceleration，vhost数据路径加速，其中vhost是Virtio后端设备模拟的轮询方式实现）实现了一种折中的解决方案，如图9所示，vDPA把Virtio分为了控制面和数据面：

控制面。vDPA控制面依然是通过要经过Hypervisor的处理，用于设备和VM之间的配置更改和功能协商，用于建立和终止数据面。

数据面。vDPA数据面包括共享队列以及相应的通知机制，用于在设备和VM之间传输实际的数据。

使用vDPA一个重要原因是，在热迁移的时候可以很方便的把Virtio数据面的处理切换回传统的Virtio/Vhost后端设备模拟。这样，可以充分利用现有的基于KVM/Qemu对Virtio设备迁移的解决方案来完成设备的迁移。

c. 虚拟化管理的卸载

从软件虚拟化进化到硬件虚拟化的过程，本身就可以看作是一个硬件加速以及硬件卸载的过程。我们逐步的剥离了Hypervisor的功能，比如通过VT-x技术“卸载”了Hypervisor的CPU/内存等的软件模拟，以及通过VT-d以及vDPA等技术“卸载”了设备软件模拟。这些剥离，使得Hypervisor越来越轻量，整个系统的虚拟化开销也越来越少。进一步的，我们可以把虚拟化的管理（例如Linux平台主流的管理程序Libvirt）卸载到硬件中的嵌入式软件运行。

如图10， 我们通过桥接的方式，实现主机软件和硬件中嵌入式软件通信机制。把虚拟化管理等软件任务从主机卸载到嵌入式系统（依然有很小一部分任务无法卸载，如虚拟机资源分配、vCPU调度等）。这样，可以把几乎100%的主机资源提供给用户，使用户虚拟机得到近乎物理机的性能。

通过虚拟化管理卸载到硬件中的嵌入式CPU软件，我们可以做到物理上的业务和管理分离，整个业务主机跟云计算管理网络安全的隔离，只能通过特定的接口访问到Lite Hypervisor，除此之外，不能访问主机的任何资源。这样，即使有潜在的运维操作失误，也无法对业务主机造成影响。

责任编辑：haq