CN103282881A - 通过虚拟化直接共享智能设备 - Google Patents

Abstract

在一些实施例中，使得设备能够直接运行虚拟机工作负荷。在来自不同虚拟机的工作负荷之间提供隔离和调度。描述并要求保护其它实施例。

Description

通过虚拟化直接共享智能设备

技术领域

本发明一般涉及通过虚拟化直接共享智能设备。

背景技术

先前已经使用设备模型实施了输入/输出（I/O）设备虚拟化，以执行全部设备仿真。这允许共享设备，但是具有巨大的性能开销。将设备的设备分配指向虚拟机（VM）允许接近本机性能，但是并不允许设备在VM之间的共享。最近的基于硬件的设计（例如，单根I/O虚拟化（SR-IOV））允许设备在共享的同时展示接近本机性能，但是需要对硬件做出显著改变。

附图说明

根据以下的详细描述以及本发明一些实施例的附图，可以更全面地理解本发明，但是所述附图不应被认为将本发明限制到具体描述的实施例，而是仅用于解释和理解。

图1示出了根据本发明一些实施例的***。

图2示出了根据本发明一些实施例的流程。

图3示出了根据本发明一些实施例的***。

图4示出了根据本发明一些实施例的***。

图5示出了根据本发明一些实施例的***。

具体实施方式

本发明的一些实施例涉及通过虚拟化直接共享智能设备。

在一些实施例中，设备能够直接运行虚拟机工作负荷。在不同虚拟机的工作负荷之间提供分离与调度。

在一些实施例中，在实现高性能输入/输出（I/O）设备虚拟化的同时，在多个虚拟机（VM）之间共享所述I/O设备。在一些实施例中，设备仿真和直接设备分配的混合技术提供了基于设备模型的直接执行。根据一些实施例，提供对基于单根I/O虚拟化（SR-IOV）设计的替代，其中与SR-IOV相比仅对硬件做出少量改变。根据一些实施例，开发现代设备（例如，现代设备诸如通用图形处理单元或GPGPU）中更高度的可编程性，在VM中提供了接近本机I/O性能。

图1示出了根据一些实施例的***100。在一些实施例中，***100包括设备102和虚拟机监视器（VMM）104。在一些实施例中，***100包括虚拟机VM1106、虚拟机VM2108，以及Dom0（或者零域）110，所述Dom0例如是在根上由VMM104共享的第一域。在一些实施例中，设备102是I/O设备、图形处理单元或GPU和/或通用图形处理单元或GPGPU，例如英特尔的Larrabee图形处理单元。

在一些实施例中，设备102包括操作***（OS）112（例如，基于完全FreeBSD的OS，称为微OS或uOS）。在一些实施例中，OS112包括调度程序114和驱动程序116（例如，主机驱动程序）。在一些实施例中，设备102包括驱动应用118、驱动应用120、设备卡122、存储器映射输入/输出（MMIO）寄存器和GTT存储器124、图形窗孔（graphics aperture）126、显示器接口128，和显示器接口130。在一些实施例中，VMM104是Xen VMM和/或开源VMM。在一些实施例中，VMM104包括建立在132处的EPT页面表和VT-d扩展的能力。在一些实施例中，VM106包括应用134（例如，DX应用）、运行时136（例如，DX运行时）、设备UMD138，和内核模式驱动程序（KMD）140（和/或仿真设备）。在一些实施例中，VM108包括应用144（例如，DX应用）、运行时146（例如，DX运行时）、设备UMD148，和内核模式驱动程序（KMD）150（和/或仿真设备）。在一些实施例中，零域（Dom0）110包括主机内核模式驱动程序（KMD）152，其包括虚拟主机扩展154。在一些实施例中，Dom0110包括处理器仿真器QEMU VM1156，其运行作为主机VMM并包括设备模型158。在一些实施例中，Dom0110包括处理器仿真器QEMU VM2162，其运行作为主机VMM并包括设备模型164。

根据一些实施例，以如下方式执行I/O设备102的虚拟化：提供高性能和在VM106和108间共享设备102的能力，而不需要显著的硬件改变。这是通过修改设备102的硬件和软件/固件以使得设备102知道VMM104和一个或多个VM（例如，VM106和108）而完成的。这使得设备102能够以提供高性能的方式直接与各VM（106和108）进行交互。设备102还负责提供来自不同VM的工作负荷之间的隔离和调度。然而，为了最小化对设备102的硬件的改变，该技术还需要VMM104中的传统设备仿真模型，其仿真与物理设备102相同的设备。通过设备模型164来俘获和仿真VM106和108对设备102的低频访问（例如，访问来完成设备设置），但是高频访问（例如，向设备发送数据/从设备接收数据、中断等）直接引向设备102，以避免昂贵的VMM104介入。

