Certains contenus de cette application ne sont pas disponibles pour le moment.
Si cette situation persiste, veuillez nous contacter àObservations et contact
1. (WO2018112855) PROCÉDÉ ET DISPOSITIF DE VIRTUALISATION, DISPOSITIF ÉLECTRONIQUE, ET PRODUIT PROGRAMME INFORMATIQUE
Document

说明书

发明名称 0001   0002   0003   0004   0005   0006   0007   0008   0009   0010   0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123  

权利要求书

1   2   3   4   5   6   7   8   9   10   11   12  

附图

0001   0002   0003   0004   0005   0006   0007  

说明书

发明名称 : 一种虚拟化方法、装置、及电子设备、计算机程序产品

技术领域

[0001]
本申请涉及计算机技术,具体地,涉及一种虚拟化方法、装置、及电子设备、计算机程序产品。

背景技术

[0002]
图1中示出了基于Qemu/KVM(Kernel-based Virtual Machine,基于内核的虚拟机)技术的虚拟化架构。
[0003]
如图1所示,基于Qemu/KVM技术的虚拟化架构由一个主Host操作系统,若干个虚拟出来的客Guest操作系统组成。Host操作系统包括多个Host用户空间程序、Host Linux内核。每个客Guest操作系统分别包括用户空间、Guest Linux内核、和模拟处理器Qemu。这些操作系统运行在同一套硬件处理器芯片上,共享处理器及外设资源。支持虚拟化架构的ARM处理器至少包含EL2,EL1,EL0三种模式,EL2模式下运行虚拟机管理器Hypervisor程序;EL1模式下运行Linux内核程序,即,Linux kernel程序;EL0模式下运行用户空间程序。Hypervisor层管理CPU、内存、定时器、中断等硬件资源,并通过CPU、内存、定时器、中断的虚拟化资源,可以把不同的操作系统分时加载到物理处理器上运行,从而实现系统虚拟化的功能。
[0004]
KVM/Hypervisor跨越Host Linux kernel和Hypervisor两层,一方面为Qemu提供驱动节点,即,允许Qemu通过KVM节点创建虚拟CPU,并管理虚拟化资源;另一方面KVM/Hypervisor还可以把Host Linux系统从物理CPU上切换出去,然后把Guest Linux系统加载到物理处理器上运行,并处理Guest Linux系统异常退出的后续事务。
[0005]
Qemu作为Host Linux的一个应用运行,为Guest Linux的运行提供虚拟 的硬件设备资源,通过KVM/Hypervisor模块的设备KVM节点,创建虚拟CPU,分配物理硬件资源,实现把一个未经修改的Guest Linux加载到物理硬件处理上去运行。
[0006]
在手机或平板等终端设备上实现上述虚拟化架构,需要解决所有硬件设备的虚拟化,允许虚拟出来的操作系统也能使用真实的硬件设备。
[0007]
在现有技术的虚拟化方案中,通常是由Guest操作系统中的前端线程在接收到用户操作时,调用相应的API(Application Program Interface,应用接口),产生对应的处理指令;然后将该处理指令传递至Host操作系统中运行的、与该API对应的后台服务器Backend Server中的、该前端线程对应的后端线程,并由后端线程驱动相应的硬件设备或模块执行相应操作、然后将执行结果作为应用接口调用指令的响应。
[0008]
采用现有技术中的虚拟化方案,对于API调用指令的响应过程比较长,因此导致对用户操作的响应耗时较长,影响用户体验。
[0009]
发明内容
[0010]
本申请实施例中提供了一种虚拟化方法、装置、及电子设备、计算机程序产品,主要用于缩短虚拟化系统中对于API调用指令的响应过程。
[0011]
根据本申请实施例的第一个方面,提供了一种虚拟化方法,应用于多核处理器,包括:将前端线程与后端线程绑定至同一物理中央处理器CPU;其中,该前端线程用于根据在第一操作系统处接收到的应用接口调用指令,确定该应用接口调用指令对应的处理指令,并将该处理指令发送至第二操作系统处的相应后端线程;该后端线程,用于在第二操作系统处,接收和执行该处理指令,并将处理结果作为该应用接口调用指令的响应或者返回给前端线程。
[0012]
根据本申请实施例的第二个方面,提供了一种虚拟化装置,应用于多核处理器,包括:绑定模块,用于将前端线程与后端线程绑定至同一物理中央 处理器CPU;其中,该前端线程用于根据在第一操作系统处接收到的应用接口调用指令,确定该应用接口调用指令对应的处理指令,并将该处理指令发送至第二操作系统处的相应后端线程;该后端线程,用于在第二操作系统处,接收和执行该处理指令,并将处理结果作为该应用接口调用指令的响应或者返回给前端线程。
[0013]
根据本申请实施例的第三个方面,提供了一种电子设备,该电子设备包括:显示器,存储器,一个或多个处理器;以及一个或多个模块,该一个或多个模块被存储在该存储器中,并被配置成由该一个或多个处理器执行,该一个或多个模块包括用于执行本申请实施例的第一个方面的虚拟方法中各个步骤的指令。
[0014]
据本申请实施例的第四个方面,提供了一种计算机程序产品,该计算机程序产品对用于执行一种过程的指令进行编码,该过程包括本申请实施例的第一个方面的虚拟方法。
[0015]
采用根据本申请实施例的虚拟化方法、装置、及电子设备、计算机程序产品,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。

