社区编辑申请
注册/登录
NFV关键技术:计算虚拟化之IO虚拟化
开发 开发工具 数据中心
现实中的外设资源是有限的,为了提高资源的利用率,满足多个虚拟机操作系统对外部设备的访问需求,VMM必须通过I/O虚拟化的方式来实现资源的复用,让有限的资源能被多个虚拟机共享。

Labs 导读

现实中的外设资源是有限的,为了提高资源的利用率,满足多个虚拟机操作系统对外部设备的访问需求,VMM必须通过I/O虚拟化的方式来实现资源的复用,让有限的资源能被多个虚拟机共享。

1、IO虚拟化概述

如何将服务器上的物理设备虚拟化为多个逻辑设备,并将物理设备与逻辑设备解耦,使虚拟机可以在各个虚拟化平台间无缝迁移,正是I/O虚拟化的目标。I/O虚拟化的基本要求主要有以下的三点:

  • 保真性,要求在虚拟化平台下进行的I/O访问与非虚拟化条件下的I/O访问除了完成时间差别外,其它效果相同;
  • 安全性,要求各虚拟机操作系统只能访问VMM分配给其的I/O资源,而各I/O设备也只能与属于同一个虚拟机的其它资源进行交互,如存储空间和CPU,而不能越界访问属于其它虚拟机的资源;
  • 性能,要求虚拟化系统下I/O访问的性能与非虚拟化系统下的I/O访问性能接近。

在这三个基本要求之中最为重要的就是安全性方面的要求,这是保证虚拟化环境可以正常运行的根本,只有首先满足这一要求才能保证虚拟化I/O的保真性,对于性能的要求才会有意义。虚拟化环境下之所以会出现安全性的问题是因为虚拟机操作系统可见的地址并不是实际的机器物理地址,而是客户物理地址,设备若无法获知客户物理地址和机器物理地址间的转换关系,直接使用客户物理地址进行内存访问,这会导致非法地址访问、破坏正常数据。

正是由于I/O虚拟化对于I/O空间安全隔离性方面的要求,所以对于虚拟机操作系统的I/O访问操作一般都需要VMM的介入,而不允许虚拟机操作系统与I/O设备直接进行交互,导致虚拟机操作系统的I/O访问会受到VMM干预,导致性能与非虚拟化环境有较大差距。而VMM介入之所以会导致性能严重损失的根本原因就是发生了上下文切换。

上下文切换分为两种,虚拟机与虚拟机之间发生的上下文切换以及虚拟机与VMM之间发生的上下文切换。在I/O虚拟化中影响性能的就是虚拟机和VMM之间的上下文切换。虚拟机操作系统产生的I/O请求会被VMM截获,VMM将I/O请求交由驱动域去处理,驱动域完成I/O请求要返回执行结果,这些过程都会造成上下文切换。虚拟机和VMM之间的上下文切换的开销主要分为以下三个部分:

  • 直接开销,这个部分主要由CPU的切换造成,CPU需要停滞虚拟机切换到VMM去执行,之后又要从VMM转回虚拟机执行下一条指令。
  • 间接开销,两种环境的切换导致需要保存上下文环境。
  • 同步开销,这个部分主要是VMM处理VM EXIT造成的。

因此,一旦发生大量的上下文切换,将严重影响I/O虚拟化的性能,尤其在I/O密集型的任务中,上下文切换导致的开销往往是无法忍受的。为了解决性能的问题,通过DMA重映射、IOMMU等硬件辅助,实现了域间隔离和设备地址转换,保证被分配给虚拟机的设备不会访问不属于该虚拟机的存储器空间。

I/O虚拟化在具体实现上与CPU和内存虚拟化一样,分为软件与硬件虚拟化;在被虚拟机访问的方式上,又分为共享模式与直接访问模式。

2、软件I/O虚拟化技术