在一些实施例中，VMM104中的设备模型向VM106或108呈现虚拟设备，其与实际的物理设备102相同，并且处理对设备资源的所有低频访问。在一些实施例中，该模型还建立对高频设备资源的直接VM访问。在一些实施例中，VMM部件104以使得设备102虚拟化感知并且使其能够直接与多个VM106和108会话的方式形成于设备102上。该部件处理所有的高频VM访问并使得设备能够共享。

根据一些实施例，与单根I/O虚拟化（SR-IOV）设计相比，需要对设备102的硬件进行最小的改变。对在设备102上运行的软件部件进行修改以包括VMM104部件，并且通过该VMM部件卸载VMM对设备本身的高频VM访问的VMM处理。

根据一些实施例，设备102是非常智能的设备，并且是高度可编程的（例如GPU，在一些实施例中为诸如英特尔的Larrabee GPU）。根据一些实施例，设备102运行基于完全FreeBSD的OS112，其被称作微OS或uOS。在一些实施例中，设备卡在VM106和108（根据一些实施例，为WindowsVista VM）之间进行共享。VM106和108直接将工作提交给设备102，这导致接近本机性能。

在一些实施例中，使用Xen（开源VMM）实现VMM104。在一些实施例中，利用Xen编写虚拟设备模型，以向VM106和108中的每个提供仿真设备。该模型还向VM106和108提供对设备102的图形窗孔126的直接访问，使得VM106和/或108能够直接向设备102提交工作。还使用对主机驱动程序的设备扩展，以使得设备模型164能够控制某些方面的设备操作。对于设备102上的VMM部件，根据一些实施例修改驱动器116以使其虚拟化感知，并使其直接从多个VM处接收工作。VM106或108中的图形应用开始设备102侧的OS112应用。然后VM应用134或144将工作负荷数据发送到相应的设备应用118或120用于处理（例如，渲染）。修改的驱动器116使得OS112能够运行来自多个VM106和108的应用118和120，就像它们是来自相同主机的多个应用一样。在独特OS应用中运行来自不同VM的工作负荷提供它们之间的隔离。在一些实施例中，OS调度程序114也被修改以使其能够调度来自不同VM的应用，从而来自一个VM的应用不会使得来自另一VM的应用饿死。

在一些实施例中，在VMM104中实现图形设备虚拟化。在一些实施例中，两个VM106和108共享单个设备卡，并且经由图形窗孔126通过直接访问在设备102上直接运行其工作负荷。根据一些实施例对OS112驱动程序116和调度程序114进行修改，以提供多个VM（例如，在应用134和144之间和/或在DX应用之间）的隔离和调度。

根据一些实施例，可实施五个主要技术来执行I/O设备虚拟化，如下：

1、全部设备仿真—在全部设备仿真中，VMM使用设备模型来仿真硬件设备。VM看到仿真的设备并试图对其进行访问。这些访问被设备模型俘获并处理。这些访问中的有些需要访问VMM中的物理设备以服务VM的请求。模型所仿真的虚拟设备能独立于***中存在的物理设备。这是该技术的一个重大优点，并且其使得VM迁移变得更简单。然而，该技术的缺点在于仿真设备具有高性能开销，从而该技术不能提供接近VM中的本机性能。

2、直接设备分配—在该技术中，将设备直接分配给VM，并且所有的设备的存储器映射I/O（MMIO）资源可由VM直接访问。这实现了VM中的本机I/O性能。但是，缺点在于设备不能由其它VM共享。另外，VM迁移变得更复杂。

3、VM中的准虚拟化（para-virtualized）驱动程序—在该方法中，准虚拟化驱动程序加载到与VMM驱动程序会话的VM内部以能够共享。在该技术中，虚拟设备能够独立于物理设备，并能实现比基于设备模型的方法更好的性能。然而，该方法的缺点在于其需要VM内部的新的驱动程序，并且性能仍旧不接近设备分配所达到的性能。另外，虚拟设备语义与物理设备语义之间的转换实施起来比较复杂，并且经常不能完成特征（例如，图形虚拟化中的API代理）。