附图说明

[0016]
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
[0017]
图1中示出了基于Qemu/KVM技术的虚拟化架构示意图;
[0018]
图2示出了用于实施本申请实施例中的虚拟化方法的一种系统架构;
[0019]
图3示出了根据本申请实施例一的虚拟化方法的流程图;
[0020]
图4示出了根据本申请实施例二的虚拟化方法的流程图;
[0021]
图5示出了根据本申请实施例三的虚拟化方法的流程图;
[0022]
图6示出了根据本申请实施例四的虚拟化装置的结构示意图;
[0023]
图7示出了根据本申请实施例五的电子设备的结构示意图。

具体实施方式

[0024]
在实现本申请的过程中,发明人发现,在现有技术的虚拟化方案中,在多核处理器中创建某一线程时,由Linux kernel根据预先设置的策略调度该线程运行的虚拟CPU,例如,根据负载均衡原则调度、根据轮询原则调度等;因此,某一线程运行于哪个虚拟CPU是不确定的;同时,Qemu在创建虚拟CPU时,也是由Linux kernel根据预先设置的策略调度虚拟CPU运行的物理CPU,例如,根据负载均衡原则、或者根据轮询原则调度等,因此,虚拟CPU与物理CPU之间的对应关系也是不确定的。因此,系统中的线程运行于哪个物理CPU是不确定。
[0025]
发明人认为,上述线程和虚拟CPU的调度策略会导致现有技术中的虚拟化方案中,Guest操作系统中运行的前端线程和Host操作系统中运行的、与该前端线程对应的后端线程通常会运行于不同的物理CPU上,从而使得在实现虚拟化的过程中,前端线程和后端线程之间进行切换时,同时也是在Guest操作系统和Host操作系统之间进行切换时,需要在不同物理CPU之间切换,从而导致对应用接口调用指令的响应耗时较长,这样当对于一些用户操作的相应时间也会比较长,影响用户体验。
[0026]
针对上述问题,本申请实施例中提供了一种虚拟化方法、装置、系统及电子设备、计算机程序产品,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。
[0027]
本申请实施例中的方案可以应用于各种场景中,例如,采用基于 Qemu/KVM技术的虚拟化架构的、多操作系统的多核智能终端、安卓模拟器等。
[0028]
本申请实施例中的方案可以采用各种计算机语言实现,例如,面向对象的程序设计语言Java等。
[0029]
为了使本申请实施例中的技术方案及优点更加清楚明白,以下结合附图对本申请的示例性实施例进行进一步详细的说明,显然,所描述的实施例仅是本申请的一部分实施例,而不是所有实施例的穷举。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
[0030]
实施例一
[0031]
图2示出了用于实施本申请实施例中的虚拟化方法的一种系统架构。
[0032]
如图2所示,根据本申请实施例的虚拟化系统应用于包括多个物理CPU201a、201b、201c和201d的电子设备中,并且在该电子设备中,创建了多个虚拟CPU 202a、202b、202c、和202d;并基于Qemu/KVM技术创建有第一操作系统203和第二操作系统204。
[0033]
具体地,该第一操作系统可以是Guest操作系统;该第二操作系统可以是Host操作系统。应当理解,在具体实施时,该第一操作系统也可以是Host操作系统,该第二操作系统也可以是Guest操作系统,本申请对此不作限制。
[0034]
为了示例的目的,图2中仅示出了四核处理器、分别对应于四核处理器的四个虚拟CPU的情况。但应当理解,在具体实施时,也可以是例如2、3、5、8等其他任意复数个数的物理CPU,虚拟CPU的数量也可以是例如5、6、8、10等其他任意复数个数。在具体设置虚拟CPU的数量时,可以与物理CPU的数量为1:1,也可以设置为2:1等;通常可以设置虚拟CPU的数量大于等于物理CPU的数量;本申请对此均不作限制。
[0035]
为了示例的目的,图2中仅示出了一个Guest操作系统、一个Host操作系统的情况。但应当理解,在具体实施时,也可以是一个或多个Guest操作系 统,也可以是一个或多个Host操作系统;即,对于Guest操作系统、Host操作系统可以为任意的数量,本申请对此均不作限制。
[0036]
接下来,将以物理CPU为4个,待创建的虚拟CPU与物理CPU的数量为1:1;同时第一操作系统为Guest操作系统,第二操作系统为Host操作系统为例,对本申请的具体实施方式进行详细介绍。
[0037]
具体地,Guest操作系统203中可以包括用户空间2031、Guest Linux Kernel2032、和Qemu 2033;在Guest操作系统的用户空间中可以提供有虚拟的多种硬件设备或模块的接口,具体地,该多种接口可以包括图形程序接口、多媒体程序接口、编解码接口等;更具体地,例如,该图形程序接口可以是OpenGL(Open Graphics Library,开放图形实验室)API接口、Direct 3D、Quick Draw 3D等图形程序接口,该多媒体/视频程序接口可以是OpenMAX(Open Media Acceleration,开放多媒体加速层)接口等,本申请对此不作限制。
[0038]
具体地,Host操作系统204中可以包括用户空间2041和Host Linux Kernel2042;在Host操作系统的用户空间中可以提供对应于Guest操作系统中的各接口的后端服务器Backend Server。例如,Guest操作系统中的图形程序接口为OpenGL API时,后端服务器可以是OpenGL Backend Server;后端服务器可以通过Host Linux Kernel中的GPU驱动程序去操作GPU设备;Guest操作系统中的多媒体/视频程序接口为OpenMAX API时,后端服务器可以是OpenMAX Backend Server;后端服务器可以通过Host Linux Kernel中的多媒体/视频驱动程序去操作相应的多媒体/视频设备。
[0039]
接下来,将结合图2所示系统架构对根据本申请实施例的虚拟化方法进行描述。
[0040]
图3示出了根据本申请实施例一的虚拟化方法的流程图。在本申请实施例一中,描述了以Guest操作系统作为执行主体的虚拟化方法的步骤。如图3所示,根据本申请实施例的GPU的虚拟化方法包括以下步骤:
[0041]
S301,在创建虚拟CPU时,在Qemu处建立各虚拟CPU与各物理CPU 的对应关系。
[0042]
在具体实施时,可以在Qemu创建虚拟CPU时,将维护各虚拟CPU的各个线程分别绑定至相应的物理CPU。例如,将创建的第一个虚拟CPU绑定至物理CPU 201a,将创建的第二个虚拟CPU绑定至物理CPU 201b,将创建的第三个虚拟CPU绑定至物理CPU 201c,第四个虚拟CPU绑定至物理CPU201d等。具体地,将虚拟CPU绑定至某一物理CPU的具体实施可以采用本领域技术人员的常用技术手段,本申请对此不赘述。
[0043]
S302,接收在第一操作系统处执行的应用接口调用指令,根据用户操作调用对应的前端线程,并确定处理指令。
[0044]
在具体实施时,用户可以针对Guest操作系统中的某一线程执行用户操作,例如,用户可以在微信、QQ等线程中,执行打开一个新窗口,打一个新页面等、播放多媒体/视频等的操作。
[0045]
在具体实施时,当接收到用户操作时,线程会根据用户操作产生一个API调用指令调用对应的前端线程,例如,当用户执行的是打开一个新窗口,打一个新页面等的操作时,可以调用对应的图形处理接口,当用户执行的是播放多媒体/视频等操作时,可以调用对应的多媒体/视频接口等。
[0046]
在具体时,当调用对应的前端线程后,可以进一步根据用户的具体操作内容,确定处理指令;具体地,该处理指令可以是新建一个窗口、页面;编码一段视频的指令,具体的,该处理指令可以包括下述代码的一种或多种:处理函数、参数、同步信息、内容数据等,本申请对此不作限制。
[0047]
S303,将前端线程绑定至一虚拟CPU。
[0048]
在具体实施时,可以在将前端线程绑定至调用该前端线程的线程所运行的虚拟CPU。例如,调用该前端线程的线程是微信,则可以将前端线程绑定至微信所运行的虚拟CPU。
[0049]
具体地,可以在该前端线程启动时,即,可以在Guest操作系统初始化API的调用时,获取调用该API的线程所运行的虚拟CPU的标识。具体地, 该虚拟CPU的标识可以是虚拟CPU的编号。并将该前端线程,即,API绑定至对应的虚拟CPU。具体地,获取调用该API的线程的虚拟CPU的编号可以采用本领域技术人员的常用技术手段,例如,可以由调用该API的线程检测自身所运行的虚拟CPU的编号,本申请在此不作赘述。
[0050]
至此,由于虚拟CPU与物理CPU存在固定的对应关系,通过S301-S303,可以将一前端线程绑定至一指定物理CPU。
[0051]
S304,将该虚拟CPU的标识发送至第二操作系统。
[0052]
在具体实施时,可以将虚拟CPU的标识单独发送至第二操作系统,也可以将虚拟CPU的标识携带在其他消息中发送至第二操作系统。
[0053]
具体地,在调用前端线程时,通常会触发Host操作系统创建与该前端线程相对应的后端线程。为了使后端线程与前端线程绑定至同一物理CPU,可以在前端线程和后端线程之间的通道初始化信息中,携带虚拟CPU的标识,并将通道初始化信息发送至Host操作系统。以使得Host操作系统可以在相应接口的后台服务器中创建与前端线程相对应的后端线程,并且可以进一步将该后端线程绑定至该虚拟CPU。
[0054]
至此,通过S301-S304,可以将一前端线程和其对应的后端线程绑定至同一指定物理CPU。
[0055]
应当理解,如果在S302之前,第一操作系统中已经建立起对应于该应用接口调用指令的前端线程,且该前端线程已经被绑定至相应的虚拟CPU,则在再次调用该前端线程时,可以不再重复执行步骤S303和S304。
[0056]
S305,将处理指令发送至后端线程;以使后端线程执行该处理指令,并得到处理结果。
[0057]
在具体实施时,处理指令的发送可以采用多种本领域技术人员的常规发送方式,本申请在此不做赘述。
[0058]
在具体实施时,从前端线程至后端线程的切换,以及第一操作系统和第二操作系统之间的切换均采用本领域技术人员的常用技术手段,本申请对此 不作赘述。
[0059]
在具体实施时,后端线程驱动相应的硬件设备/模块执行相应的处理指令,并得到处理结果。
[0060]
应当理解,步骤S304和S305并没有严格的时序关系,可以先执行S304,再执行S305,也可以先执行S305,再执行S304;还可以同步执行S304和S305,本申请对此均不作限制。
[0061]
在具体实施时,后端线程可以将该处理结果直接作为应用接口调用指令的响应反馈给用户,也可以将该处理结果返回给前端线程,由前端线程响应用户操作。
[0062]
至此,实现了Guest操作系统中用户程序对硬件设备/模块的远程调用;即,实现了前端线程与后端线程运行于同一物理CPU的虚拟化方案。
[0063]
采用本申请实施例中的虚拟化方法,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。
[0064]
实施例二
[0065]
图4示出了根据本申请实施例二的虚拟化方法的流程图。在本申请实施例二中,描述了以Host操作系统作为执行主体的虚拟化方法的步骤。本申请实施例中的系统架构的实施可以参见实施例一中图2所示的系统架构,重复之处不再赘述。
[0066]
如图4所示,根据本申请实施例的虚拟化方法包括以下步骤:
[0067]
S401,第二操作系统确定前端线程绑定的虚拟CPU,并将后端线程绑定至该虚拟CPU,其中,该虚拟CPU与物理CPU存在对应关系。
[0068]
在具体实施时,虚拟CPU与物理CPU的对应关系的建立可以参考本申请 实施例一中S301的实施,重复之处不再赘述。
[0069]
在具体实施时,Host操作系统可以在后台服务器中创建相应的后端线程时,确定前线程绑定的虚拟CPU,并将后端线程绑定至该虚拟CPU。具体地,如果Guest操作系统将前端线程绑定的虚拟CPU的标识,例如,编号,携带在前后端线程的通道初始化信息中发送至Host操作系统,则Host操作系统可以从通道初始化信息中提取相应的虚拟CPU的编号,并在创建后端线程后,将后端线程绑定至该虚拟CPU。
[0070]
至此,已经将前端线程和后端线程绑定至同一物理CPU。
[0071]
S402,在第二操作系统处的后端线程获取来自第一操作系统处的前端线程的处理指令;
[0072]
在具体实施时,从前端线程至后端线程的切换,以及第一操作系统和第二操作系统之间的切换均采用本领域技术人员的常用技术手段,本申请对此不作赘述。
[0073]
在具体实施时,具体地,该处理指令可以是新建一个窗口、页面;编码一段视频的指令,具体的,该处理指令可以包括下述代码的一种或多种:处理函数、参数、同步信息、内容数据等,本申请对此不作限制。
[0074]
在具体实施时,处理指令的获取可以采用多种本领域技术人员的常规获取方式,本申请在此不做赘述。
[0075]
S403,在后端线程处执行处理指令,并得到处理结果;将处理结果作为处理操作的响应,其中,处理操作与处理指令对应。
[0076]
在具体实施时,后端服务器中的后端线程驱动相应的硬件设备/模块执行该处理指令,并得到响应于该处理操作的处理结果。
[0077]
应当理解,如果在S402之前,第二操作系统中已经建立与前端线程相对应的后端线程,且该后端线程已经被绑定至相应的虚拟CPU,则在再次调用该后端线程时,可以不再重复执行步骤S401,而是直接执行S402和S403即可。
[0078]
至此,实现了在Host操作系统中,配合Guest操作系统中的用户程序对硬件设备/模块的远程调用;即,实现了前端线程与后端线程运行于同一物理CPU的虚拟化方案。
[0079]
采用本申请实施例中的虚拟化方法,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。
[0080]
实施例三
[0081]
图5示出了根据本申请实施例三的虚拟化方法的流程图。在本申请实施例三中,描述了Guest操作系统与Host操作系统配合实现虚拟化方法的步骤。本申请实施例中的系统架构的实施可以参见实施例一中图2所示的系统架构,重复之处不再赘述。
[0082]
在本申请实施例中,API函数远程调用的发起方为Guest操作系统,函数执行方为Host操作系统,从Guest操作系统到Host操作系统的下行同步过程经历Guest Linux kernel、Qemu到达Backend Server;从Host操作系统到Guest操作系统的上行同步过程从Backend Server发起,经过Qemu、Guest Linux kernel到达emulator API。
[0083]
接下来,将对基于上述应用场景的虚拟方法的实施过程进行详细描述。
[0084]
如图5所示,根据本申请实施例三的虚拟化方法包括以下步骤:
[0085]
S501,在创建虚拟CPU时,Qemu将维护虚拟CPU的各个线程分别绑定到固定的物理CPU。
[0086]
例如,在4核的处理器芯片上实现虚拟化,并创建4个虚拟CPU,则可以把Qemu创建虚拟CPU0的线程绑定到物理CPU0上,以此类推,创建虚拟CPU3的线程绑定到物理CPU3上。
[0087]
S502,Guest操作系统接收应用接口调用指令。
[0088]
在具体实施时,Guest操作系统可以通过操作系统,也可以通过操作系统中的某一线程接收用户操作。例如,用户可以针对Guest操作系统中的某一线程执行用户操作,例如,在微信、QQ等线程中,执行打开一个新窗口,打一个新页面等、播放多媒体/视频等的操作。这些线程在接收到用户操作后,通常会产生API调用指令。
[0089]
S503,Guest操作系统创建前端线程时,检测调用前端线程的线程所在的虚拟CPU编号。
[0090]
在具体实施时,调用前端线程的线程,也就是发起API远程调用的线程可以是接收用户操作的线程。例如,可以是微信、QQ等用户程序。
[0091]
在具体实施时,可以采用本领域技术人员的常用技术手段,检测调用该API的线程的虚拟CPU的编号,本申请在此不作赘述。
[0092]
S504,Guest操作系统将前端线程绑定在此虚拟CPU上运行,并把虚拟CPU编号传给Host操作系统中的对应Backend Server。
[0093]
在具体实施时,可以将虚拟CPU编号单独发送至Backend Server,也可以将虚拟CPU的编号携带在其他消息,例如,通道初始化消息中发送至Backend Server。
[0094]
应当理解,该Backend Server可以是与前端线程对应的后台服务器,例如,如果前端线程是图形程序接口,则对应的Backend Server是图形程序后台服务器,如果前端线程是多媒体/视频接口,则对应的Backend Server是多媒体/视频后台服务器。
[0095]
S505,Backend Server在创建后端线程时,将后端线程绑定至Guest操作系统指定的虚拟CPU。
[0096]
在具体实施时,如果Guest操作系统将虚拟CPU编号单独发送至Backend Server;则Backend Server在创建后续线程时,获取该虚拟CPU编号;如果Guest操作系统将虚拟CPU的编号携带在通道初始化消息中发送至Backend Server,则Backend Server从通道初始化消息中提取该CPU编号,并进行绑定。
[0097]
应当理解,为提高效率,当前端线程和对应的后端线程被绑定至同一物理CPU之后,在接下来的虚拟化过程中,可以直接进行API的远程调用,而不需要再次重复绑定;即,可以不再执行前端线程和后端线程绑定至同一物理CPU的步骤,即,S503-S505。
[0098]
S506,前端线程将处理指令发送给后端线程。
[0099]
在具体实施时,本步骤的实施可以参考本申请实施例一的S305和本申请实施例二的S402,重复之处不再赘述。
[0100]
S507,在后端线程处执行处理指令,并得到处理结果;将处理结果作为应用接口调用指令的响应,或者返回给前端线程。
[0101]
在具体实施时,本步骤的实施,可以参考本申请实施例二中步骤S403的实施,重复之处不再赘述。
[0102]
至此,实现了在多核处理器中,多个操作系统之间用户程序对硬件设备/模块的远程调用;即,实现了前端线程与后端线程运行于同一物理CPU的虚拟化方案。
[0103]
采用本申请实施例中的虚拟化方法,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。
[0104]
基于同一发明构思,本申请实施例中还提供了一种虚拟化装置,应用于多核处理器,由于该装置解决问题的原理与本申请实施例一所提供的虚拟化方法的相似,因此该装置的实施可以参见方法的实施,重复之处不再赘述。
[0105]
实施例四
[0106]
图6示出了根据本申请实施例四的虚拟化装置的结构示意图。
[0107]
如图6所示,根据本申请实施例四的虚拟化装置600包括:绑定模块601,用于将前端线程与后端线程绑定至同一物理中央处理器CPU;其中,该前端线程用于根据在第一操作系统处接收到的应用接口调用指令,确定该应用接口调用指令对应的处理指令,并将该处理指令发送至第二操作系统处的相应后端线程;该后端线程,用于在第二操作系统处,接收和执行该处理指令,并将处理结果作为该应用接口调用指令的响应或者返回给前端线程。
[0108]
具体地,绑定模块,具体包括:对应关系建立子模块,用于在模拟处理器Qemu处建立各虚拟CPU与各物理CPU的对应关系;第一绑定子模块,用于在第一操作系统处,将该前端线程绑定至一虚拟CPU;并将所绑定的虚拟CPU的标识发送至第二操作系统;第二绑定子模块,用于在第二操作系统中,从该第一操作系统处接收该虚拟CPU的标识,将该后端线程绑定至该虚拟CPU。
[0109]
具体地,对应关系建立子模块,具体用于:在Qemu创建虚拟CPU时,将维护各虚拟CPU的各个线程分别绑定至相应的物理CPU。
[0110]
具体地,第一绑定子模块,具体用于:获取调用该前端线程的线程所运行的虚拟CPU的标识,该标识用于标识该虚拟CPU;将该前端线程绑定至该虚拟CPU标识对应的虚拟CPU;将所绑定的虚拟CPU的标识发送至第二操作系统。
[0111]
具体地,第一绑定子模块,具体用于:在该前端线程启动时,获取调用该前端线程的线程所运行的虚拟CPU的标识;在该前端线程和该后端线程之间的通道初始化信息中,携带该虚拟CPU的标识,并将该通道初始化信息发送至该第二操作系统;第二绑定子模块,具体用于:从该第一操作系统处接收该前端线程与该后端线程之间的通道初始化信息,其中,该通道初始化信息中携带该虚拟CPU的标识;从该通道初始化信息中提取该虚拟CPU的标识,将该后端线程绑定至该虚拟CPU。
[0112]
采用本申请实施例中的虚拟化装置,将前端线程和对应的后端线程绑定至同一物理CPU,从而使得在虚拟化过程中,Guest操作系统和Host操作系统之间的切换、以及前端线程和后端线程的切换,能够在同一物理CPU上执行,从而缩短切换时间,减少对应用接口调用指令的响应时间,提升用户体验。
[0113]
实施例五
[0114]
基于同一发明构思,本申请实施例中还提供了如图7所示的一种电子设备700。
[0115]
如图7所示,根据本申请实施例五的电子设备700包括:显示器701,存储器702,一个或多个处理器703;总线704;以及一个或多个模块,该一个或多个模块被存储在该存储器中,并被配置成由该一个或多个处理器执行,该一个或多个模块包括用于执行根据本申请实施例一至三中任一方法中各个步骤的指令。
[0116]
基于同一发明构思,本申请实施例中还提供了一种计算机程序产品,该计算机程序产品对用于执行一种过程的指令进行编码,所述过程包括根据本申请实施例一中的各个步骤的虚拟方法。
[0117]
在具体实施时,该计算机程序产品可以与电子设备700结合使用。
[0118]
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
[0119]
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程 和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0120]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0121]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0122]
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
[0123]
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

