Virtual machine running method, device, equipment and storage medium
By running both the virtual machine and the host machine in the first privileged layer of root mode, and using jump instructions to directly jump between the guest kernel and the host kernel, the problem of high performance overhead in the KVM virtualization architecture is solved, achieving more efficient virtualization performance.
Patent Information
- Application Number
- CN202211296781.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-10-21
- Publication Date
- 2026-01-06
- Estimated Expiration
- 2042-10-21
AI Technical Summary
In kernel virtualization architectures based on kernel virtual machines (KVM), the switching between the host kernel and the guest kernel results in significant virtualization performance overhead, especially during mode switching and hardware virtualization translation.
Both the virtual machine and the host machine run in the first privilege level of root mode, while user tasks run in the second privilege level of root mode. Jump instructions are used to directly switch between the guest kernel and the host kernel, avoiding additional mode switching and hardware virtualization mechanisms. Paravirtualization interfaces are used for resource access and interrupt handling.
It reduces virtualization overhead, improves virtualization performance, reduces the overhead of mode switching and hardware virtualization translation, and optimizes virtual resource access and interrupt handling.
Smart Images

Figure CN115437751B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to the technical field of virtualization, and particularly relates to a virtual machine running method and device, equipment and storage medium. BACKGROUND
[0002] In a Kernel-based Virtual Machine (KVM) based virtualization architecture, a processor is divided into a root mode and a non-root mode.
[0003] Specifically, a ring0 layer of the non-root mode is used to run a Guest kernel in the virtual machine, and a ring3 layer of the non-root mode is used to run an online task or an offline task in the virtual machine; a ring0 layer of the root mode is used to run a Host kernel, and a ring3 layer of the non-root mode is used to run a Virtual Machine Manager (VMM).
[0004] Based on the above virtualization architecture, switching between the Host kernel and the Guest kernel relies on switching between the non-root mode and the root mode, which results in a relatively large performance overhead of virtualization. SUMMARY
[0005] Therefore, one or more embodiments of the present disclosure provide a virtual machine running method and device, equipment and storage medium, which can save the performance overhead of virtualization.
[0006] In an aspect, the present disclosure provides a virtual machine running method, wherein the virtual machine and a host run in a root mode, a Guest kernel in the virtual machine and a Host kernel in the host run in a first privilege layer in the root mode, and a user task in the virtual machine runs in a second privilege layer in the root mode; the method comprises: in a running process of the user task, if the Guest kernel accesses a virtual resource virtualized by the Host kernel, jumping from the Guest kernel to the Host kernel based on a jump instruction; and after completing the access to the virtual resource accessed by the Guest kernel through a hardware simulation operation in the Host kernel, jumping from the Host kernel back to the Guest kernel.
[0007] The other aspect of the present disclosure further provides a virtual machine running apparatus, the virtual machine and a host computer run in a root mode, a guest kernel in the virtual machine and a host kernel in the host computer run in a first privilege layer in the root mode, a user task in the virtual machine runs in a second privilege layer in the root mode, the apparatus comprises: a kernel jump unit, configured to, if the guest kernel accesses a virtual resource virtualized by the host kernel during running of the user task, jump from the guest kernel to the host kernel based on a jump instruction; and an access execution unit, configured to, in the host kernel, complete access to the virtual resource accessed by the guest kernel through a hardware simulation operation, and then jump from the host kernel back to the guest kernel.
[0008] The other aspect of the present disclosure further provides a computer device, the computer device comprises a memory and a processor, the memory is configured to store a computer program, the computer program is executed by the processor to realize the virtual machine running method.
[0009] The other aspect of the present disclosure further provides a computer readable storage medium, the computer readable storage medium is configured to store a computer program, the computer program is executed by a processor to realize the virtual machine running method.
[0010] The technical solution provided by one or more embodiments of the present disclosure provides a new virtualization architecture, the virtual machine and the host computer are both run in a root mode, wherein the guest kernel in the virtual machine and the host kernel in the host computer both run in a first privilege layer in the root mode, and the user task in the virtual machine runs in a second privilege layer in the root mode. Since the guest kernel and the host kernel are in the same mode, if the guest kernel accesses a virtual resource during running of the user task, the jump between the guest kernel and the host kernel does not need to perform additional mode switching, thereby saving virtualization overhead. BRIEF DESCRIPTION OF DRAWINGS
[0011] The features and advantages of the present disclosure will be more clearly understood through the following detailed description taken in conjunction with the accompanying drawings, which are shown by way of illustration and not by way of limitation, in which:
[0012] Figure 1 A structure schematic diagram of a virtualization architecture in the prior art is shown;
[0013] Figure 2 A structure schematic diagram of a virtualization architecture in one embodiment of the present disclosure is shown;
[0014] Figure 3 A step schematic diagram of a virtual machine running method in one embodiment of the present disclosure is shown;
[0015] Figure 4 a flowchart illustrating a method for processing a virtual interrupt in an embodiment of the present disclosure is shown;
[0016] Figure 5 a flowchart illustrating a lifecycle of a virtual machine in an embodiment of the present disclosure is shown;
[0017] Figure 6 a functional module diagram of a running device of a virtual machine in an embodiment of the present disclosure is shown;
[0018] Figure 7 a structural diagram of a computer device in an embodiment of the present disclosure is shown. DETAILED DESCRIPTION
[0019] In order to make the purposes, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by a person skilled in the art without creative work fall within the protection scope of the present disclosure.
[0020] In order to prevent the online task and the offline task from interfering with each other, it can be considered to select to run them in independent Kata containers. In a traditional KVM-based virtualization architecture, as shown in Figure 1 , a virtual machine is run in a non-root mode of a processor, wherein the online / offline task is run in a ring3 layer of the non-root mode, and a guest kernel is run in a ring0 layer of the non-root mode; a host is run in a root mode of the processor, wherein a host kernel is run in a ring0 layer of the root mode, and a virtual machine monitor (such as qemu, cloudhypervisor, etc.) is run in a ring3 layer of the root mode.
[0021] Based on the above virtualization architecture, the virtualization overheads include:
[0022] 1) The Kata container runs the online / offline task in the virtual machine, and when the online / offline task needs to access a virtual resource during the running process, the guest kernel needs to trap into the host kernel, and the simulation is completed by the KVM module in the host kernel, which causes the overhead of mode switching between the non-root mode / root mode.
[0023] 2) The mutual switching of the online / offline task needs to switch from one virtual machine to another virtual machine, and the guest kernel also needs to trap into the host kernel to complete the switching, which causes the overhead of mode switching between the non-root mode / root mode.
[0024] 3) Memory access needs two layers of hardware translation, access overhead is large.
[0025] Therefore, based on the traditional KVM-based virtualization architecture, the virtualization overhead is large.
[0026] In view of this, one embodiment of the present disclosure provides a new KVM-based virtualization architecture, which is as shown in Figure 2 .
[0027] The virtual machine and the host machine run in root mode, the guest kernel in the virtual machine and the host kernel in the host machine run in the first privilege layer in the root mode, and the user task in the virtual machine runs in the second privilege layer in the root mode.
[0028] The first privilege layer can be understood as ring0 layer, and the second privilege layer can be understood as ring3 layer. The priority of the first privilege layer is higher than that of the second privilege layer, and the priority of the privilege layer determines whether the privilege layer is allowed to run some privileged instructions.
[0029] The user task includes online task and offline task. The online task and the offline task are divided according to the sensitivity of the task to the delay, wherein the online task refers to the task sensitive to the delay, and the offline task refers to the task insensitive to the delay.
[0030] In one embodiment, as shown in Figure 2 , the virtual machine monitor in the host machine can run in the second privilege layer in the root mode together with the user task in the virtual machine.
[0031] In one embodiment, as shown in Figure 2 , the KVM module is included in the host kernel, and the KVM module is responsible for the operation of the emulated guest kernel.
[0032] Referring to Figure 3 , one embodiment of the present disclosure provides a virtual machine running method, which can be applied to the computer device under the virtualization architecture as shown in Figure 2 , and the method can include the following steps.
[0033] S31: In the running process of the user task, if the guest kernel accesses the virtual resource virtualized by the host kernel, the guest kernel is jumped to the host kernel based on the jump instruction.
[0034] In this embodiment, when the virtual machine accesses the virtual resource through the guest kernel, the guest kernel in the virtual machine is jumped to the host kernel in the host machine through the jump instruction.
[0035] The jump instruction can be understood as a hypercall instruction. The jump instruction can be generated by using a semi-virtualization interface of the guest kernel, which can be an interface originally used for a xen semi-virtualization implementation.
[0036] In one embodiment, the virtualized resource includes a virtual central processing unit (VCPU), and the guest kernel accesses the virtual resource virtualized by the host kernel includes that the guest kernel accesses the virtual central processing unit, and the way in which the guest kernel accesses the virtual central processing unit includes that the guest kernel performs an access operation on a central processing unit privilege register or an execution operation on a privileged instruction.
[0037] Specifically, in response to the access operation of the guest kernel on the central processing unit privilege register or the execution operation on the privileged instruction, a jump instruction is generated based on a semi-virtualization interface of the guest kernel, and based on the jump instruction, the guest kernel jumps to the host kernel to access the central processing unit privilege register or execute the privileged instruction by the host kernel.
[0038] In a conventional KVM-based virtualization architecture, when the guest kernel accesses the central processing unit privilege register or executes the privileged instruction, the host kernel relies on an interception mechanism provided by hardware virtualization to intercept the central processing unit privilege register or privileged instruction operation of the guest kernel in a non-root mode, and trap into the host kernel in a root mode, thereby realizing CPU virtualization. In the virtualization architecture provided by the present disclosure, the guest kernel and the host kernel both run in a root mode, and cannot utilize the hardware virtualization mechanism. To solve this problem, in the above embodiment, the existing semi-virtualization interface of the guest kernel is utilized, and when the guest kernel accesses the central processing unit privilege register or executes the privileged instruction, the above operation is replaced by a jump instruction, and the guest kernel performs a function call by the jump instruction to directly jump to the host kernel, and the host kernel completes the "interception" operation.
[0039] In one embodiment, the virtualized resource includes a virtual memory, and the guest kernel accesses the virtual resource virtualized by the host kernel includes that the guest kernel manages the virtual memory, and the way in which the guest kernel manages the virtual memory includes that the guest kernel performs a modification operation on a guest page table.
[0040] Specifically, in response to the modification operation of the guest kernel on the guest page table, a jump instruction is generated based on a semi-virtualization interface of the guest kernel, and based on the jump instruction, the guest kernel jumps to the host kernel to modify a shadow page table synchronized with the guest page table by the host kernel.
[0041] In a conventional KVM-based virtualization architecture, the host kernel relies on the secondary page table translation mechanism provided by hardware virtualization to implement memory virtualization. For example, in a hardware virtualization-based shadow page table (SPT) mechanism, the guest kernel maintains a guest page table, but the hardware actually uses a shadow page table maintained by the host kernel. The host kernel maps the guest page table as read-only, so when the guest kernel in non-root mode modifies the guest page table, it needs to trap to the host kernel in root mode, and the host kernel synchronizes the guest kernel's modification of the guest page table to the shadow page table. In the virtualization architecture of the present disclosure, both the guest kernel and the host kernel run in root mode and cannot use the secondary page table translation mechanism. To solve this problem, in the above embodiment, the existing semi-virtualization interface of the guest kernel is used to replace the above operation with a jump instruction when the guest kernel operates on the guest page table. The guest kernel performs function calling through the jump instruction and directly jumps to the host kernel, which performs a simulated operation of synchronizing the shadow page table.
[0042] S32: In the host kernel, after completing the access to the virtual resource accessed by the guest kernel through the hardware simulation operation, jump back to the guest kernel from the host kernel.
[0043] In the present embodiment, after jumping to the host kernel, the host kernel performs a simulated access to the virtual resource through the hardware simulation operation, and after completing the access, jumps back to the guest kernel from the host kernel to re-enter the guest kernel for running.
[0044] It can be understood that the virtual resource also includes a virtual device. If the guest kernel accesses the virtual device during the running of the user task, the virtualization of the pass-through device is still completed by relying on the conventional KVM-based virtualization virtual function I / O (VFIO) mechanism, and thus it is not described herein.
[0045] As can be seen from the above, the technical solution provided by one or more embodiments of the present disclosure provides a new virtualization architecture, which runs both the virtual machine and the host machine in root mode. The guest kernel in the virtual machine and the host kernel in the host machine both run in the first privilege layer of the root mode, and the user task in the virtual machine runs in the second privilege layer of the root mode.
[0046] Since the guest kernel and the host kernel are in the same mode, if the guest kernel accesses the virtual resource during the running of the user task, the jump between the guest kernel and the host kernel does not need to perform additional mode switching, thereby saving the virtualization overhead.
[0047] In some embodiments, in the case where the virtual resource is a virtual device, the virtualization of the virtual device is completed by relying on the conventional KVM-based virtualization virtual function I / O (VFIO) mechanism.Figure 2 The implementation of virtual interrupts has changed under the new virtualization architecture shown.
[0048] Specifically, please refer to Figure 4 .exist Figure 4 The process includes the following steps:
[0049] S41: Obtain the currently generated virtual interrupt through the host kernel, and determine the type of virtual interrupt based on the interrupt number of the virtual interrupt.
[0050] In this implementation, the virtual interrupt first enters the host kernel. Different types of virtual interrupts correspond to different interrupt number ranges. Therefore, the host kernel can determine the type of virtual interrupt by the interrupt number of the current virtual interrupt.
[0051] S42: If the virtual interrupt type represents a pass-through interrupt, jump to the guest kernel to handle the virtual interrupt through the guest kernel.
[0052] In traditional KVM-based virtualization architectures, the host kernel relies on the pass-through interrupt mechanism provided by hardware virtualization to achieve virtual interrupt pass-through. However, in the virtualization architecture provided in this disclosure, both the guest kernel and the host kernel run in root mode, making it impossible to utilize the hardware virtualization mechanism. To address this issue, in this embodiment, if the current virtual interrupt can be determined to be a pass-through interrupt based on the interrupt number, the process jumps directly from the host kernel to the guest kernel, where the virtual interrupt is executed.
[0053] S43: If the virtual interrupt type represents a non-pass-through interrupt, the host kernel injects the virtual interrupt into the guest kernel.
[0054] Specifically, the virtual interrupt injection method includes: identifying the interrupt number of the virtual interrupt and jumping to the interrupt handler of the guest kernel corresponding to the interrupt number to execute the virtual interrupt; after the interrupt handler is executed, returning to the host kernel.
[0055] For example, the host kernel checks if there are any pending virtual interrupts. If so, it jumps to the interrupt handler in the guest kernel corresponding to the interrupt number of the virtual interrupt for processing. After the interrupt handler has finished executing, it returns to the host kernel.
[0056] In traditional KVM-based virtualization architectures, the host kernel relies on the pass-through injection mechanism provided by hardware virtualization to inject virtual interrupts. However, in the virtualization architecture provided in this disclosure, both the guest kernel and the host kernel run in root mode and cannot utilize the hardware virtualization mechanism. To address this issue, in the above implementation, if the interrupt number indicates that the current virtual interrupt is a non-pass-through interrupt, the host kernel will still process it and inject the virtual interrupt into the guest kernel.
[0057] As can be seen from the above, the technical solutions provided by one or more embodiments of this disclosure change the implementation method of virtual interruption so as to still realize the function of virtual interruption under the new virtualization architecture.
[0058] In some implementations, such as Figure 2 The new virtualization architecture shown changes the way virtual machine switching is implemented.
[0059] Specifically, in response to a switching instruction initiated by a virtual machine to switch to another virtual machine, a jump instruction is generated based on the semi-virtualization interface of the guest kernel; based on the jump instruction, a jump is made from the guest kernel to the host kernel, so as to switch to another virtual machine through the host kernel.
[0060] Switching between virtual machines can also be understood as switching between user tasks, switching between online and offline tasks, and so on.
[0061] In traditional KVM-based virtualization architectures, when switching virtual machines, the guest kernel in non-root mode needs to jump into the host kernel in root mode to achieve the virtual machine switchover. However, in the virtualization architecture provided in this disclosure, both the guest kernel and the host kernel run in root mode. Therefore, in the above implementation, utilizing the guest kernel's existing paravirtualization interface, when the guest kernel executes a switching instruction, the above operation is replaced with a jump instruction. The guest kernel then uses the jump instruction to make a function call, directly jumping to the host kernel.
[0062] As can be seen from the above, the technical solutions provided by one or more embodiments of this disclosure, since the guest kernel and the host kernel are in the same mode, do not require additional mode switching when the virtual machine initiates a switch, thereby saving virtualization overhead.
[0063] In some implementations, such as Figure 2 The new virtualization architecture shown changes the way virtual machines exit.
[0064] Specifically, in response to the exit command initiated by the virtual machine, a jump instruction is generated; based on the jump instruction, the kernel jumps from the guest kernel to the host kernel, so that the virtual machine's data structures can be cleared by the host kernel, thereby completing the exit of the virtual machine.
[0065] In traditional KVM-based virtualization architectures, when a virtual machine exits, the guest kernel in non-root mode needs to jump into the host kernel in root mode to exit the virtual machine. However, in the virtualization architecture provided in this disclosure, both the guest kernel and the host kernel run in root mode. Therefore, in the above implementation, when the guest kernel executes an exit instruction, the operation is replaced by a jump instruction. The guest kernel uses the jump instruction to make a function call, directly jumping to the host kernel, which then clears the virtual machine's data structures, thus completing the virtual machine's exit.
[0066] As can be seen from the above, the technical solutions provided by one or more embodiments of this disclosure, since the guest kernel and the host kernel are in the same mode, do not require additional mode switching when the virtual machine exits, thereby saving virtualization overhead.
[0067] In some implementations, considering that the virtual machine runs in root mode along with the host machine and that the virtual machine and the host machine run in the same address space, address space relocation is required to prevent address conflicts.
[0068] In one implementation, the address space includes user space and kernel space; wherein user tasks occupy user space, and the guest kernel and host kernel occupy kernel space. Furthermore, the virtual machine monitor in the host machine can occupy user space along with user tasks.
[0069] In one implementation, the guest kernel is mapped in kernel space, and the host kernel is mapped in an unused kernel cavity in kernel space; or, the host kernel is mapped in kernel space, and the guest kernel is mapped in an unused kernel cavity in kernel space.
[0070] Below, in conjunction with the above explanation, two possible layout methods for address space relocation are shown.
[0071] Layout 1:
[0072] 1) First, the 64-bit address space is divided into user space and kernel space.
[0073] 2) Keep the address space layout of the host kernel in the kernel space unchanged, consistent with the traditional KVM-based virtualization implementation.
[0074] 3) Relocate the guest kernel's address space to a kernel cavity that is not used by the host kernel. In the current Linux kernel implementation, the kernel cavity reaches 14TB, which is sufficient to accommodate the guest kernel.
[0075] 4) User tasks occupy the upper half of the user space, while the virtual machine monitor occupies the lower half of the user space.
[0076] Layout 2:
[0077] 1) First, the 64-bit address space is divided into user space and kernel space.
[0078] 2) Keep the guest kernel's address space layout in the kernel space unchanged, consistent with traditional KVM-based virtualization implementations.
[0079] 3) Relocate the host kernel's address space to unused kernel holes in the guest kernel. In the current Linux kernel implementation, the kernel holes reach 14TB, which is sufficient to accommodate the host kernel.
[0080] 4) User tasks occupy the upper half of the user space, while the virtual machine monitor occupies the lower half of the user space.
[0081] In one implementation, after address space relocation is completed, the host kernel maps the guest kernel's executable file into the corresponding address space, thereby starting the virtual machine.
[0082] Specifically, in response to the host kernel mapping the guest kernel's executable file into the address space where the guest kernel resides, a jump instruction is generated; based on the jump instruction, the system jumps to the guest kernel's entry point in the address space, starts the guest kernel from the entry point, and completes the virtual machine startup.
[0083] As can be seen from the above, the technical solutions provided by one or more embodiments of this disclosure can avoid address conflicts when the virtual machine and the host machine are running in the same mode and the same address space by relocating the address space.
[0084] Please see Figure 5 In such Figure 2 The lifecycle of a virtual machine under the new virtualization architecture is shown in the figure.
[0085] 1) Virtual machine initialization and startup.
[0086] Similar to traditional KVM-based virtualization, the KVM module in the host kernel initializes the virtual CPU, virtualized memory, and virtual devices for the virtual machine. Then, the KVM module in the host kernel maps the guest kernel's executable file to the corresponding location in the current address space of root mode (refer to the implementation of address space relocation), and then jumps directly to the guest kernel's entry point via a jump instruction to start the guest kernel's execution.
[0087] 2) Run in a virtual machine.
[0088] After the guest kernel completes its initialization, it starts running user tasks. The virtual machine's operation includes two special cycles:
[0089] 2.1 Virtual machine access to virtual resources: When a virtual machine accesses virtual resources during operation, it needs to jump to the KVM module of the host kernel to complete the simulation operation.
[0090] In the technical solution provided in this disclosure, when accessing the virtual central processing unit and virtual memory, the jump between the guest kernel and the host kernel does not require additional mode switching, thereby saving virtualization overhead.
[0091] 2.2 Virtual Machine Switching: When a virtual machine needs to switch to another virtual machine during operation (user task switching), it is also necessary to jump to the host kernel to complete the switching operation. Moreover, the jump between the guest kernel and the host kernel does not require additional mode switching, thus saving virtualization overhead.
[0092] 3) Exit the virtual machine.
[0093] When the virtual machine needs to exit, it calls the interface provided by the host kernel, jumps to the host kernel's KVM module, and completes the virtual machine exit and the destruction of related data structures. The process in the KVM module is basically the same as that of traditional KVM-based virtualization.
[0094] Please see Figure 6 This disclosure also provides a virtual machine running apparatus in one embodiment, wherein the virtual machine and the host machine run in root mode, the guest kernel in the virtual machine and the host kernel in the host machine run in a first privilege level in the root mode, and the user tasks in the virtual machine run in a second privilege level in the root mode. The apparatus includes:
[0095] The kernel jump unit 100 is used to, during the execution of the user task, if the guest kernel accesses virtual resources virtualized by the host kernel, jump from the guest kernel to the host kernel based on a jump instruction;
[0096] The access execution unit 200 is used to, in the host kernel, complete the access to the virtual resources accessed by the guest kernel through hardware simulation operations, and then jump back from the host kernel to the guest kernel.
[0097] In one implementation, the guest kernel accessing virtual resources obtained by virtualization of the host kernel includes: the guest kernel accessing a virtual central processing unit (CPU), and the guest kernel accessing the virtual CPU includes: the guest kernel accessing privilege registers of the CPU or executing privileged instructions.
[0098] The kernel jump unit 100 is further configured to, in response to the guest kernel's access operation to the central processing unit privilege register or the execution operation to the privileged instruction, generate the jump instruction based on the guest kernel's semi-virtualization interface; and, based on the jump instruction, jump from the guest kernel to the host kernel to access the central processing unit privilege register or execute the privileged instruction through the host kernel.
[0099] In one implementation, the guest kernel accessing virtual resources virtualized by the host kernel includes: the guest kernel managing virtual memory, and the guest kernel managing the virtual memory includes: the guest kernel modifying the guest page table;
[0100] The kernel jump unit 100 is further configured to, in response to the guest kernel's modification operation on the guest page table, generate the jump instruction based on the guest kernel's semi-virtualization interface; and, based on the jump instruction, jump from the guest kernel to the host kernel, so as to modify the shadow page table synchronized with the guest page table through the host kernel.
[0101] In one embodiment, the apparatus further includes: a virtual interrupt handling unit;
[0102] The virtual interrupt handling unit is used to obtain the currently generated virtual interrupt through the host kernel, and determine the type of the virtual interrupt based on the interrupt number of the virtual interrupt; if the type of the virtual interrupt represents a pass-through interrupt, it jumps to the guest kernel to process the virtual interrupt through the guest kernel; if the type of the virtual interrupt represents a non-pass-through interrupt, the host kernel injects the virtual interrupt into the guest kernel.
[0103] In one embodiment, the virtual interrupt handling unit is further configured to identify the interrupt number of the virtual interrupt and jump to the interrupt handler of the guest kernel corresponding to the interrupt number to execute the virtual interrupt; after the interrupt handler is executed, it returns to the host kernel.
[0104] In one embodiment, the kernel jump unit 100 is further configured to, in response to a switching instruction initiated by the virtual machine representing a switch to another virtual machine, generate the jump instruction based on the semi-virtualization interface of the guest kernel; and, based on the jump instruction, jump from the guest kernel to the host kernel to switch to the other virtual machine through the host kernel.
[0105] In one embodiment, the kernel jump unit 100 is further configured to generate the jump instruction in response to the exit instruction initiated by the virtual machine; based on the jump instruction, jump from the guest kernel to the host kernel, so as to clear the data structure of the virtual machine through the host kernel, thereby completing the exit of the virtual machine.
[0106] In one implementation, the virtual machine and the host machine run in the same address space, which includes a user space and a kernel space; wherein the user task occupies the user space, and the guest kernel and the host kernel occupy the kernel space.
[0107] In one implementation, the guest kernel is mapped in the kernel space, and the host kernel is mapped in an unused kernel cavity in the kernel space; or, the host kernel is mapped in the kernel space, and the guest kernel is mapped in an unused kernel cavity in the kernel space.
[0108] In one embodiment, the kernel jump unit 100 is further configured to generate the jump instruction in response to the host kernel mapping the executable file of the guest kernel into the address space where the guest kernel is located; based on the jump instruction, jump to the entry point of the guest kernel in the address space, and start the guest kernel from the entry point to complete the startup of the virtual machine.
[0109] The various units described in the above embodiments can be implemented by a computer chip or by a product with a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.
[0110] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this disclosure, the functions of each unit can be implemented in one or more software and / or hardware.
[0111] Please see Figure 7 This disclosure also provides a computer device, which includes a memory and a processor. The memory is used to store a computer program, and when the computer program is executed by the processor, it implements the above-described virtual machine operation method.
[0112] This disclosure also provides a computer-readable storage medium for storing a computer program that, when executed by a processor, implements the above-described virtual machine operation method.
[0113] The processor can be a central processing unit (CPU). It can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations thereof.
[0114] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the methods in the above-described embodiments.
[0115] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0116] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.
[0117] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, embodiments of apparatus, devices, and storage media are basically similar to method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0118] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.
[0119] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A method of running a virtual machine, characterized by, The virtual machine and the host machine run in a root mode, a guest kernel in the virtual machine and a host kernel in the host machine run in a first privilege layer in the root mode, a user task in the virtual machine runs in a second privilege layer in the root mode, the first privilege layer has a higher priority than the second privilege layer; and the method comprises: During running of the user task, if the guest kernel accesses a virtual resource virtualized by the host kernel, the guest kernel jumps to the host kernel based on a jump instruction; In the host kernel, after a hardware simulation operation is performed on the virtual resource accessed by the guest kernel, the guest kernel jumps back from the host kernel.
2. The method of claim 1, wherein, The virtual resource accessed by the guest kernel includes a virtual central processing unit, and the guest kernel accesses the virtual central processing unit in the following manner: the guest kernel performs an access operation on a central processing unit privilege register or an execution operation on a privilege instruction; The jump from the guest kernel to the host kernel based on the jump instruction comprises: In response to the access operation on the central processing unit privilege register or the execution operation on the privilege instruction by the guest kernel, a semi-virtualization interface of the guest kernel is used to generate the jump instruction; The jump from the guest kernel to the host kernel based on the jump instruction is used to access the central processing unit privilege register or execute the privilege instruction by the host kernel.
3. The method of claim 1, wherein, The virtual resource accessed by the guest kernel includes a virtual memory, and the guest kernel manages the virtual memory in the following manner: the guest kernel performs a modification operation on a guest page table; The jump from the guest kernel to the host kernel based on the jump instruction comprises: In response to the modification operation on the guest page table by the guest kernel, the semi-virtualization interface of the guest kernel is used to generate the jump instruction; The jump from the guest kernel to the host kernel based on the jump instruction is used to modify a shadow page table synchronized with the guest page table by the host kernel.
4. The method of claim 1, wherein, The method further comprises: The host kernel acquires a current generated virtual interrupt, and determines a type of the virtual interrupt based on an interrupt number of the virtual interrupt; If the type of the virtual interrupt represents a pass-through interrupt, the guest kernel is jumped to, so that the virtual interrupt is processed by the guest kernel; If the type of the virtual interrupt represents a non-pass-through interrupt, the virtual interrupt is injected into the guest kernel by the host kernel.
5. The method of claim 4, wherein, The injection of the virtual interrupt into the guest kernel by the host kernel comprises: An interrupt number of the virtual interrupt is identified, and the virtual interrupt is executed in an interrupt processing program of the guest kernel corresponding to the interrupt number; After the interrupt processing program is executed, the host kernel is returned.
6. The method of claim 1, wherein, The method further comprises: in response to a switch instruction initiated by the virtual machine, the switch instruction indicating a switch to another virtual machine, generating the jump instruction based on a paravirtualization interface of the guest kernel; based on the jump instruction, jumping from the guest kernel to the host kernel to switch to the another virtual machine by the host kernel.
7. The method of claim 1, wherein, The method further comprises: in response to an exit instruction initiated by the virtual machine, generating the jump instruction; based on the jump instruction, jumping from the guest kernel to the host kernel to clear a data structure of the virtual machine by the host kernel, thereby completing the exit of the virtual machine.
8. The method according to any one of claims 1 to 7, characterized in that, The virtual machine and the host run in a same address space, the address space comprising: a user space and a kernel space; wherein the user task occupies the user space, and the guest kernel and the host kernel occupy the kernel space.
9. The method of claim 8, wherein: the guest kernel is mapped in the kernel space, and the host kernel is mapped in a kernel hole of the kernel space that is not used; or, the host kernel is mapped in the kernel space, and the guest kernel is mapped in a kernel hole of the kernel space that is not used.
10. The method of claim 8, wherein, The method further comprises: in response to the host kernel mapping an executable file of the guest kernel into an address space in which the guest kernel is located, generating the jump instruction; based on the jump instruction, jumping to an entry point of the guest kernel in the address space, and starting the guest kernel from the entry point to complete the start of the virtual machine.
11. A virtual machine running device, characterized in that, The virtual machine and the host run in a root mode, a guest kernel in the virtual machine and a host kernel in the host run in a first privilege level in the root mode, a user task in the virtual machine runs in a second privilege level in the root mode, the first privilege level has a higher priority than the second privilege level, and the apparatus comprises: a kernel jump unit configured to, if the guest kernel accesses a virtual resource that is virtualized by the host kernel during running of the user task, jump from the guest kernel to the host kernel based on a jump instruction; an access execution unit configured to, after completing access to the virtual resource accessed by the guest kernel by a hardware emulation operation in the host kernel, jump from the host kernel back to the guest kernel.
12. A computer device, comprising: The computer device comprises a memory and a processor, the memory is configured to store a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1 to 10.
13. A computer-readable storage medium, characterized in that, The computer readable storage medium is configured to store a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1 to 10.
Citation Information
Patent Citations
System virtual machine facing Advanced RISC Machines (ARM) multi-core processor server platform
CN102929691A
Microprocessor with dual-level address translation
US20120079164A1