WO2018112855A1

WO2018112855A1 - Virtualisation method and device, electronic device, and computer program product

Info

Publication number: WO2018112855A1
Application number: PCT/CN2016/111590
Authority: WO
Inventors: 温燕飞
Original assignee: 深圳前海达闼云端智能科技有限公司
Priority date: 2016-12-22
Filing date: 2016-12-22
Publication date: 2018-06-28
Also published as: CN106796530B; CN106796530A

Abstract

Provided are a virtualisation method and device, an electronic device and a computer program product, wherein same are applied to a multi-core processor, the method comprising: binding a front-end thread and a back-end thread to the same physical central processing unit (CPU) (S303, S401), wherein the front-end thread is used for determining, according to an application interface invoking instruction received at a first operating system, a processing instruction corresponding to the application interface invoking instruction (S302), and sending the processing instruction to a corresponding back-end thread at a second operating system (S305); and the back-end thread is used for receiving and executing the processing instruction at the second operation system, and taking a processing result as a response to the application interface invoking instruction or returning same to the front-end thread (S402, S403). Using this method can shorten the time used for system switching and decrease the response time for the application interface invoking instruction, thereby improving the user experience.

Description

Virtualization method, device, and electronic device and computer program product

Technical field

The present application relates to computer technology, and in particular, to a virtualization method, apparatus, and electronic device, computer program product.

Background technique

A virtualization architecture based on Qemu/KVM (Kernel-based Virtual Machine) technology is shown in FIG.

As shown in Figure 1, the virtualization architecture based on Qemu/KVM technology consists of a primary Host operating system and several virtual guest guest operating systems. The Host operating system includes multiple Host user space programs and the Host Linux kernel. Each guest guest operating system includes user space, Guest Linux kernel, and analog processor Qemu. These operating systems run on the same set of hardware processor chips, sharing processor and peripheral resources. The ARM processor supporting the virtualization architecture includes at least EL2, EL1, and EL0 modes, and the virtual machine manager Hypervisor program is run in EL2 mode; the Linux kernel program is run in EL1 mode, that is, the Linux kernel program; and the user space is run in the EL0 mode. program. The Hypervisor layer manages hardware resources such as CPU, memory, timers, and interrupts, and can use different CPUs, memory, timers, and interrupted virtualization resources to load different operating systems into physical processors for runtime. Functionality.

KVM/Hypervisor spans the Host Linux kernel and Hypervisor. It provides a driver node for Qemu, which allows Qemu to create virtual CPUs through KVM nodes and manage virtualized resources. On the other hand, KVM/Hypervisor can also host Host Linux systems. Switch out on the physical CPU, then load the Guest Linux system to run on the physical processor, and handle subsequent transactions that the Guest Linux system exits abnormally.

Qemu runs as an application for Host Linux and provides virtual operation for Guest Linux. The hardware device resources, through the KVM node of the KVM/Hypervisor module, create a virtual CPU, allocate physical hardware resources, and load an unmodified Guest Linux onto the physical hardware processing to run.

To implement the above virtualization architecture on a terminal device such as a mobile phone or a tablet, it is necessary to solve the virtualization of all hardware devices, and the virtual operating system can also use real hardware devices.

In the prior art virtualization solution, the front-end thread in the guest operating system usually calls a corresponding API (Application Program Interface) to generate a corresponding processing instruction when receiving a user operation; and then the processing is performed; The instruction is passed to a back-end thread corresponding to the front-end thread in the backend server Backend Server running in the Host operating system, and the back-end thread drives the corresponding hardware device or module to perform the corresponding operation, and then executes The result is a response to the application interface call instruction.

With the virtualization solution in the prior art, the response process to the API call instruction is relatively long, so that the response to the user operation takes a long time and affects the user experience.

Summary of the invention

The embodiment of the present application provides a virtualization method, device, and electronic device and computer program product, which are mainly used to shorten a response process to an API call instruction in a virtualization system.

