一种对操作***透明的处理器资源整合利用方法
(一)技术领域
本发明主要是涉及硬件虚拟化技术以及多处理器体系结构,将分散的通过在多个服务器上的处理器资源加以整合利用,尤其是涉及一种对操作***透明的处理器资源整合利用方法。属于计算机技术领域。
(二)背景技术
1.服务器的设计与部署
当前服务器的设计和部署呈现两个趋势:纵向扩展(scale-up)和横向扩展(scale-out)。纵向扩展指的是将多个处理器和存储器等***资源紧密耦合在单个服务器中,对其整体***能力的扩展是通过在单个服务器中增加处理器和内存等资源来实现。scale-up***呈现的是单一***映像,具有简单易用的编程模型,易于管理和维护,但存在成本偏高、可扩展性有限。横向扩展是指将多台小规模的中低端服务器松散连接成一个服务器***,对其整体***能力的扩展是通过在***中增加相同或类似配置的中低端服务器结点来实现。scale-out***具有实现成本低、可扩展性好等优势,但不对上呈现单一***映像,编程复杂,管理和维护也较复杂。因此,如何能够在成本低、可扩展性好的scale-out***基础上实现scale-up***所呈现的单一***映像以及可编程性好,易管理的特征是一个很值得研究的问题。
2.硬件虚拟化技术
虚拟化技术通过虚拟机监控器(Virtual Machine Monitor,简称VMM,也称作hypervisor,在本文中VMM和hypervisor指的是同一概念)可以将底层的硬件资源加以抽象来呈现给客户操作***,从而可以隐藏底层硬件真正的细节,为客户操作***虚拟出一个硬件层。因为软件虚拟化技术的种种难以克服的缺点,CPU厂商推出了基于CPU的硬件虚拟化技术。支持虚拟技术的CPU带有特别优化过的指令集来控制虚拟过程,通过这些指令集,VMM会很容易提高性能,相比软件的虚拟实现方式会很大程度上提高性能。硬件虚拟化技术可提供基于芯片的功能,借助兼容VMM软件能够改进纯软件解决方案。由于虚拟化硬件可提供全新的架构,支持操作***直接在上面运行,从而无需进行二进制转换,减少了相关的性能开销,极大简化了VMM设计,进而使VMM能够按通用标准进行编写,性能更加强大。
一个使用硬件虚拟化的虚拟机架构负责为多个客户操作******提供硬件支持,同时保证各个客户操作***的安全性,高效性以及资源的隔离性。硬件虚拟化架构在虚拟机监控器(VMM)和客户操作***之间快速切换的机制,有选择的截获客户操作***中的指令和行为的能力,DMA对内存存取操作的保护,对中断处理以及虚拟中断的支持,提供标有guest/host标记的TLB以减少虚拟化的负担等等。
硬件虚拟化架构定义了一个异常行为集合,该集合包括所有可能影响hypervisor或客户操作***的指令或事件,通过截获该集合中的异常行为来进行相应操作。相对于在x86体系结构下的最高特权级是ring0级,硬件虚拟化架构定义了一些新的指令、寄存器以及控制域来实现一个更高特权级的模式,该特权级也被称为“ring-1”(AMD)级或者“非根模式”(Intel)。同时,硬件虚拟化架构还定义了虚拟机控制结构体,(对于AMD的SVM架构来说是Virtual MachineControl Blocks(VMCB),对于Intel的VT架构来说是Virtual Machine ControlStruct(VMCS)),该结构体用于对异常行为的控制,并且不允许在处理器核心之间共享,它控制着虚拟机监控器和客户操作***的切换。
硬件虚拟化技术引入了一些新的指令。用来运行一个客户操作***,管理客户操作***的状态信息,实现客户操作***同hypervisor的交互等等。hypervisor通过建立正确的虚拟机控制结构体,运行特定指令初始客户操作***的运行。客户操作***初始完毕后,会一直运行到下一次VMEXIT条件发生,此时控制权返回到hypervisor。发生VMEXIT时,客户操作***的状态信息,包括发生VMEXIT的原因,都存放在了虚拟机控制结构体的状态域中。Hypervisor从虚拟机控制结构体中获取被截获的指令或行为,通过模拟、忽略或者改变执行方式的方法来进行相应操作,进而更新虚拟机控制结构体的相关状态信息。***开发人员可以自行规定hypervisor对客户操作***监管的程度,这是通过设置产生VMEXIT的条件的规模来决定的。针对每一种VMEXIT条件,hypervisor都必须有相应的处理程序来实现在客户操作***中该条件想要的结果,然后将该结果转化为适当的形式写入虚拟机控制结构体,进而在客户操作***进入时返回给客户操作***。
3.现有的利用多机处理器资源的方法
(1)进程迁移方式
以MOSIX为代表的***通过实现进程迁移来利用多物理服务器的处理器资源。MOSIX***采用给Linux内核打补丁的形式,实现了***级透明的进程迁移功能。其把一个进程分为用户级上下文(Remote:远程)和***级上下文(Deputy:代理)这两部分。Remote是针对进程在用户态的封装,Deputy则是针对进程在内核态的封装[14]。Deputy包括进程***上下文具有物理服务器依赖性的那部分,因此是不能被迁移的。MOSIX是通过扩充Linux内核实现的。
这种进程迁移的方式的一个优点是可伸缩性比较强,但这种方式也有很多缺陷。首先,这种通过进程迁移的方式并不是真正意义上的单一***映像,上层用户以及操作***看到的硬件资源仍然只是本地资源,并没有形成全局统一的资源视图和调度能力。其次,MOSIX进程迁移机制是需要有存根在源物理服务器上的,大量的进程迁移会造成***的不稳定。最后,MOSIX需要修改操作***。
(2)特殊硬件方式
以IBM的cc-NUMA为代表的***通过定做一些特定的硬件并配以相应的软件来实现单一***映像。在硬件方面,每个物理服务器具有一个MCU卡和一块Opium卡,用于实现跨物理服务器的内存共享,统计应用相关的内存访问特征。在软件方面,一是扩展BIOS,增加的部分称为eBIOS。eBIOS将四个独立物理服务器配置成一个16路的cc-NUMA***。二是修改windows NT的硬件抽象层(HAL)以支持远程处理器间的中断,以及提供远程I/O设备和端口的访问机制。三是将资源抽象成多个资源集,线程可以和某个资源集相绑定[9]。
这种方法的优点是通过硬件实现以后,***在资源亲和性方面比较好,使得***的效率比较高。该方法的不足之处在于,首先,通过专有硬件卡实现,通用性不够,成本较高。其次,不能进行***级的资源调整,透明性不好。
(3)基于Host OS的软件虚拟化方式
这种方式以东京大学开发的Virtual Mutiprocessor***为代表。在这种***中,每个物理服务器都存在Host OS,在Host OS的支持下实现虚拟机监控器(VMM),VMM运行在用户态,从而无须修改主机操作***。对于客户操作***采用半虚拟化技术,需要对客户操作***进行修改。VMM将一个或多个虚处理器映射到一个物理处理器[6]。***为每一个虚拟处理器配备两个进程,一个用来模拟虚拟处理器,另一个用来监控虚拟处理器,当遇到特权指令时,监控进程便要执行相应的操作。
该方法的优点是实现了对客户操作***来说实现了单一***映像,并且可以形成全局虚拟处理器视图。但其缺点也是比较明显的,首先该***需要修改客户操作***。其次,采用用户进程来模拟虚拟处理器的方法效率很低。
(4)无Host OS的软件虚拟化方式
基于Intel IA-64架构的vNUMA***采用了一种由半虚拟化方法的改进的称为预虚拟化的方法,在对客户操作***进行构建的时候,采用半自动的方法将敏感指令打包成对VMM的调用,在成功模拟敏感指令的同时避免对操作***源代码的大量修改。对于特权指令,为了保证VMM不可被绕过,客户操作***被转移到非特权级运行,此时特权指令会被捕获,VMM从内存中读取并解码引起异常的指令,并在相应的虚拟机上模拟该指令执行的效果。对于敏感非特权指令,采用预虚拟化的技术达到虚拟化的目的。这些敏感非特权指令必须被替换成可以引发异常的代码或代码段。该***的优点是在硬件之上直接实现VMM,脱离了Host OS的支持,执行效率较高,并且可以实现单一***映像,客户操作***对全局资源可见。缺点是该***也需要修改客户操作***,并且该***是基于Intel安腾架构的,而不是通用的x86处理器架构,应用受到一定限制。
(三)发明内容
1 目的
本发明提供了一种对操作***透明的处理器资源整合利用的方法,它实现了跨物理服务器的处理器虚拟化***。通过在多个物理服务器之上部署基于这种处理器资源整合利用方法的虚拟机监控器,使得上层客户操作***可以在物理服务器集群上运行,透明地使用分散在多个物理机器中的处理器资源。
2 技术方案
一种对操作***透明的处理器资源整合利用的方法,其具体步骤如下:
步骤1:在各个物理服务器上生成虚拟处理器。在每个结点上,我们采用硬件虚拟化技术来实现处理器的虚拟化。根据硬件虚拟化的规范,通过在虚拟机监控器(VMM)和客户操作***之间快速切换的机制,在每个结点上对虚拟处理器的控制结构进行初始化,同时建立虚拟处理器和物理处理器的初始对应关系。然后,对每个虚拟处理器,设置hypervisor对客户操作***监管的程度,划分敏感指令集。这样,虚拟处理器初始化完毕后,当客户操作***执行到这些指令的时候,就会发生VM退出,控制权转移到底层的虚拟机监控器。
步骤2:对各个结点的虚拟处理器信息进行采集。每个结点上生成的虚拟处理器都要提供给上层的客户操作***,因此***中每一个物理服务器都必须了解全局的虚拟处理器分布情况。这里通过将各个物理服务器所提供的虚拟处理器数量写成配置文件,在各个结点的hypervisor中读取该文件,这样各个结点一开始就知道整个***的虚拟处理器的分布情况。同时,有时候可能由于特殊原因,某个结点实际提供的虚拟处理器数目可能不同于并没有按照配置文件记录的数目(这种情况极少发生),各个物理服务器在创建完虚拟处理器后,必须告诉其他物理服务器其是否成功创建了指定数目的vcpu,如果没有,那么各个物理服务器需要修正vcpu分布信息。
步骤3:对虚拟处理器资源信息进行整合与管理。通过前面对虚拟处理器信息的采集,hypervisor已经知道了虚拟处理器在各个几点的分布情况。这样,每个结点都保存一份全局的虚拟处理器分布表。接下来需要对全局的虚拟处理器进行管理,对于跨物理服务器条件下虚拟处理器的组织,采用的原则是对于那些guest引发的相关操作进行全局范围统一管理,对于hypervisor直接掌控的相关操作则分服务器单独管理。对于虚拟处理器标识的管理,采用的方法如下:虚拟处理器资源整合***中基于以下四个比较重要的标识。(1)vcpu_id,用于在hypervisor中管理虚拟处理器;(2)vlapic_id,用于向guest提供虚拟的apicid;(3)vpu_id_global标识,代表当前虚拟处理器在全局环境下的逻辑id,从guest的角度看来,vcpu_id_global就是其所拥有的处理器在全局层面的逻辑id。(4)node_id,代表该物理服务器在全局范围内的逻辑标识。首先要为每个结点指定一个结点号node_id,其中结点号为0的结点为主结点。然后为每个虚拟处理器分配一个逻辑的vcpu_id,从0开始计数,并且服务器内的vcpuid是连续分配的。对于虚拟处理器的vpu_id_global标识,通过计算该虚拟处理器在全局的序号来指定。我们将虚拟处理器所在的物理服务器信息反映到vlapic_id中,以便可以迅速的定位该虚拟处理器。同时,为了使得虚拟处理器可以在物理处理器上迁移,我们的虚拟处理器不进行多核结构的设置。所以将8bit的虚拟处理器的vlapic_id域分为两个部分,低三个bit用来标识该vcpu在本服务器内的序号,这个序号在数值上等于其vcpu_id。高五个bit用来标识该虚拟处理器所在的服务器号。
步骤4:确定对虚拟处理器信息的获取方式。根据vcpu的管理方法,其node_id,vcpu_id,vlapic_id是可以通过计算得到的。例如计算vlapic_id采用如下方法:
vlapic_id=node_id<<3+vcpu_id (1)
对于所在的物理服务器号为t的vcpu来说,其vcpu_id_global的计算方式如下,其中vcpu_nr(i)是服务器i上的vcpu数量:
获取某个虚拟处理器所在的物理服务器号采用下面的方法:
node_id=vlapic_id>>3 (3)
另外,我们还在每个服务器上维护了一个全局的虚拟处理器资源信息表,某些不能通过计算得到的信息,例如虚拟处理器的dfr信息等,需要通过查表得到。
步骤5:将虚拟处理器信息向guest进行呈现。全局的虚拟处理器资源就是guest能够使用的处理器资源,我们需要guest能够正确的识别到这些虚拟处理器,并能够正常初始化它们。在这里为guest提供整合后的虚拟处理器资源信息,主要是根据虚拟处理器的分布情况,制作基于多处理器规范的MP表以及基于ACPI规范的acpi表,并将其放到guest的内存区域的适当位置,目的是在guest启动的时候通过读取这些表项感知其所拥有的处理器资源信息。对于MP表,主要是修改Processor Entries,为每个虚拟处理器生成一个ProcessorEntry。对于ACPI表,主要是修改Multiple APIC Description Table(MADT)的Processor Local APIC Structure,还要根据虚拟处理器信息制作processor_objects表项。将这些表项写入guest的内存,并索引到MP规范和ACPI规范的头部区域后,guest启动时便可以读到这些虚拟的处理器信息,从而对占有的处理器资源有一个概况。
至此,hypervisor层对于虚拟处理器资源信息的准备工作已经完毕,接下来就是启动客户操作***,并在其执行过程中对其行为进行模拟。
步骤6:对guest多处理器启动过程进行模拟。为了让客户操作***能够真正感知并使用底层分散在各个物理服务器中的虚拟处理器资源,还要对guest的多处理器启动过程进行跟踪和模拟。Guest首先读取MP和ACPI相关表项,确定处理器资源信息,然后通过发送SIPI中断来启动和初始化虚拟处理器。虚拟处理器发送SIPI中断的时候是通过向ICR寄存器写入数据实现的,向虚拟ICR写入地址时会被捕获到,此时在主物理服务器BSP退出的路径中,根据ICR的内容判断是否是发送SIPI,然后判断要启动的虚拟AP是否在本服务器内部,如果是的话,则直接将虚拟的跳板程序从虚拟ICR中解析出来,然后对目标AP做最后的初始化,主要是设置其虚拟控制结构体中的一些重要寄存器信息,其中重点是将跳板程序的地址写入,作为虚拟处理器进入时程序的执行起点。然后将被启动的虚拟处理器唤醒,使其为可执行状态并加入调度器队列,等到被调度到的时候进入非根模式,开始执行客户操作***的代码。如果目标AP不在主物理服务器上,则需要将SIPI信息打包成网络信息包,发送给目标AP所在的物理服务器。当目标服务器接收到信息包之后,判断如果是SIPI信息包,那么首先需要将SIPI的目标AP的vlapic_id解析出来进行判断,如果该AP确实在本物理服务器,那么紧接着从该信息包中解析出跳板程序的地址,然后对目标AP进行最后的初始化,将跳板程序地址写入虚拟控制结构体中。接下来的过程跟单机内一样,调用唤醒模块将目标虚拟处理器唤醒并加入调度队列,等下一次被调度的时候调用虚拟机进入模块,进入非根模式,执行客户操作***的代码。
步骤7:在客户操作***执行过程中,对其指令集进行必要的模拟。在多服务器的条件下,需要模拟的指令大致分为三类,一些指令只需要在物理服务器内进行模拟,而有一些敏感指令或者行为(例如发送跨处理器中断)会引发跨物理服务器的处理器操作,这时需要物理服务器之间协调完成指令的模拟。还有一些指令会间接引发跨物理服务器操作,或者受到全局资源整合的影响,这时也需要在全局资源视图下,通过跨物理服务器的操作对指令模拟进行辅助,保证指令的正确模拟。敏感指令的模拟如图3所示。
第一类,与全局vcpu资源整合无关的敏感指令模拟。某些指令只需要在物理服务器内进行模拟,其模拟过程中也只是涉及本地的一些寄存器操作,而不涉及跨物理服务器操作。例如对HLT,VMMCALL等指令的模拟。对这些指令的模拟只需根据其含义,在单机内进行模拟,并将模拟结果通过其虚拟寄存器等返回到客户操作***。
第二类,直接引发跨物理服务器操作的指令模拟。这些指令的模拟可能直接引发跨物理服务器操作。例如IO操作,无论是以IN/OUT/INS/OUTS指令为主的直接IO访问(PIO),还是以MOV/MOVS等内存操作指令为主的内存映射IO访问(MMIO),都有可能因为要访问的设备在远端物理服务器而不在本地,而产生跨物理服务器操作。对于直接IO访问操作,hypervisor通过捕获IN/OUT/INS/OUTS等指令来截获guest操作。对于内存映射IO访问,hypervisor通过设备映射内存区的缺页异常来捕获guest操作。IO操作被捕获后,hypervisor判断目标设备是否在本地。如果在本地,则直接进行指令模拟、IO操作等。如果目标设备不在本地,则需要hypervisor将IO操作信息进行分析,抽取出IO操作类型,目标端口地址、读写、数据或数据所在内存地址等信息,连同物理服务器id、处理器id等环境信息一起制作成网络信息包,发送给目标设备所在的物理服务器。在设备对guest可见的情况下,目标服务器解析传来的数据包,将IO操作在本地还原,完成IO操作,然后将操作是否成功的信息发回给请求端服务器,同时,如果IO操作时是读数据的操作,并且不是往guest的内存里读,则需要将读出的数据一并发回给请求端服务器。如果设备是由模拟器虚拟的,则目标服务器收到IO操作网络包后,将IO请求发给设备模拟器处理。
第三类,间接受到跨物理服务器影响的指令模拟。这些指令的模拟会间接受到跨物理服务器条件的影响,这些影响主要包括在模拟过程中需要用到跨物理服务器的资源整合信息,或者会间接引发跨物理服务器操作。
对于需要用到跨物理服务器的资源整合信息的指令模拟,例如CPUID指令获取apic_id的操作。当指令被捕获后,需要根据整合后的全局虚拟处理器资源信息,来模拟指令想要的结果,并将结果返回给客户操作***。
会间接引发跨物理服务器操作的指令,其典型代表是如mov_to_cr、movs等指令。在对这些指令的模拟过程中,指令操作数可能在guest内存中。当涉及到客户操作***内存访问操作的时候,需要注意缺页问题,也就是所需页面不在本地的情况,此时需要调用DSM算法请求远程页面的拷贝。对于非敏感指令和行为中操作数造成的缺页,只需由hypervisor将页面拷贝过来,然后即可返回客户操作***继续执行。对于需要访问客户操作***页面,要由hypervisor主动的调用DSM模块。通过DSM算法将有效页面迁移过来,并进一步得到操作数本身。进而完成对指令的模拟。
3优点及效果
当前由于硬件的限制,单台服务器的性能越来越难以提升,目前获得高性能服务器的方法很多是基于将多台小规模的中低端服务器松散连接成一个服务器***来实现的,但这种***不对上呈现单一***映像,编程复杂,管理和维护也较复杂。本发明提出了基于硬件虚拟化技术的处理器资源整合方法,对上层操作***透明,并且具有良好的通用性以及较高的效率,因此,本发明可以使将多台分散的、造价较低的物理服务器虚拟成一台具有大量处理器资源的高性能服务器,从而可以在不需要对上层软件***作出任何修改,具有简单易用的编程模型的前提下,在多台造价低廉的中低端服务器上实现加速比,获得高性能。因此,本发明具有良好的应用前景。
(四)附图说明
图1***总体框架示意图
图2物理处理器和虚拟处理器的对应示意图
图3敏感指令的模拟过程示意图
(五)具体实施方式
见图1、图2、图3所示,具体实施步骤如下:
步骤1:在各个物理服务器上生成虚拟处理器。在每个结点上,我们采用硬件虚拟化技术来实现处理器的虚拟化。根据硬件虚拟化的规范,通过在虚拟机监控器(VMM)和客户操作***之间快速切换的机制,在每个结点上对虚拟处理器的控制结构进行初始化,同时建立虚拟处理器和物理处理器的初始对应关系。然后,对每个虚拟处理器,设置hypervisor对客户操作***监管的程度,划分敏感指令集。这样,虚拟处理器初始化完毕后,当客户操作***执行到这些指令的时候,就会发生VM退出,控制权转移到底层的虚拟机监控器。
步骤2:对各个结点的虚拟处理器信息进行采集。每个结点上生成的虚拟处理器都要提供给上层的客户操作***,因此***中每一个物理服务器都必须了解全局的虚拟处理器分布情况。这里通过将各个物理服务器所提供的虚拟处理器数量写成配置文件,在各个结点的hypervisor中读取该文件,这样各个结点一开始就知道整个***的虚拟处理器的分布情况。同时,有时候可能由于特殊原因,某个结点实际提供的虚拟处理器数目可能不同于并没有按照配置文件记录的数目(这种情况极少发生),各个物理服务器在创建完虚拟处理器后,必须告诉其他物理服务器其是否成功创建了指定数目的vcpu,如果没有,那么各个物理服务器需要修正vcpu分布信息。
步骤3:对虚拟处理器资源信息进行整合与管理。通过前面对虚拟处理器信息的采集,hypervisor已经知道了虚拟处理器在各个几点的分布情况。这样,每个结点都保存一份全局的虚拟处理器分布表。接下来需要对全局的虚拟处理器进行管理,对于跨物理服务器条件下虚拟处理器的组织,采用的原则是对于那些guest引发的相关操作进行全局范围统一管理,对于hypervisor直接掌控的相关操作则分服务器单独管理。对于虚拟处理器标识的管理,采用的方法如下:虚拟处理器资源整合***中基于以下四个比较重要的标识。(1)vcpu_id,用于在hypervisor中管理虚拟处理器;(2)vlapic_id,用于向guest提供虚拟的apicid;(3)vpu_id_global标识,代表当前虚拟处理器在全局环境下的逻辑id,从guest的角度看来,vcpu_id_global就是其所拥有的处理器在全局层面的逻辑id。(4)node_id,代表该物理服务器在全局范围内的逻辑标识。首先要为每个结点指定一个结点号node_id,其中结点号为0的结点为主结点。然后为每个虚拟处理器分配一个逻辑的vcpu_id,从0开始计数,并且服务器内的vcpuid是连续分配的。对于虚拟处理器的vpu_id_global标识,通过计算该虚拟处理器在全局的序号来指定。我们将虚拟处理器所在的物理服务器信息反映到vlapic_id中,以便可以迅速的定位该虚拟处理器。同时,为了使得虚拟处理器可以在物理处理器上迁移,我们的虚拟处理器不进行多核结构的设置。所以将8bit的虚拟处理器的vlapic_id域分为两个部分,低三个bit用来标识该vcpu在本服务器内的序号,这个序号在数值上等于其vcpu_id。高五个bit用来标识该虚拟处理器所在的服务器号。
步骤4:确定对虚拟处理器信息的获取方式。根据vcpu的管理方法,其node_id,vcpu_id,vlapic_id是可以通过计算得到的。例如计算vlapic_id采用如下方法:
vlapic_id=node_id<<3+vcpu_id (1)
对于所在的物理服务器号为t的vcpu来说,其vcpu_id_global的计算方式如下,其中vcpu_nr(i)是服务器i上的vcpu数量:
获取某个虚拟处理器所在的物理服务器号采用下面的方法:
node_id=vlapic_id>>3 (3)
另外,我们还在每个服务器上维护了一个全局的虚拟处理器资源信息表,某些不能通过计算得到的信息,例如虚拟处理器的dfr信息等,需要通过查表得到。
步骤5:将虚拟处理器信息向guest进行呈现。全局的虚拟处理器资源就是guest能够使用的处理器资源,我们需要guest能够正确的识别到这些虚拟处理器,并能够正常初始化它们。在这里为guest提供整合后的虚拟处理器资源信息,主要是根据虚拟处理器的分布情况,制作基于多处理器规范的MP表以及基于ACPI规范的acpi表,并将其放到guest的内存区域的适当位置,目的是在guest启动的时候通过读取这些表项感知其所拥有的处理器资源信息。对于MP表,主要是修改Processor Entries,为每个虚拟处理器生成一个ProcessorEntry。对于ACPI表,主要是修改Multiple APIC Description Table(MADT)的Processor Local APIC Structure,还要根据虚拟处理器信息制作processor_objects表项。将这些表项写入guest的内存,并索引到MP规范和ACPI规范的头部区域后,guest启动时便可以读到这些虚拟的处理器信息,从而对占有的处理器资源有一个概况。
至此,hypervisor层对于虚拟处理器资源信息的准备工作已经完毕,接下来就是启动客户操作***,并在其执行过程中对其行为进行模拟。
步骤6:对guest多处理器启动过程进行模拟。为了让客户操作***能够真正感知并使用底层分散在各个物理服务器中的虚拟处理器资源,还要对guest的多处理器启动过程进行跟踪和模拟。Guest首先读取MP和ACPI相关表项,确定处理器资源信息,然后通过发送SIPI中断来启动和初始化虚拟处理器。虚拟处理器发送SIPI中断的时候是通过向ICR寄存器写入数据实现的,向虚拟ICR写入地址时会被捕获到,此时在主物理服务器BSP退出的路径中,根据ICR的内容判断是否是发送SIPI,然后判断要启动的虚拟AP是否在本服务器内部,如果是的话,则直接将虚拟的跳板程序从虚拟ICR中解析出来,然后对目标AP做最后的初始化,主要是设置其虚拟控制结构体中的一些重要寄存器信息,其中重点是将跳板程序的地址写入,作为虚拟处理器进入时程序的执行起点。然后将被启动的虚拟处理器唤醒,使其为可执行状态并加入调度器队列,等到被调度到的时候进入非根模式,开始执行客户操作***的代码。如果目标AP不在主物理服务器上,则需要将SIPI信息打包成网络信息包,发送给目标AP所在的物理服务器。当目标服务器接收到信息包之后,判断如果是SIPI信息包,那么首先需要将SIPI的目标AP的vlapic_id解析出来进行判断,如果该AP确实在本物理服务器,那么紧接着从该信息包中解析出跳板程序的地址,然后对目标AP进行最后的初始化,将跳板程序地址写入虚拟控制结构体中。接下来的过程跟单机内一样,调用唤醒模块将目标虚拟处理器唤醒并加入调度队列,等下一次被调度的时候调用虚拟机进入模块,进入非根模式,执行客户操作***的代码。
步骤7:在客户操作***执行过程中,对其指令集进行必要的模拟。在多服务器的条件下,需要模拟的指令大致分为三类,一些指令只需要在物理服务器内进行模拟,而有一些敏感指令或者行为(例如发送跨处理器中断)会引发跨物理服务器的处理器操作,这时需要物理服务器之间协调完成指令的模拟。还有一些指令会间接引发跨物理服务器操作,或者受到全局资源整合的影响,这时也需要在全局资源视图下,通过跨物理服务器的操作对指令模拟进行辅助,保证指令的正确模拟。敏感指令的模拟如图3所示。
第一类,与全局vcpu资源整合无关的敏感指令模拟。某些指令只需要在物理服务器内进行模拟,其模拟过程中也只是涉及本地的一些寄存器操作,而不涉及跨物理服务器操作。例如对HLT,VMMCALL等指令的模拟。对这些指令的模拟只需根据其含义,在单机内进行模拟,并将模拟结果通过其虚拟寄存器等返回到客户操作***。
第二类,直接引发跨物理服务器操作的指令模拟。这些指令的模拟可能直接引发跨物理服务器操作。例如IO操作,无论是以IN/OUT/INS/OUTS指令为主的直接IO访问(PIO),还是以MOV/MOVS等内存操作指令为主的内存映射IO访问(MMIO),都有可能因为要访问的设备在远端物理服务器而不在本地,而产生跨物理服务器操作。对于直接IO访问操作,hypervisor通过捕获IN/OUT/INS/OUTS等指令来截获guest操作。对于内存映射IO访问,hypervisor通过设备映射内存区的缺页异常来捕获guest操作。IO操作被捕获后,hypervisor判断目标设备是否在本地。如果在本地,则直接进行指令模拟、IO操作等。如果目标设备不在本地,则需要hypervisor将IO操作信息进行分析,抽取出IO操作类型,目标端口地址、读写、数据或数据所在内存地址等信息,连同物理服务器id、处理器id等环境信息一起制作成网络信息包,发送给目标设备所在的物理服务器。在设备对guest可见的情况下,目标服务器解析传来的数据包,将IO操作在本地还原,完成IO操作,然后将操作是否成功的信息发回给请求端服务器,同时,如果IO操作时是读数据的操作,并且不是往guest的内存里读,则需要将读出的数据一并发回给请求端服务器。如果设备是由模拟器虚拟的,则目标服务器收到IO操作网络包后,将IO请求发给设备模拟器处理。
第三类,间接受到跨物理服务器影响的指令模拟。这些指令的模拟会间接受到跨物理服务器条件的影响,这些影响主要包括在模拟过程中需要用到跨物理服务器的资源整合信息,或者会间接引发跨物理服务器操作。对于需要用到跨物理服务器的资源整合信息的指令模拟,例如CPUID指令获取apic_id的操作。当指令被捕获后,需要根据整合后的全局虚拟处理器资源信息,来模拟指令想要的结果,并将结果返回给客户操作***。
会间接引发跨物理服务器操作的指令,其典型代表是如mov_to_cr、movs等指令。在对这些指令的模拟过程中,指令操作数可能在guest内存中。当涉及到客户操作***内存访问操作的时候,需要注意缺页问题,也就是所需页面不在本地的情况,此时需要调用DSM算法请求远程页面的拷贝。对于非敏感指令和行为中操作数造成的缺页,只需由hypervisor将页面拷贝过来,然后即可返回客户操作***继续执行。对于需要访问客户操作***页面,要由hypervisor主动的调用DSM模块。通过DSM算法将有效页面迁移过来,并进一步得到操作数本身。进而完成对指令的模拟。