AMD、Intel从硬件角度辅助服务器虚拟化进程

日期: 2008-02-28 来源:TechTarget中国

  到今天,x86已经面临了最大的挑战。从体系结构上来说,该平台本身并不是为支持多操作系统同时运行而设计的,这也就意味着虚拟化厂商被迫去克服硬件和软件两方面的限制,来分配和管理处理器、内存以及I/O资源。VMware已经在这个领域占据了优势,并不仅仅因为它是第一个在此领域提供虚拟化的厂商,而且因为它能够克服这些硬件问题,提供了一个可以使用的管理环境来处理大型虚拟化所固有的一些问题。


  目前,新一代AMD和Intel处理器中的虚拟化功能正在为有效的、基于hypervisor管理程序的x86系统虚拟化铺平道路,随之重点也转向了如何使得处理器更加可靠。尽管我们看到VMware、Microsoft以及开源Xen是基于不同的hypervisor方法,但在这些hypervisor 技术之间选择的重要性,远远不如应对大型虚拟化所提出的管理挑战更为关键。最终,真正的市场赢家必然是那些可以为把我们的物理环境转变为更多产的虚拟环境而提供很好功能的厂商。但是,为实现这个目标,首先代价都需要来自处理器厂商的帮助。


  老问题,新解决


  在目前我们所看到的两种主要服务器虚拟化选择中,基于hypervisor的服务器虚拟化比操作系统分区的方法提出了更多的问题。使用操作系统分区的方法,主机操作系统提供了对所有资源的访问,消除了hypervisor中固有的很多问题,但用户只限于主机操作系统;基于Hypervisor的虚拟化提供了裸机支持多操作系统的灵活性,但引出了很多的技术挑战,需要大量的软件来处理与分配CPU、内存以及I/O资源有关的工作。


  幸运的是,AMD和Intel已经针对这些棘手的问题拿出了新的硬件应对解决方案。


  在保护模式下,x86处理器一共有4个不同优先级,术语称为Ring,从Ring 0~Ring3。Ring 0的优先级最高,Ring 3最低。一般情况下,Ring 0是被用于运行操作系统内核,Ring 1和Ring 2是用于操作系统服务,Ring 3则是用于应用程序。


  也就是说,在一个常规的x86操作环境中,操作系统是运行在受保护的ring 0。在没有处理器辅助的虚拟化情况下,取而代之的是必须要ring 0来运行VMM (Virtual Machine Monitor,虚拟机监视器)或hypervisor,来为VM以及它们的VOS(Virtual OS,虚拟操作系统)管理硬件资源。那么,CPU虚拟化的挑战就是要寻找一种方法使得操作系统正常运行在ring 0之外的一个地方。


  为了解决这个问题,芯片辅助(chip-assisted)的虚拟化能够让一个新的、有超级特权的和受保护的ring 1来运行VMM。这个新的位置使得VOS能够平静地共存于ring 0,通信自动改变到ring 1,而这些VOS并不知道它们与同一系统中的其他操作系统共享物理资源。


  这项主要的进步消除了操作系统的ring转换问题,也减少了虚拟化的费用,它可以为各种操作系统的虚拟化提供支持,而且并不需要对内核或运行时间做任何改变。尽管AMD和Intel选择了略微不同的方法来达到这个目标,不过令我们高兴的是,即使两公司的技术不能完全互换,我们也不担心,因为很多虚拟化提供商已经致力于这两种技术积极展开工作。


  Intel公司首先出手的是其VT-x,它创建了ring 1并提供了一套新指令来建立、管理和退出VM,就如同操作内存管理一样。VT-x与AMD-V(以前被称为Pacifica)芯片辅助技术有很多相似之处。在具有芯片辅助的处理器中,hypervisor驻留在 ring 1,并创建一个VM控制结构来支持新的VM。这提供了一种机制,可以根据需要来创建、重新分配以及撤销VM,其作用就如同是在VMM和大量VM之间场景转换的控制架构。


  很多虚拟机和它们的操作系统堆栈可以和平共处在ring 0中;而每一个芯片上都类似地会有这些虚拟机VM的控制器——Intel称之为VMX,而AMD则称之为SVM(secure VM)。更重要的是,允许虚拟的操作系统驻留在ring 0还消除了ring转换的挑战。因为大量的指令是对位置敏感的,只被设计为在rings 0和3之间转换,如果VOS位于ring 0以外的其他地方,关键程序就可能出现不可预知的错误。


  现在,VM安全地位于ring 0,为截取和校正VOS所引发的问题而必需的软件机制运行在错误的ring也无所谓了。当在虚拟的VM上出现问题的时候,处理器有能力转换控制器到受保护的VMM,它可以解决问题并把控制器返回给VM或者在不中断系统中其他VM的情况下终止该问题。


  不过在这里也看到了AMD和Intel的技术分叉点,因为Intel处理器使用外部内存控制器,新的VT-x处理器修改并不只提供虚拟内存管理功能,这也就意味着仍然需要软件来处理物理和虚拟内存资源之间的地址转化。这并不是最理想的解决方案,但是确实是有效的方案。


  与之形成对照的是,AMD的处理器片上集成了内存控制器,因此AMD-V虚拟化技术引入了独特的新指令,使得内存的模式和特性与其设计无关。这些指令中的大多数用于MMU (memory management unit)的操作,MMU提供内存分配。


  在虚拟化情况下,MMU需要跟踪了解什么时候分配任务来映射多操作系统、运行多种连接到物理内存地址的应用程序。另外,AMD-V还提供了先进的内存特性,包括Tagged Translation Look-Aside Buffers。


  也许最有趣的特性是AMD对NPTs (nested page tables)的支持。与Intel的软件方法相对立,NPT支持通过为每一个VM提供不受硬件约束的、虚拟CR3内存寄存器,允许每一个VM更有力地控制其内部内存管理。


  尽管使用NPTs增加了内存查找的数量,但NPTs消除了VT-x所需要的软件层。这就使得内存管理保留在其本应该在的硬件区域,从而充分保证了更高的VM内存性能。这种速度的提升在一些对内存要求较高的应用中表现最为明显,尤其是在有很多VM存在的环境中。


  AMD的虚拟化策略比Intel的看似更具有性能潜力,但是AMD-V要在即将发布的第一代Rev.F Opteron中才会出现,而Intel的VT-x 已经出现在其目前最新的Xeon处理器中,不过服务器厂商才刚刚开始发布BIOS修订来支持这些新的特性。


  来自Microsoft和使用Xen的厂商的所有未来基于hypervisor的虚拟化将依赖于这种芯片辅助技术,但是VMware的完全硬件虚拟化方法将持续支持没有芯片辅助的传统系统。


  打破I/O瓶颈


  CPU和VMM内存管理问题只是虚拟化难题中的一部分;对于硬件制造商来说,接下来的巨大挑战将是改善具有共享I/O设备的内存的交感和安全性。


  这本身有两方面的问题,也许更艰巨的任务会落到I/O硬件开发者肩上,他们需要创建能够跨越多个VM共享访问设备——今天的存储、网络和图形设备只能够对操作系统提供单一接口界面,这就意味着对于具有多个VM的系统必须使用软件来处理IRQ、内存和计时器函数,直到I/O硬件能够支持多个功能性接口。


  从处理器的立场,挑战在于为共享设备提供处理器级的架构。现在以及未来,AMD和Intel已经创建了非常类似的规格来达到这个目标,二者的规范都已经在春季发布,一些虚拟化的厂商也已经对二者做了签约支持。


  据预测,AMD将首先在这块市场出击,推出其IOMMU(I/O memory mapping unit)技术,该技术提供了附加的指令来支持硬件虚拟化。这些新的特性被设计用于改进DMA(direct memory access)映射以及对硬件设备的访问,取代目前的图形化的寻址机制,并支持通过一个VM对设备的直接控制,同时能够在一个VM中直接访问用户空间 I/O。


  Intel的VT-d(Virtualization Technology for Directed I/O)标准也是锁定直接设备访问和内存保护的问题。与IOMMU一样,VT-d提供了在VM和I/O设备之间直接通信的架构。


  不过,最初这些功能对于虚拟化来说还只是有名无实,因为I/O虚拟化解决方案的另外一半目前还没有到位——那就是,如今还没有I/O设备能够管理共享VM对硬件资源的访问。


  事实上,甚至还没有一个适当的标准支持设备跨越PCI共享,也许要看到普遍的、基于设备的硬件I/O虚拟化解决方案还需要等两年到四年的时间。到那个时候,虚拟化厂商将需要提供一个提取层,来支持对存储、网络以及其他中断驱动的设备的共享访问。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