According to a first aspect of the embodiments of the present application, a virtualization method is provided, which is applied to a multi-core processor, including: binding a front-end thread and a back-end thread to a same physical central processing unit CPU; wherein the front-end thread is used Determining, according to the application interface call instruction received at the first operating system, a processing instruction corresponding to the application interface calling instruction, and sending the processing instruction to a corresponding backend thread at the second operating system; the backend thread, And being used to receive and execute the processing instruction at the second operating system, and return the processing result as a response of the application interface calling instruction or return to the front-end thread.

According to a second aspect of the embodiments of the present application, a virtualization apparatus is provided for a multi-core processor, including: a binding module, configured to bind a front-end thread and a back-end thread to the same physical center a processor CPU, wherein the front-end thread is configured to determine, according to an application interface call instruction received at the first operating system, a processing instruction corresponding to the application interface call instruction, and send the processing instruction to the second operating system Corresponding backend thread; the backend thread is configured to receive and execute the processing instruction at the second operating system, and return the processing result as a response of the application interface calling instruction or to the front end thread.

According to a third aspect of embodiments of the present application, there is provided an electronic device comprising: a display, a memory, one or more processors; and one or more modules, the one or more modules being stored The memory is configured and executed by the one or more processors, the one or more modules comprising instructions for performing the various steps in the virtual method of the first aspect of the embodiments of the present application.

According to a fourth aspect of the embodiments of the present application, there is provided a computer program product for encoding an instruction for performing a process, the process comprising the virtual method of the first aspect of the embodiment of the present application .

The virtualization method, the device, and the electronic device and the computer program product according to the embodiment of the present application bind the front-end thread and the corresponding back-end thread to the same physical CPU, so that during the virtualization process, the guest operating system and the Host Switching between operating systems and switching between front-end threads and back-end threads can be performed on the same physical CPU, thereby shortening the switching time, reducing the response time to the application interface call instructions, and improving the user experience.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the present application, and are intended to be a part of this application. In the drawing:

A schematic diagram of a virtualization architecture based on Qemu/KVM technology is shown in FIG. 1;

FIG. 2 illustrates a system architecture for implementing a virtualization method in an embodiment of the present application;

FIG. 3 is a flowchart of a virtualization method according to Embodiment 1 of the present application;

FIG. 4 is a flowchart of a virtualization method according to Embodiment 2 of the present application;

FIG. 5 is a flowchart of a virtualization method according to Embodiment 3 of the present application;

FIG. 6 is a schematic structural diagram of a virtualization device according to Embodiment 4 of the present application;

FIG. 7 is a schematic structural diagram of an electronic device according to Embodiment 5 of the present application.

detailed description

In the process of implementing the present application, the inventor has found that in the prior art virtualization solution, when a certain thread is created in a multi-core processor, the Linux kernel schedules a virtual CPU running by the thread according to a preset policy, for example, According to the load balancing principle, scheduling according to the polling principle; therefore, which virtual CPU is running on a certain thread is uncertain; meanwhile, when Qemu creates a virtual CPU, the Linux kernel also schedules the virtual CPU according to a preset policy. The running physical CPU, for example, according to the load balancing principle or scheduling according to the polling principle, etc., therefore, the correspondence between the virtual CPU and the physical CPU is also uncertain. Therefore, it is unclear which physical CPU the thread in the system is running on.

The inventor believes that the scheduling policy of the thread and the virtual CPU may cause the front-end thread running in the guest operating system and the back-end thread running in the host operating system corresponding to the front-end thread to be usually in the virtualization scheme in the prior art. Will run on different physical CPUs, so that when the virtual machine is switched between the front-end thread and the back-end thread, it is also different when switching between the guest operating system and the host operating system. Switching between physical CPUs results in a longer response time to the application interface call instructions, so that the corresponding time for some user operations will be longer, affecting the user experience.

In the embodiment of the present application, a virtualization method, apparatus, system, electronic device, and computer program product are provided, and a front-end thread and a corresponding back-end thread are bound to the same physical CPU, thereby making the virtualization process Switching between the guest operating system and the host operating system, and switching between the front-end thread and the back-end thread can be performed on the same physical CPU, thereby shortening the switching time, reducing the response time to the application interface call instruction, and improving the user experience. .