软件I/O虚拟化通过软件模拟设备的方式,使得I/O设备资源能够被多个虚拟机共享,该方式可使I/O设备的利用率得到极大的提高,并且可以做到物理设备与逻辑设备分离,具有良好的通用性,但由于该方式需要VMM的介入而导致多次上下文切换,使得I/O性能受到影响。其本质是VMM需要截获虚拟机操作系统对外部设备的访问请求,通过软件的方式模拟出真实的物理设备的效果,这样,虚拟机看到的实际只是一个虚拟设备,而不是真正的物理设备,这种模拟的方式就是I/O虚拟化的一种实现,下图所示就是一个典型的虚拟机I/O模型。

为了达到虚拟化I/O的目的,VMM截获客户操作系统对设备的访问请求,然后通过软件的方式来模拟真实设备的效果。I/O虚拟化中的设备对软件来说,就是一堆的寄存器(I/O端口)和I/O内存,以及中断和DMA。而设备虚拟化的过程,就是模拟设备的这些寄存器和内存,然后截获Guest OS里面对I/O端口和寄存器的访问,然后通过软件的方式来模拟真实的硬件。软件I/O虚拟化需要解决3个问题:

设备发现: 需要控制各虚拟机能够访问的设备。

所谓设备发现就是VMM必须采取某种方式,使得虚拟机能够发现虚拟设备。这样,虚拟机才能够加载相应的驱动程序。

在没有虚拟化的系统中,由BIOS或者操作系统通过遍历PCI总线上的所有设备完成设备发现过程,而在虚拟化系统中,则由VMM决定向虚拟机呈现哪些设备。具体过程要根据设备是否存在于物理总线上来进行。对于一个真实存在于物理总线的设备,如果是不可枚举的类型,例如PS/2键盘,由于这类设备是硬编码固定的,驱动程序会通过其特定的访问方式来检查设备是否存在,因此VMM只要在相应端口上模拟出该设备,虚拟机即可成功检测到它;如果是可枚举的类型,譬如PCI设备或者PCIe设备,这种设备通常定义了完整的设备发现方法,并允许BIOS或者操作系统在设备枚举过程中通过PCI配置空间对其资源进行配置。因此VMM不仅要模拟这些设备本身的逻辑,还要模拟PCI总线的一些属性,包括总线拓扑关系及相应设备的PCI配置空间,以便虚拟机OS在启动时能够发现这些设备。

VMM不仅可以模拟真实设备,还可以实际并不存在的虚拟设备。由于这类设备并没有现实中的规范和模型与之相对应,因此完全由VMM决定它们的总线类型。这类虚拟设备可以挂载在已有PCI总线上,也可以完全自定义一套新的总线。若使用自定义的新总线,则必须在虚拟机中加载特殊的总线驱动程序,且影响虚拟机在不同虚拟化平台的迁移性。

访问截获: 通过I/O端口对设备的访问。

所谓访问截获就是虚拟机操作系统发现虚拟设备之后,虚拟机上的驱动程序就会按照特定接口访问这个虚拟设备。驱动程序对于接口的调用必须能够被VMM截获,并能按照真实设备的行为进行模拟。

以分配到端口I/O资源的设备为例,由于CPU对于端口I/O资源的控制与指令流所处的特权级别和相关 I/O位图有关,而在虚拟化环境中虚拟机OS又被降级到非特权级别,因此OS能否访问设备的I/O端口就完全由I/O位图决定。对于没有直接分配给虚拟机的设备,VMM就可以把它的I/O端口在I/O位图中关闭,当 虚拟机操作系统在访问该端口时,就会抛出一个保护异常,VMM即可获得异常原因,并进而将请求发送给底层设备模拟器进行模拟,并异常访问处理结果返回给虚拟机;如果该设备是直接分配给虚拟机,那么VMM就可以在I/O位图中打开它的I/O端口,这样虚拟机驱动程序就可以直接访问该设备。