4、间接传递（MPT）或辅助驱动程序传递（ADPT）—VMM销售商最近提出一种准虚拟化驱动程序的改进技术，称为MPT或ADPT，其中仿真虚拟设备与物理设备相同。这使得VM能够使用现有的设备驱动程序（进行一些修改以允许其与VMM会话）。这也避免了将VM工作负荷从虚拟设备格式转换为物理设备格式的开销（由于两个设备是相同的）。该方法的缺点在于性能仍不能接近设备分配所能达到的性能，这是因为VM仍不能直接与设备进行通信。

5、硬件方法（例如，SR-IOV）—在该方法中，对设备硬件进行修改以创建设备资源的多个实例，每个VM用一个实例。单根I/O虚拟化（SR-IOV）是一种标准，其在硬件销售商间是受欢迎的，且为这种设备制定了软件接口。其创建设备资源的多个实例（物理功能或PF以及多个虚拟功能或VF）。该方法的优点在于现在设备能够在多个VM之间进行共享，并且能在同时给出高性能。缺点在于需要对设备进行显著的硬件改变。另一个缺点在于设备资源被静态创建以支持特定数目的VM（例如，如果建造设备以支持四个VM但当前只有两个VM在运行，则其它两个VM的资源价值未被使用且对两个运行VM不可用）。

根据一些实施例，上述技术4和5的混合方法用于实现高性能可共享设备。然而，该混合方法不要求技术5所要求的大部分硬件的改变。而且，允许设备资源动态地分配给VM（而不是如技术5所述的静态分割）。由于在一些实施例中对设备上运行的硬件和软件进行修改，所以能直接与VM进行通信，导致接近本机性能（不像技术4）。类似于技术4，在一些实施例中，使用仿真与物理设备相同的虚拟设备的设备模型。设备模型以及设备软件/固件的修改避免了技术5所要求的大部分硬件改变。类似于技术2，在一些实施例中，将一些设备资源直接映射到VM，从而VM能直接与设备会话。然而，不同于技术2，在一些实施例中，以保持设备在多个VM间可共享的方式映射设备资源。类似于技术5，在一些实施例中，修改设备行为以达到高性能。然而，不同于技术5，主要修改设备软件/固件，并对硬件仅做出最小的改变，因而保持设备成本低并且降低上市时间。而且，通过改变设备软件（而不是硬件），基于需求动态分配设备资源到VM。

根据一些实施例，实现高性能I/O虚拟化，具有设备共享能力和动态将设备资源分配给VM的能力，而不要求对设备做出显著的硬件改变。当前方案中没有一个能提供所有的这四个特征。在一些实施例中，对设备软件/固件做出改变，且对硬件做出一些改变以使得设备直接运行VM工作负荷，并提供在来自不同VM的工作负荷之间的隔离和调度。

在一些实施例中，实现利用基于模型的直接执行的混合方案。在一些实施例中，对设备软件/固件进行修改，而不是创建设备硬件资源的多个实例。这使得能够在来自不同VM的工作负荷之间进行隔离和调度。

图2示出了根据一些实施例的流程200。在一些实施例中，在202处，VM请求访问设备资源（例如，设备的MMIO资源）。在204处确定MMIO资源是否是被频繁访问的资源。在204处如果不是被频繁访问的资源，则在206处VMM设备模型俘获并仿真所述请求。然后在208处VMM设备模型确保隔离和调度。在210处，VMM设备模型访问设备资源212。在204处如果所述资源是频繁访问的资源，则在214处VM使用到设备的直接访问路径。在216处，设备上的VMM部件接收VM的直接访问。然后在218处，VMM部件确保对这些访问的正确隔离和调度。在220处，VMM部件访问设备资源212。

现代设备变得越来越可编程，并且以设备上运行的软件/固件实施设备功能的重要部分。在一些实施例中，对设备硬件做出最小的改变或者没有改变是必要的。因此，根据一些实施例，对设备（例如I/O设备）的改变非常快（例如，与使用SR-IOV的硬件方法相比）。在一些实施例中，能够以非常短的时间对例如I/O设备的设备进行虚拟化。可以根据一些实施例改变设备软件/固件，以提供高性能I/O虚拟化。

在一些实施例中，用单个I/O存储器管理单元（IOMMU）表来仿真多个请求者ID。