The solution in the embodiment of the present application can be applied to various scenarios, for example, based on Virtualized architecture of Qemu/KVM technology, multi-core intelligent terminal with multiple operating systems, Android simulator, etc.

The solution in the embodiment of the present application can be implemented in various computer languages, for example, an object-oriented programming language Java or the like.

The exemplary embodiments of the present application are further described in detail below with reference to the accompanying drawings. Not all embodiments are exhaustive. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

Embodiment 1

FIG. 2 illustrates a system architecture for implementing a virtualization method in an embodiment of the present application.

As shown in FIG. 2, a virtualization system according to an embodiment of the present application is applied to an electronic device including a plurality of

physical CPUs

201a, 201b, 201c, and 201d, and in the electronic device, a plurality of virtual CPUs 202a, 202b are created, 202c, and 202d; and a first operating system 203 and a second operating system 204 are created based on the Qemu/KVM technology.

Specifically, the first operating system may be a guest operating system; the second operating system may be a Host operating system. It should be understood that, in a specific implementation, the first operating system may also be a Host operating system, and the second operating system may also be a Guest operating system, which is not limited in this application.

For the purpose of example, only the case of a quad core processor, four virtual CPUs respectively corresponding to a quad core processor is shown in FIG. However, it should be understood that, in the specific implementation, it may be any other plural physical CPUs such as 2, 3, 5, 8, etc., and the number of virtual CPUs may also be any other plural such as 5, 6, 8, 10, and the like. number. When the number of virtual CPUs is set, the number of physical CPUs can be 1:1 or 2:1. Generally, the number of virtual CPUs can be set to be greater than or equal to the number of physical CPUs. .

For the purposes of example, only one Guest operating system, one Host operating system is shown in FIG. However, it should be understood that, in the specific implementation, it may also be one or more Guest operating systems. The system may be one or more Host operating systems; that is, the Guest operating system and the Host operating system may be any number, which is not limited in this application.

Next, the physical CPU is four, and the number of the virtual CPU and the physical CPU to be created is 1:1. The first operating system is the guest operating system, and the second operating system is the host operating system. The detailed description is described in detail.

Specifically, the guest operating system 203 may include a user space 2031, a Guest Linux Kernel 2032, and a Qemu 2033; in the user space of the Guest operating system, an interface of multiple virtual hardware devices or modules may be provided, specifically, the multiple The interface may include a graphics program interface, a multimedia program interface, a codec interface, and the like; more specifically, for example, the graphics program interface may be an OpenGL (Open Graphics Library) API interface, a Direct 3D, a Quick Draw 3D, or the like. The program interface, the multimedia/video program interface may be an OpenMAX (Open Media Acceleration) interface, etc., which is not limited in this application.

Specifically, the host operating system 204 may include a user space 2041 and a Host Linux Kernel 2042; in the user space of the Host operating system, a backend server Backend Server corresponding to each interface in the Guest operating system may be provided. For example, when the graphics program interface in the Guest operating system is the OpenGL API, the backend server can be an OpenGL Backend Server; the backend server can operate the GPU device through the GPU driver in the Host Linux Kernel; the multimedia/video in the Guest operating system When the program interface is OpenMAX API, the back-end server can be OpenMAX Backend Server; the back-end server can operate the corresponding multimedia/video device through the multimedia/video driver in the Host Linux Kernel.

Next, a virtualization method according to an embodiment of the present application will be described in conjunction with the system architecture shown in FIG. 2.

FIG. 3 shows a flow chart of a virtualization method according to Embodiment 1 of the present application. In the first embodiment of the present application, the steps of the virtualization method using the guest operating system as the execution subject are described. As shown in FIG. 3, a virtualization method of a GPU according to an embodiment of the present application includes the following steps:

S301. When creating a virtual CPU, establish each virtual CPU and each physical CPU at Qemu. Correspondence.