权利要求书

[权利要求 1]
一种虚拟化方法,应用于多核处理器,其特征在于,包括: 将前端线程与后端线程绑定至同一物理中央处理器CPU;其中, 所述前端线程用于根据在第一操作系统处接收到的应用接口调用指令,确定所述应用接口调用指令对应的处理指令,并将所述处理指令发送至第二操作系统处的相应后端线程; 所述后端线程,用于在第二操作系统处,接收和执行所述处理指令,并将处理结果作为所述应用接口调用指令的响应或者返回给前端线程。
[权利要求 2]
根据权利要求1所述的方法,其特征在于,将前端线程与后端线程绑定至同一物理中央处理器CPU,具体包括: 在模拟处理器Qemu处建立各虚拟CPU与各物理CPU的对应关系; 在第一操作系统处,将所述前端线程绑定至一虚拟CPU;并将所绑定的虚拟CPU的标识发送至第二操作系统; 在第二操作系统中,从所述第一操作系统处接收所述虚拟CPU的标识,将所述后端线程绑定至所述虚拟CPU。
[权利要求 3]
根据权利要求2所述的方法,其特征在于,在Qemu处建立各虚拟CPU与各物理CPU的对应关系,具体包括: 在Qemu创建虚拟CPU时,将维护各虚拟CPU的各个线程分别绑定至相应的物理CPU。
[权利要求 4]
根据权利要求2所述的方法,其特征在于,将前端线程绑定至一虚拟CPU,具体包括: 获取调用所述前端线程的线程所运行的虚拟CPU的标识,所述标识用于标识所述虚拟CPU; 将所述前端线程绑定至所述虚拟CPU标识对应的虚拟CPU。
[权利要求 5]
根据权利要求4所述的方法,其特征在于,获取调用所述前端线程的线程所运行的虚拟CPU的标识,具体包括: 在所述前端线程启动时,获取调用所述前端线程的线程所运行的虚拟CPU的标识; 并将所绑定的虚拟CPU的标识发送至第二操作系统,具体包括:在所述前端线程和所述后端线程之间的通道初始化信息中,携带所述虚拟CPU的标识,并将所述通道初始化信息发送至所述第二操作系统; 从所述第一操作系统处接收所述虚拟CPU的标识,具体包括: 从所述第一操作系统处接收所述前端线程与所述后端线程之间的通道初始化信息,其中,所述通道初始化信息中携带所述虚拟CPU的标识; 从所述通道初始化信息中提取所述虚拟CPU的标识。
[权利要求 6]
一种虚拟化装置,应用于多核处理器,其特征在于,包括: 绑定模块,用于将前端线程与后端线程绑定至同一物理中央处理器CPU;其中, 所述前端线程用于根据在第一操作系统处接收到的应用接口调用指令,确定所述应用接口调用指令对应的处理指令,并将所述处理指令发送至第二操作系统处的相应后端线程; 所述后端线程,用于在第二操作系统处,接收和执行所述处理指令,并将处理结果作为所述应用接口调用指令的响应或者返回给前端线程。
[权利要求 7]
根据权利要求6所述的装置,其特征在于,绑定模块,具体包括: 对应关系建立子模块,用于在模拟处理器Qemu处建立各虚拟CPU与各物理CPU的对应关系; 第一绑定子模块,用于在第一操作系统处,将所述前端线程绑定至一虚拟CPU;并将所绑定的虚拟CPU的标识发送至第二操作系统; 第二绑定子模块,用于在第二操作系统中,从所述第一操作系统处接收所述虚拟CPU的标识,将所述后端线程绑定至所述虚拟CPU。
[权利要求 8]
根据权利要求7所述的装置,其特征在于,对应关系建立子模块,具体用于: 在Qemu创建虚拟CPU时,将维护各虚拟CPU的各个线程分别绑定至相应的物理CPU。
[权利要求 9]
根据权利要求7所述的装置,其特征在于,第一绑定子模块,具体用于: 获取调用所述前端线程的线程所运行的虚拟CPU的标识,所述标识用于标识所述虚拟CPU; 将所述前端线程绑定至所述虚拟CPU标识对应的虚拟CPU; 将所绑定的虚拟CPU的标识发送至第二操作系统。
[权利要求 10]
根据权利要求9所述的装置,其特征在于,第一绑定子模块,具体用于: 在所述前端线程启动时,获取调用所述前端线程的线程所运行的虚拟CPU的标识;在所述前端线程和所述后端线程之间的通道初始化信息中,携带所述虚拟CPU的标识,并将所述通道初始化信息发送至所述第二操作系统; 第二绑定子模块,具体用于: 从所述第一操作系统处接收所述前端线程与所述后端线程之间的通道初始化信息,其中,所述通道初始化信息中携带所述虚拟CPU的标识; 从所述通道初始化信息中提取所述虚拟CPU的标识,将所述后端线程绑定至所述虚拟CPU。
[权利要求 11]
一种电子设备,其特征在于,所述电子设备包括:显示器,存储器,一个或多个处理器;以及一个或多个模块,所述一个或多个模块被存储在所述存储器中,并被配置成由所述一个或多个处理器执行,所述一个或多个模块包括用于执行权利要求1-5中任一所述方法中各个步骤的指令。
[权利要求 12]
一种计算机程序产品,所述计算机程序产品对用于执行一种过程的指令进行编码,所述过程包括根据权利要求1-5中任一项所述的方法。

附图

[ 图 0001]  
[ 图 0002]  
[ 图 0003]  
[ 图 0004]  
[ 图 0005]  
[ 图 0006]  
[ 图 0007]