图3示出了根据一些实施例的***300。在一些实施例中，***300包括设备302（例如，I/O设备）。设备302具有设备上的VMM部件，以及第一VM工作负荷306和第二VM工作负荷308。***300另外包括合并的IOMMU表310，其包括第一VM IOMMU表312和第二VM IOMMU表314。***300还包括主存储器320，其包括第一VM存储器304和第二VM存储器324。

设备302上的VMM部件304在工作负荷使用客户机物理地址（GPA）之前对其进行标记。工作负荷306使用标记有IOMMU表ID的GPA1访问VM1IOMMU表312，并且工作负荷308使用标记有IOMMU表ID的GPA2访问VM2IOMMU表312。

图3涉及在每个VM都能够直接访问设备用于高性能I/O时在多个VM间共享单个设备320（例如，I/O设备）的问题。由于VM直接访问设备，所以其为设备提供客户机物理地址（GPA）。设备302通过使用IOMMU表310访问VM存储器322和/或324，其中IOMMU表310在使用地址访问存储器之前将VM的GPA转换成主机物理地址（HPA）。当前，每个设备功能通过使用称为请求者ID的标识符能够使用单个IOMMU表（每个设备功能具有请求者ID）。然而，为每个VM请求不同的IOMMU表，以为VM提供个体GPA到HPA的映射。因此，因为设备功能一次仅能访问一个IOMMU表，所以功能在多个VM间不能直接共享。

图3的***300通过以下方式解决了上述问题：为单个设备功能仿真多个请求者ID，从而能够同时访问多个IOMMU表。访问多个IOMMU表使得设备功能能够同时访问多个VM的存储器并由这些VM共享。

多个IOMMU表312和314合并成单个IOMMU表310，并且设备功能使用该合并的IOMMU表。通过将每个表的映射放置在合并的IOMMU表310的不同偏移处，合并IOMMU表312和314，从而GPA的较高阶位表示IOMMU表ID。例如，如果我们假设个体IOMMU表312和314映射39个位地址（其可以映射512GB的客户存储器），并且合并的IOMMU表310能够映射48个位地址，则能够创建合并的IOMMU表，并且在偏移0处提供第一IOMMU表的映射、在偏移512GB处为第二IOMMU表、在偏移1TB处为第三IOMMU表，等等。有效高阶位39-47变为用于合并的IOMMU表310中的个体IOMMU表编号的标识符。

为了和该合并的表一起工作，修改意图用于不同IOMMU表的GPA。例如，第二IOMMU表的GPA0出现在合并的IOMMU表的GPA512GB处。这要求改变设备正在使用的地址（GPA），以在IOMMU GPA中反映该改变，从而它们使用合并的IOMMU表的正确部分。本质上，在设备访问这些GPA之前，GPA的高阶位标记有IOMMU表编号。在一些实施例中，修改设备上运行的软件/固件以执行该标记。

根据一些实施例，***300包括两个重要的部件。VMM部件304创建合并的IOMMU表310，并让设备功能使用该IOMMU表。另外，从VM接收GPA并将其标记有IOMMU表编号的设备部件对应于自其接收GPA的VM。这允许设备正确地使用所述VM的IOMMU表的映射（现在为合并的IOMMU表的部分）。通过设备标记GPA以及创建合并的IOMMU表一起使用单个请求者ID仿真多个请求者ID。

***300包括两个VM及其对应的IOMMU表。这些IOMMU表已经在不同偏移处组合为单个合并的IOMMU表，并且这些偏移已经标记为设备上相应VM的工作负荷所使用的GPA。这本质上使用单个IOMMU表仿真多个RID。虽然图3将VM的存储器呈现为主存储器中的连续块，但是实际上VM的存储器可以是遍及主存储器分散的非连续页面。IOMMU表从用于每个VM的GPA的连续范围映射到主存储器内的非连续物理页面。

根据一些实施例，设备302是GPU。在一些实施例中，设备302是英特尔Larrabee GPU。如本文所讨论的，诸如Larrabee GPU的GPU是非常智能的设备，并且高度可编程。在一些实施例中，如本文所讨论的，其运行基于完全FreeBSD的OS，称为微OS或uOS。这使其成为该技术的理想候选。在一些实施例中，单个设备卡（例如，单个Larrabee卡）由两个Windows Vista VM共享。VM直接向设备提交工作，导致接近本机性能。在一些实施例中，使用诸如Xen VMM的开源VMM。在一些实施例中，修改VMM（和/或Xen VMM）以创建合并的IOMMU表310。在一些实施例中，设备OS驱动程序被修改，从而当建立用于设备应用的页面表时，将GPA标记有VM使用的IOMMU表编号。当需要在主存储器和本地存储器之间进行DMA时也标记GPA。这使得利用合并的IOMMU表将所有对GPA的访问都映射到正确的HPA。