In a specific implementation, when a virtual CPU is created by Qemu, each thread that maintains each virtual CPU is bound to a corresponding physical CPU. For example, the first virtual CPU created is bound to the physical CPU 201a, the second virtual CPU created is bound to the physical CPU 201b, and the third virtual CPU created is bound to the physical CPU 201c, the fourth The virtual CPU is bound to the physical CPU 201d and the like. Specifically, the specific implementation of binding the virtual CPU to a certain physical CPU may employ the common technical means of those skilled in the art, which is not described in this application.

S302. Receive an application interface call instruction executed at the first operating system, invoke a corresponding front-end thread according to a user operation, and determine a processing instruction.

In a specific implementation, the user may perform a user operation on a thread in the guest operating system. For example, the user may perform a new window, a new page, etc., playing multimedia/video, etc. in a thread such as WeChat or QQ. operating.

In a specific implementation, when receiving a user operation, the thread generates an API call instruction according to the user operation to invoke the corresponding front-end thread. For example, when the user performs an operation of opening a new window, playing a new page, etc., The corresponding graphic processing interface is called, and when the user performs operations such as playing multimedia/video, the corresponding multimedia/video interface can be called.

Specifically, when the corresponding front-end thread is invoked, the processing instruction may be further determined according to the specific operation content of the user; specifically, the processing instruction may be a new window, a page; an instruction for encoding a video, specifically, the processing The instructions may include one or more of the following codes: processing functions, parameters, synchronization information, content data, etc., which are not limited in this application.

S303. Bind the front-end thread to a virtual CPU.

In a specific implementation, the front-end thread can be bound to the virtual CPU running by the thread that invokes the front-end thread. For example, if the thread that calls the front-end thread is WeChat, the front-end thread can be bound to the virtual CPU that WeChat runs.

Specifically, when the front-end thread is started, that is, when the guest operating system initialization API is called, the identifier of the virtual CPU running by the thread that invokes the API may be obtained. specifically, The identifier of the virtual CPU may be the number of the virtual CPU. And bind the front-end thread, ie, the API, to the corresponding virtual CPU. Specifically, the number of the virtual CPU of the thread that invokes the API may be obtained by using a common technical means of a person skilled in the art. For example, the number of the virtual CPU running by the thread may be detected by the thread that invokes the API, which is not described herein. .

So far, because the virtual CPU has a fixed correspondence with the physical CPU, a front-end thread can be bound to a specified physical CPU through S301-S303.

S304. Send the identifier of the virtual CPU to the second operating system.

In a specific implementation, the identifier of the virtual CPU may be sent to the second operating system separately, or the identifier of the virtual CPU may be carried in other messages and sent to the second operating system.

Specifically, when the front-end thread is called, the host operating system is usually triggered to create a back-end thread corresponding to the front-end thread. In order to bind the back-end thread and the front-end thread to the same physical CPU, the channel initialization information between the front-end thread and the back-end thread may carry the identifier of the virtual CPU and send the channel initialization information to the host operating system. So that the host operating system can create a backend thread corresponding to the front end thread in the background server of the corresponding interface, and can further bind the back end thread to the virtual CPU.

So far, through S301-S304, a front-end thread and its corresponding back-end thread can be bound to the same specified physical CPU.

It should be understood that if a front-end thread corresponding to the application interface call instruction has been established in the first operating system before S302, and the front-end thread has been bound to the corresponding virtual CPU, when the front-end thread is called again, Steps S303 and S304 may not be repeatedly performed.

S305. Send the processing instruction to the backend thread, so that the backend thread executes the processing instruction, and obtains the processing result.

In a specific implementation, the sending of the processing instruction may adopt a plurality of conventional sending manners by those skilled in the art, which is not described herein.

In a specific implementation, the switching from the front-end thread to the back-end thread, and the switching between the first operating system and the second operating system are all commonly used by those skilled in the art. Do not repeat them.

In a specific implementation, the backend thread drives the corresponding hardware device/module to execute the corresponding processing instruction and obtain the processing result.

It should be understood that steps S304 and S305 do not have a strict timing relationship. S304 may be executed first, then S305 may be performed, S305 may be performed first, and then S304 may be performed. S304 and S305 may also be executed synchronously.