同理,对于分配到MMIO(Memory Mapped I/ O)资源的设备,比如某些PCIe设备,由于MMIO是系统物理地址空间的一部分,物理地址空间由页表管理,因此VMM同样可以通过控制MMIO相应的页表项是否有效来截获虚拟机操作系统对于MMIO资源的访问。

设备模拟:通过软件的方式模拟真实的物理设备

所谓设备模拟就是模拟设备的功能,内容十分多样且复杂。对于像PS/2键盘、鼠标这样的设备,VMM需要根据设备的接口规范模拟设备的所有行为,才能够无需修改驱动就在虚拟机上展现出设备应有的效果。而对于磁盘存储系统,则不必受限于实际的磁盘控制器以及具体磁盘类型和型号。比如,对IDE硬盘其I/O端口虚拟化时,底层可以是一块磁盘,可以是一个分区,也可以是不同格式的文件;然后在其上实现一个专门的块设备抽象层;最后在块设备上使用文件系统,并引入一些真实硬件没有的高级特性,例如:加密、备份、增量存储等。

上述三个环节仅是VMM处理一个虚拟 机所发出I/O请求的流程。在实际中,系统的物理设备需要同时接受来自多个虚拟 机的I/O请求。因此,VMM还要将多个虚拟机的I/O请求合并为单独一个I/O数据流发送给底层设备驱动。当VMM收到来自底层设备驱动完成I/O请求的中断时,VMM还要能够将中断响应结果转发给正确的虚拟机,以通知其I/O操作结束。同时VMM在调度各个虚拟机发送来的I/O请求处理时,必须依据一定的算法确保虚拟机I/O的QoS与设备共享的公平性。

在实现架构上,软件I/O虚拟化技术主要包括Hypervisor全虚架构和前端/后端的半虚架构来说实现。

2.1 全虚拟化---模拟模型

即完全使用软件来模拟真实硬件,模拟通常硬件,例如键盘鼠标。该架构使用最为广泛的I/O设备虚拟化模型,采用软件的方式模拟设备行为,为虚拟机模拟出与底层硬件完全一致的虚拟化环境,保证虚拟机操作系统的行为与非虚拟化环境下完全一致。在模拟模型中,虚拟设备必须以某种方式让虚拟机可以发现,导致虚拟机被“欺骗”。当虚拟机访问虚拟设备时,访问请求被VMM截获,然后VMM将I/O请求交由domain0来模拟完成,最后将结果返回给虚拟机。如下图所示是一个基于设备模拟的xen的I/O虚拟化模型。

这种架构最大的优点在于不需要对虚拟机操作系统内核做修改,也不需要为改写其原生驱动程序,因此,这种架构是可移植性与兼容性最佳的一种I/O设备虚拟模型,这也是它被如此广泛使用的主要原因,除了Xen架构的全虚模型外,VMware的Workstations和ESX都有类似的全虚模型,且是全虚模型的典型代表。

但是,全虚模型有一个很大的不足之处,即性能不够高,主要原因有两方面:第一、模拟方式是用软件行为进行模拟,这种方式本身就无法得到很高的性能;第二、这种模型下I/O请求的完成需要虚拟机与VMM多次的交互,产生大量的上下文切换,造成巨大开销。模拟IO虚拟化方式的最大开销在于处理器模式的切换:包括从Guest OS到VMM的切换,以及从内核态的VMM到用户态的IO模拟进程之间的切换。

在全虚拟化,由于VMM实现模式不同,采用的设备虚拟化方式也不同。比如,全虚拟化最有代表性的VMware ESX和VMWare Workstattion。

在VMware ESX中,VMM直接运行在物理硬件之上,直接操作硬件设备,而Guest OS看到的则是一组统一的虚拟IO设备。Guest OS对这些虚拟设备的每一个IO操作都会陷入VMM 中,由VMM对IO指令进行解析并映射到实际的物理设备,然后直接控制硬件完成。