当前设备（例如，SR-IOV设备）实施在设备中的多个设备功能，以创建多个请求者ID（RID）。具有多个RID使得设备能够同时使用多个IOMMU表。然而，这要求对设备硬件进行显著改变，将增加设备的成本以及上市时间。

在一些实施例中，在VMM设备模型中执行地址转换。当VM试图向设备提交工作缓冲区时，其生成到VMM的俘获，其解析VM的工作缓冲区以发现GPA，然后在将工作缓冲区交给设备之前将GPA转换为HPA。因为频繁的VMM俘获和解析工作缓冲区，该技术具有非常高的虚拟化开销。

在一些实施例中，只有对设备软件/固件的少量修改是必需的（而不是创建单独的设备功能），以使得其能够利用单个请求者ID使用多个IOMMU表。VMM304创建合并的IOMMU表310，其包括共享设备302的所有VM的IOMMU表。设备在访问GPA之前将每个GPA标记有对应的IOMMU表编号。这减少了设备成本和上市时间。

当前方案不使用现代I/O设备（例如，英特尔的Larrabee GPU）中的可编程性，以使得能够同时访问多个IOMMU表。相反，它们依赖硬件改变来实现多个设备功能，以使其能够同时访问多个IOMMU表。

在一些实施例中，使用合并的IOMMU表（其包括来自多个个体IOMMU表的映射），并且修改设备软件/固件来将GPA标记有个体IOMMU表编号。

图4示出了根据一些实施例的***400。在一些实施例中，***400包括设备402（例如，I/O设备）、VMM404、服务VM406，以及VM1408。服务VM406包括设备模型412、主设备驱动程序414，以及存储器页面416（具有作为MMIO页面的映射传递）。VM1408包括设备驱动程序422。

图4示出利用存储器支持的寄存器（例如，MMIO寄存器）来减少设备虚拟化中的VMM捕获。根据一些实施例，VMM404运行VM1408并利用设备模型412虚拟化I/O设备402。设备模型412分配存储页面，并将VM的I/O设备传递的MMIO页面映射到该存储页面。设备的合格寄存器驻留在该页面。设备模型412和VM的设备驱动程序422都能通过访问该页面而直接访问合格寄存器。对合格寄存器的访问仍由VMM404俘获且由设备模型412仿真。

使用全部设备仿真的I/O设备虚拟化需要VMM中的软件设备模型，其仿真用于VM的硬件设备。仿真的硬件设备经常基于现有的物理设备，以便调整商业操作***中存在的设备驱动程序。VM408看到由VMM设备模型412所仿真的硬件设备，并且如同所述仿真的硬件设备是物理设备一样通过读和写其PCI、I/O和MMIO（存储器映射I/O）空间来进行访问。这些访问由VMM404所俘获并转发给设备模型412，在设备模型412处对所述访问进行适当地仿真。大部分现代I/O设备在由设备的PCI MMIOBAR（基地址寄存器）配置的范围内通过存储器映射I/O暴露其寄存器。然而，俘获对设备的MMIO寄存器的每个VM访问可能具有巨大的开销，并且大大降低了虚拟化设备的性能。当VM进行读/写时，一些仿真设备的MMIO寄存器不需要设备模型的任何额外处理，除了返回/写入寄存器的值之外。VMM404不必需要俘获对这种寄存器（后文称为合格寄存器）的访问，因为作为访问的结果没有待执行的处理。然而，当前VMM确实俘获对合格寄存器的访问，这不必要地增加了设备虚拟化中的虚拟化开销。如果合格寄存器被VM408频繁地访问，则该开销变得更巨大。

***400通过用存储器支持合格寄存器而减少了访问MMIO寄存器所引起的VMM俘获的数目。VMM中的设备模型412为合格寄存器分配存储页面，并将这些页面映射到VM作为RO（用于只读合格寄存器）或RW（用于读/写合格寄存器）。当VM408对合格寄存器进行合格访问时，将对存储器进行访问而不俘获到VMM404。设备模型412使用存储页面作为设备的MMIO空间中虚拟寄存器的位置。通过用合适的值填充存储器和/或读取VM408写入的值，设备模型412异步地仿真这些寄存器。通过减少VMM俘获的数目，改善了设备虚拟化性能。