In a specific implementation, the backend thread may directly feed back the processing result to the user as a response of the application interface call instruction, or return the processing result to the front end thread, and the front end thread responds to the user operation.

At this point, the remote operation of the hardware device/module by the user program in the guest operating system is realized; that is, the virtualization scheme in which the front-end thread and the back-end thread run on the same physical CPU is realized.

The virtualization method in the embodiment of the present application binds the front-end thread and the corresponding back-end thread to the same physical CPU, so that the switching between the Guest operating system and the Host operating system and the front-end thread in the virtualization process are performed. The switching with the back-end thread can be performed on the same physical CPU, thereby shortening the switching time, reducing the response time to the application interface call instruction, and improving the user experience.

Embodiment 2

FIG. 4 shows a flow chart of a virtualization method according to Embodiment 2 of the present application. In the second embodiment of the present application, the steps of the virtualization method using the Host operating system as the execution subject are described. For the implementation of the system architecture in the embodiment of the present application, refer to the system architecture shown in FIG. 2 in the first embodiment, and details are not described herein again.

As shown in FIG. 4, the virtualization method according to an embodiment of the present application includes the following steps:

S401. The second operating system determines a virtual CPU bound to the front-end thread, and binds the back-end thread to the virtual CPU, where the virtual CPU has a corresponding relationship with the physical CPU.

In the specific implementation, the establishment of the correspondence between the virtual CPU and the physical CPU may refer to the present application. The implementation of S301 in Embodiment 1 will not be repeated here.

In a specific implementation, when the host operating system creates a corresponding backend thread in the background server, the virtual CPU bound to the previous thread is determined, and the backend thread is bound to the virtual CPU. Specifically, if the guest operating system sends the identifier of the virtual CPU bound to the front-end thread, for example, the number, carried in the channel initialization information of the front-end thread to the host operating system, the host operating system may extract corresponding information from the channel initialization information. The number of the virtual CPU, and after creating the backend thread, bind the backend thread to the virtual CPU.

At this point, the front-end thread and the back-end thread have been bound to the same physical CPU.

S402. The backend thread at the second operating system acquires a processing instruction from the front end thread at the first operating system.

In the specific implementation, the switching from the front-end thread to the back-end thread, and the switching between the first operating system and the second operating system all adopt the common technical means of those skilled in the art, which is not described in this application.

In a specific implementation, specifically, the processing instruction may be a new window, a page, and an instruction for encoding a video. Specifically, the processing instruction may include one or more of the following codes: a processing function, a parameter, and synchronization information. , content data, etc., this application does not limit this.

In the specific implementation, the processing instruction can be obtained by a plurality of conventional acquisition methods, which are not described herein.

S403, executing a processing instruction at the backend thread, and obtaining a processing result; the processing result is a response of the processing operation, wherein the processing operation corresponds to the processing instruction.

In a specific implementation, the backend thread in the backend server drives the corresponding hardware device/module to execute the processing instruction and obtain a processing result in response to the processing operation.

It should be understood that if a backend thread corresponding to the front end thread has been established in the second operating system before S402, and the backend thread has been bound to the corresponding virtual CPU, when the backend thread is called again, Step S401 may not be repeatedly performed, but S402 and S403 may be directly executed.

So far, the remote operation of the hardware device/module is implemented in the Host operating system in conjunction with the user program in the Guest operating system; that is, the virtualization scheme in which the front-end thread and the back-end thread run on the same physical CPU is realized.

Embodiment 3

FIG. 5 is a flow chart showing a virtualization method according to Embodiment 3 of the present application. In the third embodiment of the present application, the steps of the guest operating system and the host operating system to implement the virtualization method are described. For the implementation of the system architecture in the embodiment of the present application, refer to the system architecture shown in FIG. 2 in the first embodiment, and details are not described herein again.