而VMWare WorkStation采用了不同的方式。VMM实际上运行在一个传统的操作系统之上,这类VMM无法获得对硬件资源的完全控制,因此采用软件模拟的方式来模拟IO设备。Guest OS的IO操作会被VMM捕获,并转发给宿主机(host OS)的一个用户态进程,该进程通过对宿主机操作系统的系统调用来模拟设备的行为。

以下是VMware的ESX架构,VMkernel负责管理虚拟机对于网络和存储设备的访问。通过设备模拟术,不同的物理设备对于虚拟机可以呈现为某种特定的虚拟设备,甚至并不存在的虚拟设备。

对于存储,物理服务器上部署的可能是某种SCSI设备、磁盘阵列甚至是SAN存储网络,但是ESX能够模拟出BusLogic或者LSILogic的SCSI适配器,因此对于虚拟机总是呈现为SCSI设备。而对于网络ESX则模拟为AMD Lance适配器或者一个并不存在的自定义接口vmxnet,来帮助虚拟机对网络的问。上图显示了在ESXi服务器内部经过的I/O路径。其中,虚拟机分别使用vmxnet虚拟网络适配器与LSI Logic虚拟SCSI适配器对网络和存储进行访问,而物理服务器则使用Intel e1000网卡连接到SAN网络的QLogic光纤HBA卡。

  • 第1步所示,虚拟机中的某个应用程序通过操作系统发起I/O访问,比如发送一个网络数据包或者向磁盘写入一个文件;
  • 第2步表示操作系统对其进行处理,并调用设备驱动处理相应的I/O请求;
  • 第3步表示当设驱动试图访问外设时,VMM拦截到该操作并将控制权切换到Vmkernel;
  • 第4步为VMkernel获得控制权后,I/O请求会被转发到与设备无关的网络或者存储抽象层进行处理;
  • 第5步表示VMkernel还会同时接收到来自其他虚拟机的多个I/O请求,并对这些I/O请求按照特定算法进行优先级调度处理。

I/O请求最终会被转发到具有物理设备驱动程序的硬件接口层进行处理。当I/O请求的完成中断到达时,I/O处理过程则与上述路径完全相反。VMkernel中设备驱动会将到达的中断保护起来,并调用VMkernel来处理该中断;接下来VMkernel会通知相应虚拟机的VMM进程,VMM进程会向虚拟机发起中断,以通知I/O请求处理完毕;同时VMkernel还要确保I/O处理完毕的相关信息与其他虚拟机的数据相互隔离。

由于上述过程需要VMkernel处理I/O请求,因此从虚拟机到VMkernel上下文的切换过程会导致一定的开销。为了降低开销,vmxnet在收发数据包之前,会收集一组数据包再转发给各个虚拟机或者一起发送出去。对于多个虚拟机之间的设备资源管理方面,对于网络ESX采用了流量整形的方式限制每个虚拟机的总带外流量;对于存储ESX实现了比例公平的算法平衡多个虚拟机之间磁盘访问带宽。

2.2 半虚拟化---泛虚拟化模型

即属于前后端驱动模型的IO虚拟化,也称为分离驱动模型。泛虚拟化模型是被广泛使用的另一种I/O设备虚拟化模型。相比于全虚模型而言,泛虚拟化模型在性能上有很大的提升。主要有以下两个原因:

  • 一是该模型采用了I/O环机制(一种大块多队列聚合传输技术,支持I/O环适配功能的虚拟机操作系统,只有安装了Tools才能使用到IO环适配功能),减少了虚拟机与VMM之间的切换;
  • 二是该模型摒弃了传统的中断机制,而采用事件或回调机制来实现设备与客户机间的通信。进行中断处理时,传统的中断服务程序需要进行中断确认和上下文切换,而采用事件或回调机制,无需进行上下文切换。如下图所示是一个基于泛虚拟化的Xen的I/O虚拟化模型。

