理解 PCIe 虚拟化技术:什么是 PCIe 虚拟通道?
一、背景
SR-IOV(Single Root I/O Virtualization)是由PCI-SIG组织定义的PCIe规范的扩展规范《Single Root I/O Virtualization and Sharing Specification》,目的是通过提供一种标准规范,为VM(虚拟机)提供独立的内存空间、中断、DMA数据流,当前最新版本为1.1。
图1.1
IO虚拟化有软件模拟、基于virtio的半虚拟化和设备直通三种方式,见图1.1,其中设备直通实现了数据面加速,允许物理PCIe设备可以直接访问虚拟机的GuestOS中运行相应驱动分配的物理地址(GPA)。
SR-IOV的出现,支持了单个物理PCIe设备虚拟出多个虚拟PCIe设备,然后将虚拟PCIe设备直通到各虚拟机,以实现单个物理PCIe设备支撑多虚拟机的应用场景,如图1.2。
图1.2
二、SR-IOV原理
2.1 硬件实现
2.1.1 SR-IOV基本结构
SR-IOV是在PCIe规范的基础上实现的,SR-IOV协议引入了两种类型功能的概念:物理功能 (Physical Function, PF)和虚拟功能 (Virtual Function, VF),基本结构见图2.1.1。
图2.1.1
PF用于支持 SR-IOV 功能的 PCI 功能,如 SR-IOV 规范中定义,PF 包含 SR-IOV 功能配置结构体,用于管理 SR-IOV 功能。PF 是全功能的 PCIe 功能,可以像其他任何 PCIe 设备一样进行发现、管理和处理。PF 拥有完全配置资源,可以用于配置或控制 PCIe 设备。
VF是与PF关联的一种功能,是一种轻量级 PCIe 功能,可以与物理功能以及与同一物理功能关联的其他 VF 共享一个或多个物理资源。VF 仅允许拥有用于其自身行为的配置资源。
2.1.2 VF的BAR空间资源
VF的BAR空间是PF的BAR空间资源中规划的一部分,VF不支持IO空间,所以VF的BAR空间也需要映射到系统内存,VF的BAR空间的物理资源排布如图2.1.2:
图2.1.2
2.1.3 PF的SR-IOV Extended Capabilities 配置
PF的PCIe扩展配置空间 SR-IOV Extended Capability支持对SR-IOV功能进行配置,如图2.1.3:
图2.1.3
其中SR-IOV Control 字段的bit0位是SR-IOV的使能位,默认为0,表示关闭,如果需要开启SR-IOV功能,需要配置为1。
TotalVFs字段表示PCIe Device支持VF的数量。
NumVFs字段表示开启VF的数量,此值不应超过PCIe Device支持的VF的数量TotalVFs的值。
First VF Offset字段表示第一个各VF相对PF的Routing ID(即Bus number、Device number、Function number)的偏移量。
VF Stride字段表示相邻两个VF的Routing ID的偏移量。
其他字段含义详见《Single Root I/O Virtualization and Sharing Specification Revision 1.1》。
2.2 软件支持
Linux系统下,基于SR-IOV有三种应用场景:HostOS使用PF、HOstOS使用VF、将VF直通到VM(虚拟机),见图2.2.1:
图2.2.1
Linux系统中PCI驱动框架drivers/pci/iov.c提供了一系列对SR-IOV Extended Capability的配置接口函数,PCIe Device需要有相应的PF驱动和VF驱动,PF驱动支持配置SR-IOV,VF驱动需要实现相应的PCIe Device的业务功能(例如NIC或GPU),VFIO中的vfio-pic是一个简易符合VFIO框架PCIe驱动。
三、基于SR-IOV的IO虚拟化
3.1 基于QEMU/KVM的PCIe设备直通框架
在QEMU/KVM的虚拟化架构下,PCIe设备直通的软硬件系统架构由下往上有如下几部分(见图3.1):
l PCIe Device(支持SR-IOV功能)
l IOMMU
l VFIO
l Hypervisor(QEMU/KVM)
l VF Driver(运行在GuestOS中)
图3
3.1.1 IOMMU
IOMMU(I/O Memory Management Unit)是一个内存管理单元,主要针对外设访问系统内存市进行内存管理,像intel VT-d、AMD的IOMMU及ARM的SMMU都具有相同功能。IOMMU支持PCIe Device虚拟化的两个基础功能:地址重映射和中断重映射。
3.1.1.1 DMA物理地址重映射
(DMA Remapping )
1)地址空间隔离
在没有iommu的时候,用户态驱动可以通过设备dma可以访问到机器的全部的地址空间,如何保护机器物理内存区对于用户态驱动框架设计带来挑战。引入iommu以后,iommu通过控制每个设备dma地址到实际物理地址的映射转换,可以实现地址空间上的隔离,使设备只能访问规定的内存区域,见图3.1.1.1.1。
图3.1.1.1.1
2)GPA(虚拟机物理地址) --> HPA(宿主机物理地址)
物理PCI设备通过直通的方式进入到虚拟机的客户机时,客户机设备驱动使用透传设备的DMA访问虚拟机内存物理地址时,IOMMU会进行 GPA-->HPA的转换,详细转换细节在下一章节分析。
3.1.1.2 中断重映射
以Intel VT-d为例,提出了两个机制支持中断重映射:
引入两种中断请求格式
兼容模式和重映射模式,Bit4位为0来表征为不可重映射中断,Bit4位为
1来表征为可重映射中断,见图3.1.1.2.1和图3.1.1.2.2。
图3.1.1.2.1
图3.1.1.2.2
引入Interrupt Remapping Table Entry (IRTE)
Interrupt Remapping Table Entry是一个二级表,需要先通过Interrupt Remapping Table Address Register来找到Interrupt Remapping Table Entry所在的地址,Interrupt Remapping Table Entry的格式如图3.1.1.2.3:
图3.1.1.2.3
IOMMU中断重映射的实质是将来自PCIe设备的中断(包括来自IOAPIC和PCIe设备的MSI/MSI-X等)拦截下来判断是否为重映射中断,如果是重映射中断会通过查询中断映射表(Interrupt Remapping Table Entry)找到真正的中断路由信息然后发送给物理CPU。
3.1.2 VFIO
VFIO(Virtual Function I/O)是基于IOMMU为HostOS的用户空间暴露PCIe设备的配置空间和DMA。VFIO的组成主要有以下及部分,见图3.1.2.1:
图3.1.2.1
l VFIO Interface:
VFIO通过设备文件向用户空间提供统一访问接口:
• Container文件描述符:打开/dev/vfio字符设备可得
• IOMMU group文件描述符:打开/dev/vfio/N文件可得
• Device文件描述符:向IOMMU group文件描述符发起相关ioctl可得
l vfio_iommu_type1_driver:
为VFIO提供了IOMMU重映射驱动,向用户空间暴露DMA操作。
l vfio-pci:
vfio支持pci设备直通时以vfio-pci作为pci设备驱动挂载到pci总线, 将pci设备io配置空间、中断暴露到用户空间。
3.1.3 QEMU/KVM PCI设备直通
QEMU/KVM 的PCI设备直通QEMU的核心工作主要有两部分:
1) 读取PCIe设备信息
通过VFIO接口读取PCIe设备的配置空间和DMA信息,
2) 为虚拟机创建虚拟PCIe设备
为虚拟机创建虚拟PCIe设备,虚拟PCIe设备的寄存器规划和DMA信息是物理PCIe设备在虚拟机中的映射。
QEMU中PCI设备直通时vfio-pci注册流程见图3.1.3.1:
图3.1.3.1
QEMU中PCI设备直通时vfio-pci初始化流程见图3.1.3.2:
图3.1.3.2
3.2 PCI设备直通数据面加速
PCI设备直通时,GuestOS中的设备驱动操作虚拟PCI设备的DMA时,QEMU会将上述操作通过VFIO接口下发给物理PCI设备的DMA,物理设备DMA收到GuestOS中的物理地址GPA,通过IOMMU的映射,找到Host主机物理内存的物理地址HPA,达到物理PCI设备直接访问GuestOS中的GPA,从而达到数据数据面加速。
3.2.1 GPA->HPA的映射过程
对于直通的设备,QEMU创建虚拟机时需要两方面的地址映射,见图3.2.1.1:
1)VM在创建时GuestOS的内存需要QEMU调用KVM最终通过EPT和MMU建立GVA->GPA->HPA的映射;
2)QEMU进行VM的虚拟PCI设备初始化时,会将HVA和GPA下发给IOMMU,
让IOMMU建立GPA到HPA的映射关系。
当GuestOS中直通设备的驱动分配内存并配置DMA时,QEMU通过VFIO接口将GPA下发到PCI Device的DMA,DMA读取数据时经由IOMMU映射,找到相应的HPA。
推荐阅读
-
理解 PCIe 虚拟化技术:什么是 PCIe 虚拟通道?
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。