In the embodiment of the present application, the initiator of the API function remote call is the Guest operating system, and the function execution party is the Host operating system, and the downlink synchronization process from the Guest operating system to the Host operating system goes through the Guest Linux kernel and Qemu to the Backend Server; The uplink synchronization process from the Host operating system to the Guest operating system is initiated from the Backend Server and reaches the emulator API through the Qemu and Guest Linux kernels.

Next, the implementation process of the virtual method based on the above application scenario will be described in detail.

As shown in FIG. 5, the virtualization method according to Embodiment 3 of the present application includes the following steps:

S501: When creating a virtual CPU, Qemu binds each thread of the maintenance virtual CPU to a fixed physical CPU.

For example, if virtualization is implemented on a 4-core processor chip and 4 virtual CPUs are created, the thread that Qemu creates virtual CPU0 can be bound to physical CPU0, and so on, and the thread that creates virtual CPU 3 is bound to the physics. On CPU3.

S502. The Guest operating system receives an application interface call instruction.

In a specific implementation, the guest operating system may receive user operations through an operating system or through a thread in the operating system. For example, the user can perform a user operation on a thread in the guest operating system, for example, in a thread such as WeChat or QQ, performing an operation of opening a new window, playing a new page, playing multimedia/video, and the like. These threads usually generate API call instructions after receiving a user action.

S503: When the guest operating system creates the front-end thread, it detects the virtual CPU number of the thread that invokes the front-end thread.

In a specific implementation, the thread that invokes the front-end thread, that is, the thread that initiates the remote call of the API, may be the thread that receives the user operation. For example, it may be a user program such as WeChat or QQ.

In the specific implementation, the number of the virtual CPU of the thread that invokes the API may be detected by a common technical means of a person skilled in the art, which is not described herein.

S504: The guest operating system binds the front-end thread to the virtual CPU, and transmits the virtual CPU number to the corresponding Backend Server in the host operating system.

In the specific implementation, the virtual CPU number can be sent to the Backend Server separately, or the virtual CPU number can be carried in other messages, for example, in the channel initialization message, to the Backend Server.

It should be understood that the Backend Server may be a background server corresponding to the front-end thread. For example, if the front-end thread is a graphics program interface, the corresponding Backend Server is a graphics program background server, and if the front-end thread is a multimedia/video interface, the corresponding Backend Server is a multimedia/video backend server.

S505: When the backend thread is created, the backend server binds the backend thread to the virtual CPU specified by the guest operating system.

In the specific implementation, if the guest operating system sends the virtual CPU number to the Backend Server separately, the Backend Server obtains the virtual CPU number when creating the subsequent thread; if the guest operating system carries the virtual CPU number in the channel initialization message, To Backend Server, the Backend Server extracts the CPU number from the channel initialization message and binds it.

It should be understood that, in order to improve efficiency, after the current end thread and the corresponding back end thread are bound to the same physical CPU, in the next virtualization process, the remote call of the API can be directly performed without repeating the binding again; That is, the steps of binding the front-end thread and the back-end thread to the same physical CPU, that is, S503-S505, may no longer be performed.

S506, the front-end thread sends the processing instruction to the back-end thread.

For the implementation of this step, refer to S305 in the first embodiment of the present application and S402 in the second embodiment of the present application, and the repeated description is not repeated.

S507, executing a processing instruction at the backend thread, and obtaining a processing result; using the processing result as a response of the application interface calling instruction, or returning to the front end thread.

For the implementation of this step, reference may be made to the implementation of step S403 in the second embodiment of the present application, and the repeated description is not repeated.

So far, in the multi-core processor, the remote calling of the hardware program/module by the user program between the multiple operating systems is realized; that is, the virtualization scheme in which the front-end thread and the back-end thread run on the same physical CPU is realized.

Based on the same inventive concept, the embodiment of the present application further provides a virtualization device, which is applied to a multi-core processor. The principle of solving the problem is similar to the virtualization method provided by the first embodiment of the present application. For the implementation of the method, refer to the implementation of the method, and the repetition will not be repeated.

Embodiment 4

FIG. 6 is a schematic structural diagram of a virtualization device according to Embodiment 4 of the present application.