前端/后端架构也称为“Split I/O”,即将传统的I/O驱动模型分为两个部分,一部分是位于客户机OS内部的设备驱动程序(前端),该驱动程序不会直接访问设备,所有的I/O设备请求会转发给位于一个特权虚机的驱动程序(后端),后端驱动可以直接调用物理I/O设备驱动访问硬件。前端驱动负责接收来自其他模块的I/O操作请求,并通过虚拟机之间的事件通道机制将I/O请求转发给后端驱动。后端在处理完请求后会异步地通知前端。相比于全虚模型中VMM需要截获每个I/O请求并多次上下文切换的式,这种基于请求/事务的方式能够在很大程度上减少上下文切换的频率,并降低开销。但是这种I/O模型有一个很大的缺点,要修改操作系统内核以及驱动程序,因此会存在移植性和适用性方面的问题,导致其使用受限。下满以Xen架构的模型为例说明:

在Xen架构的半虚拟化模型中,通过修改Guest OS的内核,将原生的设备驱动从Guest OS移出,放到一个特殊的设备虚拟机中Dom0了,其余虚拟机中的I/O请求都由设备虚拟机处理。而在Guest OS内部,为每个虚拟设备安装一个特殊的驱动程序,由该驱动程序负责I/O请求的传递,设备虚拟机经过VMM授权,解析收到的请求并映射到实际物理设备,最后交给设备的原生驱动来完成IO。实际上在这种情况下,Guest OS的驱动是消息代理的作用,把I/O事件转换为消息,发送给设备虚拟机处理。具体前后端驱动配合实现物理设备驱动功能,需要通过以下几步实现:

Step1:如何实现设备发现?

  • 所有VM的设备信息保存在Domain0的XenStore中。
  • VM中的XenBus (为Xen开发的半虚拟化驱动)通过与Domain0的XenStore通信,获取设备信息。
  • 加载设备对应的前端驱动程序。

Step2:如何实现设备数据截获?

  • 前端设备驱动将数据通过VMM提供的接口全部转发到后端驱动。
  • 后端驱动VM的数据进行分时分通道进行处理。

Step3:如何模拟使用IO设备

Domain U中虚拟机程序使用IO设备时,通过前端驱动Front-End Driver由XenBus总线访问Domain 0中的Back-End Driver,Back-End Driver通过XenStor中记录的IO设备信息,找到真实的设备驱动Native Driver去访问真实IO设备。

需要注意一点:这种前后端驱动架构的瓶颈就是Domain 0,因为Domain 0通过XenBus总线采用时分复用的策略与前端多个DomainU联动。

3、硬件I/O虚拟化技术

为了改善I/O性能,旨在简化I/O访问路径的设备直通访问方式又被提了出来。代表技术为Intel公司出 的VT-d与AMD公司的IOMMU技术。尽管这两种技术在一定程度上提高了I/O访问性能,但代价却是限制了系统的可扩展性。目前PCI-SIG提出的SR-IOV与MR-IOV是平衡I/O虚拟化通用性、访问性能与系统可扩展性的很好的解决方案。

3.1 IO透传---设备直接分配模型,即直接分配给虚拟机物理设备

软件实现I/O虚拟化的技术中,所有的虚拟机都共享物理平台上的硬件设备。如果物理条件好,有足够的硬件,就可以考虑让每个虚拟机独占一个物理设备,这样无疑会提高系统的性能。把某一个设备直接分配给一个虚拟机,让虚拟机可以直接访问该物理设备而不需要通过VMM或被VMM截获,这就是设备直通技术。如下图所示为设备直接分配的I/O模型。

在设备直接分配模型中,虚拟机操作系统可直接拥有某一物理设备的访问控制权限,VMM不再干涉其访问操作。因此,该模型可以较大地改善虚拟化设备的性能,降低VMM程序的复杂性,易于实现,并且不需要修改操作系统,保证了高可用性。