使用正常的存储器虚拟化技术（影子页表或扩展页表（EPT）），将合格寄存器映射传递（取决于寄存器语义要么是只读的要么是读写的）到VM的地址空间。然而，由于MMIO地址仅在页面大小粒度可以映射到VM，所以映射这些寄存器传递也将所述页面传递上的其它每个寄存器映射到VM408。因此，仅在没有不合格的寄存器驻留在相同页面时，VMM404能够将合格设备寄存器传递映射到VM408。因此，根据一些实施例设计设备的MMIO寄存器布置，使得没有不合格的寄存器驻留在与合格寄存器相同的页面。合格寄存器进一步被分类为只读和读/写传递寄存器，并且这两种类型的合格寄存器需要在分离的MMIO页面上。如果VM使用准虚拟化的驱动程序，则能创建用于设备的这种虚拟化友好MMIO布置，从而没有必要依赖于具有这种MMIO布置的硬件设备。

当前VMM没有将合格设备寄存器传递映射到VM，并且通过俘获对这些寄存器的访问而引起不必要的虚拟化开销。一个原因是合格寄存器位于与不合格寄存器相同的MMIO页面。当前VMM使用VM中的准虚拟化驱动程序，以减少VMM俘获。这些准虚拟化驱动程序避免做出不必要的寄存器访问（例如，因为那些寄存器的值在VM是无意义的），或者分批处理那些寄存器访问（例如，写一系列寄存器以对设备进行编程）。

***400使用新技术来进一步减少I/O设备虚拟化中VMM俘获的数目，这将导致显著更好的设备虚拟化性能。***400使用存储器支持的合格寄存器用于VM的设备，并将那些存储页面映射到VM以减少访问虚拟设备的VMM俘获的数目。

当前VMM设备模型没有将合格设备寄存器传递映射到VM，并通过俘获其访问而引起不必要的虚拟化开销。这导致在虚拟化设备时比必要更多的VMM俘获。

根据一些实施例，合格的MMIO寄存器由存储器支持，并且存储页面被映射到VM中的传递以减少VM俘获。

图5示出了根据一些实施例的***500。在一些实施例中，***500包括设备502（例如，I/O设备）、VMM504、服务VM506和VM508。服务VM506包括设备模型512、主设备驱动程序514，以及包括中断状态寄存器的存储页面516。VM508包括设备驱动程序522。在设备502中，当工作负荷完成532时，设备502接收中断状态寄存器（例如，存储页面516中的中断状态寄存器）的位置，并在534处生成中断之前对其进行更新。

***500示出了将中断直接注入VM508。VMM504运行VM508、使用设备模型512虚拟化其I/O设备502。设备模型分配存储页面516以包含中断状态寄存器，并且将其地址传输给物理I/O设备。设备模型512也将存储页面只读传递映射到VM508。在完成VM的工作负荷之后，I/O设备502更新存储页面516上的中断状态寄存器，然后生成中断。当接收到设备中断时，处理器直接将中断注入到VM508。这使得VM的设备驱动程序522读取中断状态寄存器（没有生成任何VMM俘获）。当设备驱动程序522写这些寄存器时（应答中断），生成VMM俘获并且设备模型512对其进行处理。

如本文所讨论的，VMM提供I/O设备虚拟化以使得VM能够使用物理I/O设备。多个VMM使用设备模型以允许多个VM使用单个物理设备。I/O虚拟化开销是虚拟化总开销的最大部分。I/O虚拟化开销的较大部分是涉及处理用于VM的设备中断的开销。当物理设备处理来自VM的请求时，生成将由VMM的设备模型俘获和处理的中断。设备模型建立虚拟中断状态寄存器，并将所述中断注入到VM。已经观察到，将中断注入到VM是非常重量级的操作。其需要调度VM并发送IPI到被选择用于运行VM的处理器。这显著地有助于虚拟化开销。当接收中断时，VM读取中断状态寄存器。这生成到VMM的设备模型的另一俘获，其返回寄存器的值。

为了减小中断处理延时，硬件特征（称为虚拟中断交付和投递中断）可用于将中断直接注入到VM，而没有VMM干涉。这些硬件特征允许设备直接中断VM。虽然这些技术用于直接设备分配和SR-IOV设备，但是直接中断注入不用于基于设备模型的虚拟化方案。这是因为用于VM设备的中断状态由设备模型进行管理，并且设备模型必须被告知中断从而能更新中断状态。

