I/O虚拟化是SmartNIC/DPU/IPU中最核心的部分,AWS NITRO就是从I/O硬件虚拟化开始,逐渐开启了DPU这个新处理器类型的创新。而Virtio接口,已经是事实上的云计算虚拟化的标准化接口。Virtio成为整个问题的焦点:不管是SPDK/vhost、还是vDPA加速,都是围绕着Virtio接口展开。
本文围绕I/O设备虚拟化、通用接口Virtio以及虚拟化卸载等方面进行了详细的解读。推荐给大家。
**01 **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配合客户机完成相应的后端驱动程序,这样两者之间通过交互机制就可以实现高效的虚拟化过程。
图1 I/O设备虚拟化
Virtio框架如图2所示,使用Virtqueue来实现其I/O机制,每个Virtqueue就是一个承载大量数据的Queue。VRing是Virtqueue的具体实现方式,针对VRing会有相应的描述符表格进行描述。Virtio是一个通用的驱动和设备接口框架,基于Virtio分别实现了Virtio-net、Virtio-blk、Virtio-scsi等很多不同类型的模拟设备及设备驱动。
图2 Virtio框架
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驱动 | 直接访问物理设备,减少虚拟化开销 | 需要购买额外的较少的硬件 | 硬件设备支持多个虚拟设备,扩展性较好 |
**02 **通用接口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配置访问 |
-
接口
+关注
关注
33文章
8488浏览量
150809 -
DPU
+关注
关注
0文章
354浏览量
24124 -
i/o
+关注
关注
0文章
33浏览量
4569
发布评论请先 登录
相关推荐
评论