设备直接分配模型虽然在性能上相比软件方式的两种I/O设备虚拟化模型有着很大的提升,但是该模型的使用也是有一定限制的。因为该模型将一件物理设备直接分配给了一个虚拟机,其它虚拟机是无法使用该设备的,所产生的一个问题就是如果其它虚拟机需要访问该设备则无法满足需求,解决办法就是物理资源充分满足需求或者通过硬件虚拟化技术虚拟出多个IO设备(与物理设备性能极为接近)供多个虚拟机使用(硬件必须支持)。

3.2 Intel的设备硬件虚拟化技术---VT-d

VT-d,即VT for Direct I/O,主要在芯片组中实现,允许虚拟机直接访问I/O设备,以减少VMM和CPU的负担,如下图画红框部分。

Intel公司提出的VT系列技术中VT-d其目的就是让虚拟机直接访问物理机底层I/O设备,使虚拟机能够使用自己的驱动直接操作I/O设备,而无需VMM的介入和干涉。通过引入DMA重映射,VT-d不仅可以使虚拟机直接访问设备,同时还提供了一种安全隔离机制,防止其他虚拟机或者VMM访问分配给指定虚拟机的物理内存。VT-d中DMA重映射原理如下图所示:(在北桥也就是现在CPU封装中实现)

具体来说,VT-d技术在北桥引入了DMA重映射技术,并通过两种数据结构(Root Entry 和 Context Entry)维护了设备的I/O页表。设备上的DMA操作都会被DMA重映射硬件截获,并根据对应的I/O页表对DMA中的地址进行转换,同时也会对要访问的地址空间进行控制。

在具体实现上,VT-d使用PCI总线中的设备描述符BDF(Bus Device Function)来标示DMA操作发起者的标示符。其次,VT-d使用两种数据结构来描述PCI总线结构,分别是根条目(Root Entry)和上下文条目(Context Entry)。如下图所示,其中根条目用于描述PCI总线。由于PCI总线个数可以达到256个,因此根条目的范围是0~255,其中每个根条目的一个指针字段都指向该总线的所有PCI设备的上下文条目表指针(Context Table Pointer,CTP)。由于一个PCI总线可以包含256个设备,因此上下文条目表的范围也是0~255 。在每个上下文条目中都包含两个重要字段:地址空间根(Address Space Root,ASR) 指向该设备的I/O页表;域标示符(Domain ID,DID)可以理解为唯一标示一个虚拟机的标示符。

基于这种方式,当某一个设备发起DMA操作及被DMA重映射硬件截获时,通过该设备的BDF中的Bus字段,可以找到其所在的根条目。根据device和function字段,可以索引到具体设备的上下文条目。这样就可根据上下文条目中的ASR字段找到该设备的I/O页表,再通过DMA重映射硬件将I/O请求的GPA转换为HPA,从而达到设备直接访问虚拟机内存的目的。

使用VT-d将设备直接分配给虚拟机的I/O访问性能十分接近无虚拟化环境下的I/O访问性能,然而VT-d事实上是一种I/O设备被虚拟机独占的方式,这种方式牺牲了虚拟化平台中的设备共享能力,设备用率大大降低,而且系统的可扩展性受到物理平台插槽个数的限制。比如,假定一个服务器配置4个CPU,每个CPU为8核,按照平均分配方式每个虚拟机一个核,则可以创建32个虚拟机,如果按照备 直接访问的方式分配网卡,则需要32个物理插槽,这是不现实的。

VT-d还为DMA重映射提供了安全隔离的保障。上图是没有VT-d技术与有VT-d技术的虚拟化平台的对比。可以看出,图(a)部分没有VT-d虚拟化技术的平台中,物理设备的DMA操作可以访问整个系统内存。而图(b)有VT-d技术的平台中,对设备DMA操作的地址范围进行了限制,只能访问指定的地址空间。