***500能够将中断直接注入到VM用于基于设备-模型的虚拟化方案。因为VMM的设备模型在直接中断注入期间没有得到通知，所以设备自身在生成中断之前更新设备模型的中断状态寄存器。设备模型为VM设备的中断状态分配存储器，并将该存储器的位置传输到设备。修改所述设备（设备上运行的硬件或软件/固件），从而其能从设备模型接收中断状态寄存器的位置，且在生成中断之前适当地更新这些位置。设备模型还将中断状态寄存器映射到VM地址空间，从而VM的设备驱动器能够访问所述空间而不生成VMM俘获。通常，设备的中断状态寄存器写1以清除（W1C）语义（向寄存器的位写1清除该位）。这种寄存器不能读-写映射到VM，因为RAM存储器不能仿真W1C语义。这些中断状态寄存器可只读映射到VM，从而VM能读取中断状态寄存器，而无需任何VMM俘获，并且当写中断状态寄存器（例如，应答中断）时，VMM俘获访问并且设备模型仿真W1C语义。因此，***500的一些实施例使用两个重要部件。

根据一些实施例，***500的第一重要部件是VMM设备模型512，其为中断状态寄存器分配存储器，通知设备关于这些寄存器的位置，并将该存储器映射到VM508的MMIO空间。

根据一些实施例，***500的第二重要部件是设备驻留部件532，其从设备模型512接收中断状态寄存器的位置，并且在生成用于VM508的中断之前正确地更新它们。

根据一些实施例，使用硬件来提供对直接中断注入的支持（例如，APIC特征称为用于英特尔处理器的虚拟中断交付和投递中断）。

根据一些实施例，VMM设备模型512卸载更新中断状态寄存器到设备本身的责任，从而不需要在中断注入VM期间受到牵扯。在当前方案中，当设备中断时，设备模型更新中断状态寄存器，并将中断注入到VM。在图5的***500中，设备更新VM的中断状态寄存器（用于这些寄存器的存储器已经被设备模型在先分配），并且生成直接注入到VM的中断。另外，设备模型512还将中断状态寄存器映射到VM，以在VM的设备驱动器访问这些寄存器时避免VMM俘获。

在当前方案中，中断状态寄存器驻留在设备本身。设备不负责更新存储器中的中断状态寄存器。当前设备模型还不将这些寄存器映射到VM，以在VM的设备驱动器访问这些寄存器时避免VMM俘获。

根据一些实施例，物理I/O设备更新存储器中的设备模型的中断状态寄存器，允许中断被直接注入VM。

虽然本文描述了用特定方式实施的一些实施例，但根据一些实施例，可以不要求这些特定实施。

虽然参考特定实现描述了一些实施例，但是根据一些实施例的其它实现也是可以的。另外，附图中示出的电路元件或其它特征的布置和/或次序不需以示出和描述的特定方式布置。根据一些实施例，许多其它布置也是可以的。

在图中所示的每个***中，在一些情况中元件可能每个具有相同的附图标记或不同的附图标记，以暗示所表示的元件可以是不同的和/或相同的。然而，元件可能足够灵活以具有不同的实现和与本文所示出和描述的一些或所有***一起工作。附图中示出的各种元件可以是相同或不同的。哪一个被称为第一元件和哪一个被称为第二元件是任意的。

在说明书和权利要求书中，可以使用术语“耦合”和“连接”及其衍生词。可以理解的是，这些术语并不意图作为彼此的同义词。而是，在特定实施例中，“连接”可用于表示两个或更多个元件彼此直接物理或电接触。“耦合”可表示两个或更多个元件可以直接物理或电接触。但是，“耦合”还可以表示两个或更多个元件彼此并不直接接触，而是彼此相互合作或交互。

本文的算法通常被认为是导致期望结果的动作或操作的自相容序列。这些包括物理量的物理操作。通常，虽然不是必需的，这些量采用能够被储存、传输、组合、比较和操作的电信号或磁信号的形式。主要出于通常使用的原因，已经多次证明了参照这些信号作为位、值、元素、符号、字符、术语、数目等是方便的。然而，可以理解的是，所有这些和类似术语将与合适的物理量相关联，并且仅是施加到这些量的方便标签。