As shown in FIG. 6, the virtualization device 600 according to Embodiment 4 of the present application includes: a binding module 601, configured to bind a front-end thread and a back-end thread to a same physical central processing unit CPU; wherein the front-end thread is used for Determining, according to the application interface call instruction received at the first operating system, a processing instruction corresponding to the application interface call instruction, and sending the processing instruction to a corresponding backend thread at the second operating system; At the second operating system, the processing instruction is received and executed, and the processing result is returned as a response to the application interface calling instruction or returned to the front-end thread.

Specifically, the binding module includes: a corresponding relationship establishing submodule, configured to establish a correspondence between each virtual CPU and each physical CPU at the analog processor Qemu; the first binding submodule is used in the first operating system Binding the front-end thread to a virtual CPU; sending the identifier of the bound virtual CPU to the second operating system; and the second binding sub-module, in the second operating system, from the first The operating system receives the identifier of the virtual CPU and binds the backend thread to the virtual CPU.

Specifically, the corresponding relationship establishes a sub-module, which is specifically used to bind each thread that maintains each virtual CPU to a corresponding physical CPU when creating a virtual CPU in Qemu.

Specifically, the first binding sub-module is specifically configured to: obtain an identifier of a virtual CPU running by a thread that invokes the front-end thread, where the identifier is used to identify the virtual CPU; and bind the front-end thread to the virtual CPU identifier. Virtual CPU; sends the identity of the bound virtual CPU to the second operating system.

Specifically, the first binding sub-module is specifically configured to: when the front-end thread starts, acquire an identifier of a virtual CPU running by a thread that invokes the front-end thread; and initialize a channel between the front-end thread and the back-end thread The information carries the identifier of the virtual CPU, and sends the channel initialization information to the second operating system. The second binding sub-module is specifically configured to receive the front-end thread and the back end from the first operating system. The channel initialization information between the threads, wherein the channel initialization information carries the identifier of the virtual CPU; the identifier of the virtual CPU is extracted from the channel initialization information, and the backend thread is bound to the virtual CPU.

The virtualization device in the embodiment of the present application binds the front-end thread and the corresponding back-end thread to the same physical CPU, so that the switching between the guest operating system and the host operating system and the front-end thread in the virtualization process are performed. The switching with the back-end thread can be performed on the same physical CPU, thereby shortening the switching time, reducing the response time to the application interface call instruction, and improving the user experience.

Embodiment 5

Based on the same inventive concept, an electronic device 700 as shown in FIG. 7 is also provided in the embodiment of the present application.

As shown in FIG. 7, an electronic device 700 according to Embodiment 5 of the present application includes: a display 701, a memory 702, one or more processors 703; a bus 704; and one or more modules, the one or more modules being stored In the memory, and configured to be executed by the one or more processors, the one or more modules include instructions for performing the steps in any of the methods one to three of the present application.

Based on the same inventive concept, a computer program product is also provided in the embodiment of the present application, and the computer program product encodes an instruction for executing a process, where the process includes the steps in the first embodiment of the present application. Virtual method.

In particular implementations, the computer program product can be used in conjunction with electronic device 700.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment in combination of software and hardware. Moreover, the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the present application. It will be understood that each of the processes and/or blocks in the flowcharts and/or block diagrams, and the flows in the flowcharts and/or block diagrams can be implemented by computer program instructions. And/or a combination of boxes. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

While the preferred embodiment of the present application has been described, it will be apparent that those skilled in the art can make further changes and modifications to the embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and the modifications and

It will be apparent to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit and scope of the application. Thus, it is intended that the present invention cover the modifications and variations of the present invention.

Claims

A virtualization method for a multi-core processor, comprising:

Bind the front-end thread to the back-end thread to the same physical CPU CPU;

The front-end thread is configured to determine, according to an application interface call instruction received at the first operating system, a processing instruction corresponding to the application interface call instruction, and send the processing instruction to a corresponding back end at the second operating system Thread

The backend thread is configured to receive and execute the processing instruction at the second operating system, and return the processing result as a response of the application interface calling instruction or to the front end thread.
The method of claim 1, wherein binding the front-end thread to the back-end thread to the same physical CPU CPU comprises:

Establishing a correspondence between each virtual CPU and each physical CPU at the analog processor Qemu;

At the first operating system, binding the front-end thread to a virtual CPU; and sending the identifier of the bound virtual CPU to the second operating system;

In the second operating system, the identifier of the virtual CPU is received from the first operating system, and the backend thread is bound to the virtual CPU.
The method according to claim 2, wherein the mapping between each virtual CPU and each physical CPU is established at Qemu, and specifically includes:

When creating a virtual CPU in Qemu, each thread that maintains each virtual CPU is bound to a corresponding physical CPU.
The method of claim 2, wherein binding the front end thread to a virtual CPU comprises:

Obtaining an identifier of a virtual CPU running by a thread that invokes the front-end thread, where the identifier is used to identify the virtual CPU;

Binding the front end thread to the virtual CPU corresponding to the virtual CPU identifier.
The method of claim 4, wherein the identifier of the virtual CPU running by the thread that invokes the front-end thread is obtained, which specifically includes:

When the front-end thread is started, acquiring an identifier of a virtual CPU running by a thread that invokes the front-end thread;

And sending the identifier of the bound virtual CPU to the second operating system, specifically: carrying the identifier of the virtual CPU in the channel initialization information between the front-end thread and the back-end thread, and Transmitting channel initialization information to the second operating system;

Receiving the identifier of the virtual CPU from the first operating system, specifically:

Receiving channel initialization information between the front-end thread and the back-end thread from the first operating system, where the channel initialization information carries an identifier of the virtual CPU;

Extracting an identifier of the virtual CPU from the channel initialization information.
A virtualization device for a multi-core processor, comprising:

a binding module for binding a front-end thread and a back-end thread to the same physical CPU;

The front-end thread is configured to determine, according to an application interface call instruction received at the first operating system, a processing instruction corresponding to the application interface call instruction, and send the processing instruction to a corresponding back end at the second operating system Thread

The backend thread is configured to receive and execute the processing instruction at the second operating system, and return the processing result as a response of the application interface calling instruction or to the front end thread.
The device according to claim 6, wherein the binding module comprises:

Corresponding relationship establishing submodule, configured to establish a correspondence between each virtual CPU and each physical CPU at the analog processor Qemu;

a first binding submodule, configured to bind the front end thread to a virtual CPU at the first operating system, and send the identifier of the bound virtual CPU to the second operating system;

a second binding submodule, configured to receive an identifier of the virtual CPU from the first operating system, and bind the backend thread to the virtual CPU in a second operating system.
The device according to claim 7, wherein the corresponding relationship establishes a sub-module, specifically for:

When creating a virtual CPU in Qemu, each thread that maintains each virtual CPU is bound to a corresponding physical CPU.
The device according to claim 7, wherein the first binding submodule is specifically configured to:

Obtaining an identifier of a virtual CPU running by a thread that invokes the front-end thread, where the identifier is used to identify the virtual CPU;

Binding the front end thread to a virtual CPU corresponding to the virtual CPU identifier;

Send the ID of the bound virtual CPU to the second operating system.
The device according to claim 9, wherein the first binding submodule is specifically configured to:

The identifier of the virtual CPU running by the thread that invokes the front-end thread is acquired when the front-end thread is started; and the identifier of the virtual CPU is carried in the channel initialization information between the front-end thread and the back-end thread. And sending the channel initialization information to the second operating system;

The second binding submodule is specifically used to:

Receiving channel initialization information between the front-end thread and the back-end thread from the first operating system, where the channel initialization information carries an identifier of the virtual CPU;

Extracting an identifier of the virtual CPU from the channel initialization information, and binding the backend thread to the virtual CPU.
An electronic device, comprising: a display, a memory, one or more processors; and one or more modules, the one or more modules being stored in the memory and being Configured to be performed by the one or more processors, the one or more modules comprising instructions for performing the various steps of the method of any of claims 1-5.
A computer program product for encoding instructions for performing a process, the process comprising the method of any of claims 1-5.