除了DMA重映射外,VT-d还提供了中断重映射功能,有兴趣的可以参考Intel官网的VT技术手册。

3.3 VMDq和VMDc技术

在集群和数据中心这类环境中,每台主机通常同时运行大量的虚拟机。由于主机的网络设备数目有限,多个虚拟机不得不复用同一个网络设备,从而导致性能下降。Intel VT-c 技术可针对虚拟化进一步优化网络性能。VT-c 包括如下两个关键技术:

3.3.1 虚拟机设备队列(Virtual Machine Device Queues,VMDq)

收到一个数据包时,VMM必须将其分类以确定应该转发给哪个虚拟机,这占用了大量宝贵的处理器资源。如果以太网控制器支持 VMDq 技术,VMM可以为虚拟机使用不同的数据包队列,以太网控制器自动分类数据包并投放到相应的队列中,大大减轻VMM的负担,提高了I/O吞吐量,如下图所示。

而Intel所使用的VMDq就是通过网卡芯片內建的 Layer 2 classifier / sorter 以加速网络数据传送,它可以先行將不同的虚拟机所需的网络数据包,直接在芯片里规划好,然后再通过 receive queue直送给虚拟机。这样就不用送过虚拟交换机转发数据包减少网络的负载与CPU的开销,有VMDq和没VMDq的对比如下:

3.3.2 虚拟机直接连接(Virtual Machine Direct Connect,VMDc)

这是Intel借鉴了SR-IOV技术的特点。与SR-IOV技术一样,支持该技术的网络设备能够对外展现出多个虚拟功能接口VF(Virtual Function)。每个功能接口相当于一个网络设备,VMM可将其直接分配给某个虚拟机,从而“避免”了网络设备的复用。例如,VMM仅用单个英特尔万兆位服务器网卡,可为10个客户机操作系统分配独立受保护的1Gb/秒的专用链路,VMM无需继续管理这些直接通信链路,进一步提升I/O性能并减少主机CPU的负载 。

3.4 SR-IOV与MR-IOV:PCIe的虚拟化

如前所述,软件设备模拟尽管实现了物理与逻辑的分离,但是性能受到影响;VT-d或者IOMMU技术则以牺牲系统扩展性为代价获得近似于直接访问设备的I/O性能,而且其中任何一种都不是基于现有的工业标准。因此,业界希望重新设计一种可以原生共享的设备。具有原生共享特性的设备可同时为多个虚拟机提供单独的内存空间、工作队列、中断与命令处理,使得设备的资源能够在多个虚拟机之间共享。同时,这些设备能够从多个源端同时接收命令,并将其合并再一起发送出去。因此,原生共享设备不需要VMM模拟设备,同时也在硬件层次上使得多个虚拟机同时访问设备,很好地兼顾了虚拟化系统的性能与可扩展性。

PCI-SIG组织提出了一个新的技术规范:SR-IOV(Single Root I/O Virtualization)。该规范定义了一个单根设备(如 一个以太网卡端口)如何呈现为多个虚拟设备。在SR-IOV中,定义了两个功能类型:一是物理功能类型PF,负责管理SR-IOV设备的特殊驱动,其主要功能是提供设备访问功能和全局共享资源配置的功能,虚拟机所有影响设备状态的操作均需通过通信机制向PF发出请求完成。二是虚拟功能类型VF是轻量级的PCIe功能,包含三个方面:向虚拟机操作系统提供的接口;数据的发送、接收功能;与PF进行通信,完成全局相关操作。由于VF的资源仅是设备资源的子集,因此VF驱动能够访问的资源有限,对其它资源的访问必须通过PF完成。