一些实施例可以实现为硬件、固件和软件之一或其组合。一些实施例还可以实施为存储于机器可读介质上的指令，其可以由计算平台读取并执行以实现本文描述的操作。机器可读介质可以包括任意机制，用于存储或传输机器（例如，计算机）可读形式的信息。例如，机器可读介质可以包括只读存储器（ROM）；随机存取存储器（RAM）；磁盘存储介质；光学存储介质；闪存设备；电、光、声或其它形式的传播信号（例如，载波、红外信号、数字信号、传输和/或接收信号的接口，等）；以及其它。

实施例为本发明的实现或示例。说明书中引用的“实施例”、“一个实施例”、“一些实施例”或“其它实施例”表示结合实施例所描述的特定特征、结构或特性包含于至少一些实施例中，但是不必是本发明的所有实施例。出现的各“实施例”、“一个实施例”或“一些实施例”不必都指同一实施例。

不是所有在本文中描述和示出的部件、特征、结构、特性等都需包含于特定的一个实施例或多个实施例中。例如，如果说明书表述部件、特征、结构或特性“可以”、“可能”、“能够”或“能”被包含，则特定部件、特征、结构或特性不要求被包含。如果说明书或权利要求书涉及“一（a）”或“一（an）”元件，则不表示只有一个所述元件。如果说明书或权利要求书涉及“另外的”元件，则不排除存在多余一个的所述额外元件。

虽然本文使用了流程图和/或状态图来描述实施例，但是本发明并不受限于这些图或本文的相应描述。例如，流程不必移动通过每个示出的方框或状态或者按图示或本文描述的完全相同的次序。

本发明并不受限于本文所列出的特定细节。实际上，受益于本公开的本领域的技术人员将会理解，在本发明的范围内可以根据上述描述和附图做出多种其它变型。因此，随后的权利要求包括限定本发明范围的任何修改。

Claims (20)

1.一种方法，包括：

使得设备能够直接运行虚拟机工作负荷；以及

在来自不同虚拟机的工作负荷之间提供隔离和调度。

2.根据权利要求1所述的方法，还包括：修改设备软件和/或固件，以支持对来自不同虚拟机的工作负荷进行隔离和调度。

3.根据权利要求1所述的方法，还包括：提供高性能输入/输出虚拟化。

4.根据权利要求1所述的方法，还包括：支持由多个虚拟机进行的设备共享。

5.根据权利要求1所述的方法，还包括：将设备资源动态地分配给虚拟机。

6.根据权利要求1所述的方法，还包括：将设备资源动态地分配给虚拟机，而不要求对被虚拟化的设备进行显著的硬件改变。

7.根据权利要求1所述的方法，还包括：对于频繁访问的设备资源，直接访问到被虚拟化的设备的路径。

8.根据权利要求1所述的方法，还包括：确保对不频繁访问的设备资源的隔离和调度。

9.根据权利要求1所述的方法，还包括：俘获和仿真。

10.根据权利要求1所述的方法，还包括：对于不频繁访问的设备资源，使用虚拟机设备模型来访问设备资源。

11.一种装置，包括：

虚拟机监视器，其适用于使得设备能够直接运行虚拟机工作负荷，并且适用于在来自不同虚拟机的工作负荷之间提供隔离和调度。

12.根据权利要求11所述的装置，所述虚拟机监视器适用于修改设备软件和/或固件，以支持对来自不同虚拟机的工作负荷进行隔离和调度。

13.根据权利要求11所述的装置，所述虚拟机监视器适用于提供高性能输入/输出虚拟化。

14.根据权利要求11所述的装置，所述虚拟机监视器适用于支持由多个虚拟机进行的设备共享。

15.根据权利要求11所述的装置，所述虚拟机监视器适用于将设备资源动态地分配给虚拟机。

16.根据权利要求11所述的装置，所述虚拟机监视器适用于将设备资源动态地分配给虚拟机，而不要求对被虚拟化的设备进行显著的硬件改变。

17.根据权利要求11所述的装置，所述虚拟机监视器适用于对于频繁访问的设备资源，直接访问到被虚拟化的设备的路径。

18.根据权利要求11所述的装置，所述虚拟机监视器适用于确保对不频繁访问的设备资源的隔离和调度。

19.根据权利要求11所述的装置，所述虚拟机监视器适用于俘获和仿真。

20.根据权利要求11所述的装置，所述虚拟机监视器适用于对于不频繁访问的设备资源，使用虚拟机设备模型来访问设备资源。

Images