上图是一个支持SR-IOV的网卡配置。其中左侧三个VM是通过VF可以直接分配到的网卡资源,而该网卡的PF所具有的完整资源仍能用于最右侧两个虚拟机对模拟设备的访问路径。一个具备SR-IOV特性的设备通过VMM配置可以在PCI配置空间中呈现为多个VF,每个VF都配置了基地址寄存器(Base Address Register,BAR)的完整配置空间。VMM通过将一个或多个VF的配置空间映射到虚拟机的PCI配置空间中实现VF的分配。结合VT-d内存映射等技术,虚拟机可以直接访问VF的内存空间,这就 能绕过VMM直接访问I/ O设备。如下图所示:

SR-IOV还实现了地址转换服务(Address Translation Service,ATS)来提供更好的性能。通过缓存TLB到本地,I/O设备可以在发起PCI事务之前直接对DMA地址进行转换,这样就避免了在IOMMU中进行地址转换时可能发生的缺页情况。通过这种方式,绑 定到VF的虚拟机可 获得与基于硬件I/O虚拟 化虚拟机接近的性能。但是与基于硬件I/O虚拟化较低的可扩展性相比,一个SR-IOV设备可以具有几百个VF,因此SR-IOV具有更好的可扩展性。

MR-IOV(Multiple Root I/O Virtualization)扩展了SR-IOV规范。MR-IOV允许PCIe设备在多个有独立PCI根的系统之间共享,这些系统通过基于PCIe转换器的拓扑结构与PCIe设备或者PCIe-PCI桥相接。MR-IOV与SR-IOV相比,每个VH(Virtual Hierarchy,一个VH就是一个虚拟独立的SR-IOV设备)拥有独立的PCI Memory,IO,配置空间。如下图是MR-IOV的作用,本来每个系统只有一个Host,两个PCIe设备,但是有了MRA Switch之后,系统里面有2个Host,4个PCIe设备。

MR-IOV里有个重要概念:VH,Virtual Hirearchy:每个VH至少包含一个PCIe Switch,这个PCIe Switch是MRA Switch里面的一个虚拟组件。每个VH可以包含各种PCIe设备、MRA PCIe设备、或者PCIe-PCI桥的组合。如下图,在MRA PCIe Switch中,可以有多个根端口Root Port,RP。

这样,有了MR-IOV之后,软件系统变成了下面这种,物理机之间也能相互通信,PCIe设备被多台物理机共享。下图中的SI就是虚拟机OS、VI就是虚拟机监视器VMM。

【本文为51CTO专栏作者“移动Labs”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

 

责任编辑:未丽燕 来源: 移动Labs
相关推荐

2021-06-17 13:28:20

2021-12-21 15:46:16

2022-04-12 14:11:27

存储虚拟化软件定义服务器

2021-05-17 14:57:22

NFV虚拟化数据

2021-08-20 11:22:05

2015-04-23 09:16:50

SDNNFV网络虚拟化

2015-10-08 17:37:42

SDNNFV网络虚拟化

2015-10-09 13:13:30

网络虚拟化SDN

2018-10-09 10:38:09

2019-02-25 12:06:02

5GNFV虚拟化

2014-10-27 09:41:18

2017-04-17 14:15:31

2014-03-04 11:49:01

网络虚拟化NFVSDN

2015-03-18 15:46:58

2014-02-21 10:56:48

网络虚拟化

2021-08-20 11:12:31

2020-05-21 10:41:04

NFVVNF网络虚拟化

2018-04-11 14:56:47

2017-11-29 14:57:47

2017-05-04 10:53:27

虚拟机运营商NFV

同话题下的热门内容

使用VScode的几点感受,对比Pycharm、Jupyter优劣势用 Antlr 重构脚本解释器GitHub 添加工具以简化软件开发管理

编辑推荐

终于有人把Elasticsearch原理讲透了!花了一个星期,我终于把RPC框架整明白了!这可能是把ZooKeeper概念讲的最清楚的一篇文章论如何下载一个在线的m3u8文件到本地成为一个mp4!拜托!面试不要再问我Spring Cloud底层原理
我收藏的内容
点赞
收藏

51CTO技术栈公众号