Method for suspending virtual machines of a microkernel hypervisor based on ARM VHE

By separating the vCPU running thread and processing thread in ARM VHE mode, the interrupt and exception handling of virtual machines are optimized, and the problems of resource waste and frequent state switching in virtual machine pause processing are solved, and system performance and resource utilization efficiency are improved.

CN119440735BActive Publication Date: 2025-07-29UNIV OF ELECTRONICS SCI & TECH OF CHINA +1
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202411575408.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-11-06
Publication Date
2025-07-29
Estimated Expiration
2044-11-06

AI Technical Summary

Technical Problem

In the existing virtualization technology, the virtual machine pause processing method in ARM VHE mode is not fully optimized, resulting in frequent abnormal state transitions and resource waste, and the existing solutions add additional CPU overhead and complexity.

Method used

Adopting the ARM VHE-based micro-kernel Hypervisor architecture, separating vCPU running threads and vCPU processing threads, using ARM VHE hardware virtualization extension, optimizing interrupt and exception handling, and reducing context switching frequency and resource exclusiveness through the high-priority design and asynchronous processing mechanism of vCPU processing threads.

Benefits of technology

Improve the performance of virtual machine pause processing, reduce the time overhead of exception and interrupt processing, and optimize system response speed and resource utilization efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119440735B_ABST
    Figure CN119440735B_ABST
Patent Text Reader

Abstract

The present invention discloses a method for handling virtual machine suspension of a microkernel Hypervisor based on ARM VHE. Deploy a microkernel Hypervisor based on ARM VHE, including a Hypervisor microkernel module, a Host OS service thread, and a virtual machine user-mode management thread. Among them, the CPU virtualization module in the kernel virtualization extension module of the Hypervisor microkernel module includes a vCPU running thread running in the EL0 / EL1 mode and a vCPU processing thread running in the EL0 mode. When the Hypervisor detects that the vCPU running thread is suspended, corresponding processing operations are adopted according to the suspension trigger reason: if the current suspension reason belongs to an interrupt trigger or an exception trigger processed under the Hypervisor microkernel, the kernel virtualization extension module directly performs the corresponding virtual machine suspension processing operation in EL2; if it is other situations, the vCPU processing thread is scheduled to perform the virtual machine suspension processing operation in EL0; after the operation is completed, the vCPU running thread resumes running. The present invention optimizes the handling of interrupts and exceptions of the Hypervisor for virtual machines and improves the performance of virtual machine suspension processing.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of virtual machines. More specifically, it relates to a method for handling virtual machine suspension of a microkernel Hypervisor based on ARM VHE. Background Art

[0002] A microkernel is a scaled-down version of the kernel that provides the core functions of an operating system. It is significantly different from a macro kernel. The microkernel only provides the most basic functions, such as task scheduling, inter-process communication, and memory management, while services such as device drivers, networking, and file systems are implemented in user space. Application programs communicate with the kernel service modules through IPC (usually message passing). This design reduces the amount of kernel code, achieves low coupling of services and address space isolation, thereby improving the stability, security, and portability of the system.

[0003] The core of virtualization technology lies in abstracting and centrally managing the underlying hardware resources to form a resource pool, which can then be shared by multiple independent execution environments. This technology enables multiple such environments to run in parallel on the same hardware platform. To ensure non-interference and secure isolation between these environments, virtualization technology relies on a key management component, namely the virtual machine manager (Hypervisor), which is responsible for coordinating and managing the allocation and use of these resources.

[0004] Virtualization technology mainly includes full virtualization and para virtualization. The biggest feature that distinguishes full virtualization technology from other virtualization technologies is that the guest machine can run on the virtualization platform without any modification; Para virtualization also uses the Hypervisor to communicate with the underlying hardware. Different from full virtualization, para virtualization requires modifying the kernel source code of the guest machine according to functional requirements, including replacing some privileged operations of the original guest operating system. In this way, some protection tasks that originally needed to be directly executed by the CPU can be directly executed in the modified kernel through a virtual machine call Hypercall similar to the system call Syscall, without causing a trap and being simulated by the Hypervisor. This effectively improves the efficiency of the virtual machine. Therefore, in scenarios with high real-time requirements, para virtualization has more significant advantages.

[0005] The implementation methods of virtualization are mainly divided into Type-1 virtual machine managers (Hypervisors) and Type-2 virtual machine managers (Hypervisors). The Type-1 Hypervisor runs directly on the host hardware, controls the hardware and manages guest operating systems, providing a higher level of isolation (Xen); the Type-2 Hypervisor runs as an application on the host operating system. Different from the Type-1 Hypervisor that runs directly on the hardware, the Type-2 Hypervisor provides virtualization services on top of the host operating system, and calls common operating system functions such as scheduling, memory management, and hardware support provided by the host operating system to achieve virtualization.

[0006] The Hypervisor architecture of the microkernel generally includes two modes: the cross-layer mode and the ARM VHE (Virtualization Extensions) mode. The cross-layer mode mainly implements the hypervisor by splitting it into three hierarchical components: Lowvisor, Midvisor, and Highvisor. Lowvisor is the only functional component running in the Hypervisor (EL2), and its main function is to communicate directly with the hardware; Midvisor and Highvisor run in the kernel mode (EL1) and user mode (EL0) of the Host OS respectively to provide management services for virtual machines. The ARM VHE mode makes the entire kernel of the Hypervisor run at the EL2 level, while virtual machines run in the form of threads at the EL1 and EL0 levels.

[0007] Virtual machine suspension means that due to virtual machine exceptions or interrupts of the current CPU core, the virtual machine pauses at this time, and the Hypervisor performs exception or interrupt handling. After the Hypervisor finishes processing, the virtual machine resumes running this process. For the handling of virtual machine suspension, the design of the cross-layer mode does not make full use of the virtualization host extensions supported by ARMv8, and the hierarchical design will cause additional time overhead due to frequent abnormal state transitions. In the ARM VHE mode, since the entire kernel of the Hypervisor runs at EL2, only the kernel of the virtual machine runs at EL1, and the threads of the virtual machine and the Hypervisor run at EL0, it is easier to handle virtual machine suspension in hardware. However, currently, the focus of the ARM VHE mode is to judge whether to call the vCPU thread of the general system or the vCPU thread of the real-time system according to the priority of the virtual machine process to be scheduled reported by the recorder to ensure real-time performance, and no exploration has been carried out on the optimization of virtual machine interrupt and exception handling under this architecture.

[0008] Regarding the specific virtual machine pause processing method, the existing exception and interruption processing methods have the following deficiencies:

[0009] (1) The exception handling method proposed in the patent with the patent number "CN202311606091.9" and the patent name "Hypervisor Virtualization System Exception Handling System and Method" requires additional resources to run the Host VM and transmits the exception information of the Guest OS through the Event Channel, increasing the complexity of the kernel.

[0010] (2) The separation strategy proposed in the patent with the patent number "CN202010660215.1" and the patent name "Separate Virtual Machine and Its Virtual Machine Architecture, Construction Method and Optimization Method" does not fully utilize the CPU core resources. After the vCPU running thread is suspended, the current physical core will be in a waiting state until the vCPU monitoring thread on another core completes the processing and wakes up. In addition, each VM EXIT involves inter-core communication, increasing the CPU overhead.

[0011] (3) The design of user-mode Hypervisor intervention in interrupt injection is proposed in the patent with the patent number "CN202110088713.8" and the patent name "An Interrupt Virtualization Processing Method and System for the ARM Architecture Virtualization Field". For each injection of a virtual interrupt, this design scheme incurs additional costs for the context restoration of the user-mode thread and the exception level transition.

[0012] (4) For the design schemes of KVM and ZVM, the vCPU thread contains two sets of contexts, one for running the virtual machine code and the other for running the Hypervisor code. Each VM ENTRY and VM EXIT requires additional saving and restoring of the Hypervisor context, which increases the complexity and overhead of virtual machine pause processing. Summary of the Invention

[0013] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a virtual machine pause processing method based on the microkernel Hypervisor of ARM VHE. By improving the architecture of the ARM VHE microkernel Hypervisor and proposing a separate design for the vCPU running thread and the vCPU processing thread, the handling of interrupts and exceptions of the Hypervisor for virtual machines is optimized, and the temporary processing performance of virtual machines is improved.

[0014] To achieve the above-mentioned invention purpose, the virtual machine pause processing method based on the microkernel Hypervisor of ARM VHE of the present invention includes the following steps:

[0015] S1: Deploy a microkernel Hypervisor based on ARM VHE in the microkernel, including a Hypervisor microkernel module, Host OS service threads, and virtual machine user-mode management threads, where:

[0016] The Hypervisor microkernel module runs in EL2 mode and includes a microkernel module and a kernel virtualization extension module. The microkernel module is mainly responsible for providing the core functions of the host operating system, including thread and process management, inter-process communication, and address space management. The kernel virtualization extension module is used for virtualization function support, including a CPU virtualization module, a memory virtualization module, a clock virtualization module, an interrupt virtualization module, and a device virtualization module, where:

[0017] The CPU virtualization module includes vCPU running threads and vCPU processing threads. The priority of the vCPU processing threads is higher than that of the vCPU running threads. One CPU core supports multiple vCPU running threads running in EL0 / EL1 mode and one vCPU processing thread running in EL0 mode. Among them, the vCPU running threads are responsible for saving the context related to the virtual machine and running the code of the virtual machine. The vCPU processing threads are responsible for handling the suspension reasons of the vCPU running threads in user mode.

[0018] The interrupt virtualization module is used to support the GICv3's interrupt management for virtual machines.

[0019] The memory virtualization module is used to perform physical address and virtual address conversion using the two-stage address translation mechanism provided by the ARM architecture to ensure address isolation between the virtual machine and the Hypervisor.

[0020] The clock virtualization module is used to perform time management and time isolation for the guest operating system using the virtual clock in EL1 mode.

[0021] The device virtualization module is used to create virtual versions of computer hardware devices to achieve abstraction and sharing of physical resources.

[0022] The Host OS service threads run in EL0 mode and are used to provide user-mode services for the host machine.

[0023] The virtual machine user-mode management threads run on the main core of the Host OS service threads and are responsible for the control at the virtual machine level.

[0024] S2: The Hypervisor realizes the automatic deployment of virtual machines through shell commands; after the virtual machines run, the virtual machine kernels operate at the EL1 privilege level, while the internal application programs of the virtual machines execute at the EL0 user level; when specific sensitive instructions are executed or abnormal access occurs, the system will switch to the EL2 mode and the Hypervisor will perform corresponding processing;

[0025] S3: The Hypervisor monitors the running threads of vCPUs. When a vCPU running thread pauses, the Hypervisor performs a pause handling to resume the running of the vCPU running thread. The specific method is as follows:

[0026] S3.1: Judge whether the pause reason is triggered by an interrupt. If so, go to step S3.2; otherwise, go to step S3.5;

[0027] S3.2: Judge whether the current interrupt belongs to the virtual machine. If so, go to step S3.3; otherwise, go to step S3.4;

[0028] S3.3: The interrupt virtual module in the Hypervisor performs virtual interrupt injection, and then degrades the current interrupt; go to step S3.9;

[0029] S3.4: The Hypervisor calls the interrupt service program belonging to its own interrupt; go to step S3.9;

[0030] S3.5: The Hypervisor reads and parses the values of relevant registers to judge the specific type of the exception;

[0031] S3.6: Judge whether the current exception trigger can be processed in the Hypervisor microkernel. If so, go to step S3.7; otherwise, go to step S3.8;

[0032] S3.7: The Hypervisor completes the exception handling in the EL2 mode, and then goes to step S3.9;

[0033] S3.8: Call the vCPU processing thread for processing. The specific method is as follows:

[0034] 1) The Hypervisor suspends the current vCPU running thread and saves the context of this vCPU running thread;

[0035] 2) The Hypervisor writes the pause reason information of the vCPU running thread into the buffer shared by the user state and the kernel state of the vCPU processing thread;

[0036] 3) The Hypervisor wakes up the vCPU processing thread and makes the current vCPU running thread block and wait;

[0037] 4) The vCPU processing thread reads and parses the vCPU running thread pause reason information from the buffer shared by the user mode and the kernel mode, processes it in the EL0 mode, wakes up the corresponding vCPU running thread after processing, and the vCPU running thread joins the thread ready queue to wait for scheduling;

[0038] 5) The Hypervisor suspends the processed vCPU processing thread;

[0039] S3.9: The Hypervisor restores the context of the vCPU running thread, and the vCPU running thread continues to execute.

[0040] The virtual machine suspension processing method of the microkernel Hypervisor based on ARM VHE of the present invention deploys a microkernel Hypervisor based on ARMVHE, including a Hypervisor microkernel module, a Host OS service thread, and a virtual machine user mode management thread. Among them, the Hypervisor microkernel module includes a microkernel module and a kernel virtualization extension module. The CPU virtualization module in the kernel virtualization extension module includes a vCPU running thread running in the EL0 / EL1 mode and a vCPU processing thread running in the EL0 mode. When the Hypervisor detects that the vCPU running thread pauses, corresponding processing operations are adopted according to the pause trigger reason: If the current pause reason belongs to an interrupt trigger or an exception trigger processed under the Hypervisor microkernel, the kernel virtualization extension module directly performs the corresponding virtual machine suspension processing operation in EL2. If it is other situations, such as the situation of calling the Host OS user mode service, the vCPU processing thread is scheduled to perform the virtual machine suspension processing operation in EL0; after the operation is completed, the vCPU running thread resumes running.

[0041] The present invention has the following beneficial effects:

[0042] 1) In terms of architecture, the present invention mainly utilizes ARM VHE, adds kernel virtualization extensions to build a Type-2 Hypervisor running in EL2, only runs the virtual machine kernel in EL1, and runs the Hypervisor and the virtual machine user mode services in EL0. By utilizing the ARM VHE hardware virtualization extension, the overhead caused by abnormal state transitions is reduced, the context switching frequency is optimized, and the system response speed and resource utilization efficiency are improved;

[0043] 2) In terms of virtual machine suspension processing, the present invention utilizes the design of separating the vCPU running thread and the vCPU processing thread to optimize the Hypervisor's handling of interrupts and exceptions in virtual machines: (1) In terms of interrupt handling, the vCPU running thread in the present invention is suspended when processing interrupts and resumed after processing. Only the preservation and restoration of the virtual machine context are involved in the whole process, thus avoiding the overhead of preserving and restoring the Hypervisor context in each VM ENTRY and VM EXIT, and further shortening the interrupt handling time. (2) In terms of exception handling, the present invention efficiently processes exceptions that can be directly processed in the EL2 mode, reduces the dependence on the Hypervisor context, and enables the vCPU running thread to quickly resume running; for exceptions that cannot be directly processed in EL2, the Hypervisor suspends the current vCPU running thread, writes the suspension reason information, and wakes up the vCPU processing thread, optimizing the exception handling process. This design rationally utilizes CPU resources. By setting the priority of the vCPU processing thread higher than that of the vCPU running thread, long-term resource exclusions are avoided, and through asynchronous processing support, the service response time and the utilization efficiency of system resources are optimized. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 is a flowchart of the specific implementation manner of the virtual machine suspension processing method of the microkernel Hypervisor based on ARM VHE of the present invention;

[0045] Figure 2 is an architecture diagram of the microkernel Hypervisor based on ARM VHE of the present invention;

[0046] Figure 3 is a working mode diagram of the vCPU running thread and the vCPU processing thread of the microkernel Hypervisor based on ARM VHE of the present invention;

[0047] Figure 4 is a flowchart of the Hypervisor suspending the vCPU running thread in the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0048] The following describes the specific implementation manner of the present invention with reference to the accompanying drawings, so that those skilled in the art can better understand the present invention. It should be particularly noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0049] EXAMPLE

[0050] Figure 1This is the flowchart of the specific implementation of the virtual machine pause processing method of the microkernel Hypervisor based on ARM VHE in the present invention. As Figure 1 shown, the virtual machine pause processing method of the microkernel Hypervisor based on ARM VHE in the present invention includes the following steps:

[0051] S101: Configure the microkernel Hypervisor based on ARM VHE:

[0052] In order to optimize the virtual machine interrupt, the present invention designs a microkernel Hypervisor architecture based on ARM VHE, making full use of the hardware support provided by ARM VHE to achieve a more reasonable deployment of Hypervisor components. Figure 2 This is the architecture diagram of the microkernel Hypervisor based on ARM VHE in the present invention. Figure 3 This is the working mode diagram of the vCPU running thread and the vCPU processing thread of the microkernel Hypervisor based on ARM VHE in the present invention. As Figure 2 and Figure 3 shown, the Type-2 microkernel Hypervisor based on ARM VHE in the present invention includes a Hypervisor microkernel module, a Host OS service thread, and a virtual machine user state management thread (VMM). Next, each module will be described in detail.

[0053] The Hypervisor microkernel module runs in EL2 mode and includes a microkernel module and a kernel virtualization extension module. Among them, the microkernel module is mainly responsible for providing the core functions of the host operating system, including thread and process management, inter-process communication (IPC), and address space management; the kernel virtualization extension module is used for virtualization function support, including a CPU virtualization module, a memory virtualization module, a clock virtualization module, an interrupt virtualization module, and a device virtualization module, where:

[0054] The CPU virtualization module includes vCPU running threads and vCPU processing threads. The priority of the vCPU processing thread is higher than that of the vCPU running thread. One CPU core supports multiple vCPU running threads running in the EL0 / EL1 mode and one vCPU processing thread running in the EL0 mode. Among them, the vCPU running thread is responsible for saving the context related to the virtual machine and running the code of the virtual machine; the vCPU processing thread is responsible for processing the pause reason of the vCPU running thread in the user state. The vCPU processing thread reads and parses the pause reason of the vCPU running thread from the buffer shared by the user state and the kernel state, and performs corresponding processing (such as calling the service thread of the Host OS in EL0). After the processing is completed, the corresponding vCPU running thread is awakened to resume running. Such a design only adds one recovery of the Host OS thread context like the design of the class ZVM, and in the present invention, the specific processing function is placed in the user state, reducing the kernel code and maintaining the advantages of the microkernel.

[0055] The interrupt virtualization module is used to support the interrupt management of the virtual machine by GICv3, mainly including: a. vGIC initialization; b. access simulation: GICD access simulation, GICR access simulation, ICC_SGIR access simulation, and ICC_SRE access simulation; c. virtual interrupt injection; d. maintaining the interrupt design.

[0056] The memory virtualization module is used to perform physical address and virtual address conversion by using the two-stage address conversion mechanism provided by the ARM architecture to ensure address isolation between the virtual machine and the Hypervisor. The specific implementation method of physical address and virtual address conversion in this embodiment is as follows:

[0057] (1) In the EL0 mode, through the root service rootserver of the Host OS service thread, a memory area of a specified size is applied for in the user state, and the corresponding host physical address HPA is resolved and used as the memory area of the virtual machine;

[0058] (2) Parse the intermediate physical address IPA of each device / memory in the virtual machine configuration file;

[0059] (3) In the EL0 mode, enter the kernel through a system call, and pass the IPA, HPA, and the corresponding memory attribute information to the kernel, and the kernel completes the second-stage mapping of memory virtualization.

[0060] The clock virtualization module is used to manage time and isolate time for the guest operating system using virtual clocks in EL1 mode. The specific methods for time management and clock isolation in this embodiment are as follows: Capture the access to the physical clock of the virtual machine in EL1 mode to EL2, locate the corresponding virtual clock register according to the encoded accessed physical clock, and complete the simulation of the virtual machine reading and writing the physical clock register by reading and writing the virtual clock register.

[0061] The device virtualization module is used to create a virtual version of computer hardware devices, realizing the abstraction and sharing of physical resources. This technology allows multiple virtual machines or applications to share the same physical hardware, thereby improving resource utilization and flexibility.

[0062] The Host OS service thread runs in EL0 mode and is used to provide user-level services for the host machine.

[0063] The virtual machine user-mode management thread runs on the main core of the Host OS service thread, that is, also runs in EL0 mode, and is used to be responsible for the control at the virtual machine level, mainly including the creation, suspension, resume, and deletion of virtual machines.

[0064] S102: Deploy a virtual machine:

[0065] In the present invention, the Hypervisor realizes the automatic deployment of the virtual machine through shell commands. After the virtual machine runs, the virtual machine kernel operates at the EL1 privilege level, while the internal application of the virtual machine executes at the EL0 user level. When specific sensitive instructions are executed or abnormal access occurs, the system will switch to EL2 mode and the Hypervisor will perform corresponding processing.

[0066] S103: Suspension processing:

[0067] The Hypervisor monitors the vCPU running thread. When the vCPU running thread is suspended, the Hypervisor performs suspension processing to resume the operation of the vCPU running thread. Figure 4 is the flowchart of the Hypervisor in the present invention performing suspension processing on the vCPU running thread. As Figure 4 shown, the specific method for the Hypervisor in the present invention to perform suspension processing on the vCPU running thread is as follows:

[0068] S401: Determine whether the suspension reason is interrupt-triggered. If so, go to step S402; otherwise, go to step S405.

[0069] S402: Determine whether the current interrupt belongs to the virtual machine. If so, go to step S403; otherwise, go to step S404.

[0070] S403: Virtual Interrupt Injection:

[0071] The interrupt virtualization module in the Hypervisor performs virtual interrupt injection and then degrades the current interrupt. Proceed to step S409.

[0072] S404: Hypervisor Interrupt Handling:

[0073] The Hypervisor calls the interrupt service routine belonging to its own interrupt. Proceed to step S409.

[0074] S405: Analyze the Pause Reason:

[0075] After research, it is found that the reasons for the vCPU running thread to pause due to exceptions other than interrupt triggers mainly include sensitive instruction exception capture (such as HVC32, HVC64, SMC32, and SMC64), DATA ABORT exception capture (such as two-stage memory access error), and sensitive register access exception capture (such as the virtual machine accessing the physical clock register under EL1), etc. Different exception triggers are handled differently. When an exception is triggered, the values of relevant registers such as ESR_EL2, FAR_EL2, and HPFAR_EL2 will record the detailed information of the current exception. The Hypervisor reads and parses the values of the registers related to the exception trigger to determine the specific type of the exception.

[0076] S406: Determine whether the current exception trigger can be handled in the Hypervisor microkernel. If yes, proceed to step S407; otherwise, proceed to step S408.

[0077] S407: Hypervisor Exception Handling:

[0078] The Hypervisor completes exception handling in EL2 mode and then proceeds to step S409.

[0079] The specific handling methods for different types of exception triggers may vary. Taking GICD access simulation as an example, the Hypervisor reads and writes the structure information storing virtual interrupts according to the type and method of the GICD register accessed by the virtual machine. If it is a write operation, it may be designed to modify the corresponding hardware register, and then restore the context of the vCPU running thread, and the vCPU running thread continues to execute. This process is similar to the situation of virtual interrupt injection, reducing the saving and restoring of Hypervisor-related context information.

[0080] S408: Call the vCPU Processing Thread:

[0081] If the current exception type cannot be directly processed in the microkernel (for example, it is necessary to call the driver of the Host OS in EL0 or other service threads of the Host OS), it is necessary to call the vCPU processing thread for processing at this time. The specific method is as follows:

[0082] 1) The Hypervisor suspends the current vCPU running thread and saves the context of the vCPU running thread;

[0083] 2) The Hypervisor writes the pause reason information of the vCPU running thread into the buffer shared by the user mode and the kernel mode of the vCPU processing thread;

[0084] 3) The Hypervisor wakes up the vCPU processing thread and makes the current vCPU running thread block and wait;

[0085] 4) The vCPU processing thread reads and parses the pause reason information of the vCPU running thread from the buffer shared by the user mode and the kernel mode, processes it in the EL0 mode, wakes up the corresponding vCPU running thread after processing, and the vCPU running thread joins the thread ready queue to wait for scheduling;

[0086] 5) The Hypervisor suspends the vCPU processing thread that has been processed.

[0087] Since the priority of the vCPU processing thread in the present invention is higher than that of the vCPU running thread, in order to avoid the situation that due to specific vCPU running thread pause reasons, the vCPU processing thread runs for a long time and monopolizes the CPU resources, resulting in all other vCPU running threads on the same physical CPU core being unable to be scheduled and run, the present embodiment also proposes the following optimization scheme for the vCPU processing thread:

[0088] Determine the pause reason processing method of the vCPU processing thread according to the number of time slices provided by the required Host OS service thread. The specific method is as follows:

[0089] If the number of time slices required by the vCPU processing thread is less than or equal to the preset threshold, the vCPU processing thread processes the pause reason of the vCPU running thread in a synchronous manner. The specific method is: directly call the synchronous service interface provided by the Host OS service thread, and after the operation is completed, wake up the suspended vCPU running thread through a system call. Since the time required for service completion is short, the synchronous processing method is adopted, so that other vCPU running threads will not be blocked for a long time.

[0090] If the number of time slices required by the vCPU processing thread is greater than a preset threshold, the vCPU processing thread processes the reason for the suspension of the vCPU running thread asynchronously. The specific method is as follows: The vCPU processing thread registers a callback function with the asynchronous Host OS service thread. The priority of the asynchronous Host OS service thread is the same as that of the vCPU running thread. Therefore, the asynchronous Host OS service thread and other vCPU running threads are rotated and executed according to the thread scheduling policy of the Host OS service thread. After the asynchronous service thread is completed, the corresponding suspended vCPU running thread is awakened within the corresponding callback function.

[0091] S409: Resume running:

[0092] The Hypervisor restores the context of the vCPU running thread, and the vCPU running thread continues to execute.

[0093] It should be added here that in the conventional virtual machine interruption handling method of the ARM architecture, whether it is GICv2 or GICv3, all interruptions need to be routed to EL2 for processing by the Hypervisor. The vCPU running thread will suspend running. The Hypervisor determines whether the current interruption belongs to the Hypervisor or the virtual machine, and then performs Hypervisor interruption handling and virtual interruption injection respectively. After the processing is completed, the vCPU running thread resumes running. That is to say, each interruption trigger will involve the suspension and resume of the vCPU running thread, which also includes the saving and restoration of the vCPU thread context. According to the above process, it can be seen that the vCPU thread in the architecture of the present invention only includes the context of virtual machine operation. Therefore, in the case of interruption handling, compared with vCPU thread designs such as ZVM, the restoration of the Hypervisor context is reduced when the virtual machine exits, and the saving of the Hypervisor context is reduced before the virtual machine enters.

[0094] Although the above-described illustrative specific embodiments of the present invention have been described to facilitate the understanding of the present invention by those skilled in the art of the present technology, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art of the present technology, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions and creations using the concept of the present invention are within the scope of protection.

Claims

1. A method for handling virtual machine suspension of a microkernel Hypervisor based on ARM VHE, characterized in that It includes the following steps: S1: Deploy a microkernel Hypervisor based on ARM VHE in the microkernel, including a Hypervisor microkernel module, a Host OS service thread, and a virtual machine user-mode management thread, where: The Hypervisor microkernel module runs in EL2 mode and includes a microkernel module and a kernel virtualization extension module. The microkernel module is mainly responsible for providing the core functions of the host operating system, including thread and process management, inter-process communication, and address space management; the kernel virtualization extension module is used for virtualization function support, including a CPU virtualization module, a memory virtualization module, a clock virtualization module, an interrupt virtualization module, and a device virtualization module, where: The CPU virtualization module includes a vCPU running thread and a vCPU processing thread. The priority of the vCPU processing thread is higher than that of the vCPU running thread. One CPU core supports multiple vCPU running threads running in EL0 / EL1 mode and one vCPU processing thread running in EL0 mode; the vCPU running thread is responsible for saving the context related to the virtual machine and running the code of the virtual machine; the vCPU processing thread is responsible for handling the pause reason of the vCPU running thread in user mode; The interrupt virtualization module is used to support the interrupt management of the GICv3 for the virtual machine; The memory virtualization module is used to perform physical address and virtual address conversion using the two-stage address conversion mechanism provided by the ARM architecture to ensure address isolation between the virtual machine and the Hypervisor; The clock virtualization module is used to perform time management and time isolation for the guest operating system using the virtual clock in EL1 mode; The device virtualization module is used to create a virtual version of the computer hardware device to achieve the abstraction and sharing of physical resources; The Host OS service thread runs in EL0 mode and is used to provide the user-mode services of the host; The virtual machine user-mode management thread runs on the main core of the Host OS service thread and is responsible for the control at the virtual machine level; S2: The Hypervisor realizes the automatic deployment of the virtual machine through shell commands; after the virtual machine runs, the virtual machine kernel operates at EL1 privilege level, while the internal application programs of the virtual machine execute at EL0 user level; when specific sensitive instructions are executed or abnormal access occurs, the system will switch to EL2 mode and the Hypervisor will perform corresponding processing; S3: The Hypervisor monitors the vCPU running thread. When the vCPU running thread pauses, the Hypervisor performs pause processing to resume the operation of the vCPU running thread. The specific method is: S3.1: Judge whether the pause reason is triggered by an interrupt. If so, go to step S3.2; otherwise, go to step S3.5; S3.2: Judge whether the current interrupt belongs to the virtual machine. If so, go to step S3.3; otherwise, go to step S3.4; S3.3: The interrupt virtual module in the Hypervisor performs virtual interrupt injection, and then degrades the current interrupt; go to step S3.9; S3.4: The hypervisor calls the interrupt service routine that belongs to its own interrupt; go to step S3.9; S3.5: The hypervisor reads and parses the values of the registers related to the exception trigger to determine the specific type of the exception; S3.6: Determine whether the current exception trigger can be processed in the hypervisor microkernel. If so, go to step S3.7; otherwise, go to step S3.8; S3.7: The hypervisor completes the exception handling in EL2 mode and then goes to step S3.9; S3.8: Call the vCPU processing thread for processing. The specific method is as follows: 1) The hypervisor suspends the current vCPU running thread and saves the context of the vCPU running thread; 2) The hypervisor writes the pause reason information of the vCPU running thread into the buffer shared by the user mode and the kernel mode of the vCPU processing thread; 3) The hypervisor wakes up the vCPU processing thread and makes the current vCPU running thread block and wait; 4) The vCPU processing thread reads and parses the vCPU running thread pause reason information from the buffer shared by the user mode and the kernel mode, processes it in EL0 mode, wakes up the corresponding vCPU running thread after processing, and the vCPU running thread joins the thread ready queue and waits to be scheduled; 5) The hypervisor suspends the vCPU processing thread that has been processed; S3.9: The hypervisor restores the context of the vCPU running thread, and the vCPU running thread continues to execute.

2. The virtual machine suspension processing method according to claim 1, characterized in that The specific method of physical address and virtual address conversion in step S1 is as follows: (1) In EL0 mode, apply for a memory area of a specified size in the user mode through the root service rootserver of the Host OS service thread, and reverse-resolve the corresponding host physical address HPA as the memory area of the virtual machine; (2) Resolve the intermediate physical address IPA of each device / memory in the virtual machine configuration file; (3) In EL0 mode, enter the kernel through a system call, transfer the IPA, HPA, and the corresponding memory attribute information to the kernel, and the kernel completes the second-stage mapping of memory virtualization.

3. The virtual machine suspension processing method according to claim 1, wherein The specific method of time management and clock isolation in step S1 is: capture the access to the physical clock of the virtual machine in EL1 mode to EL2, locate the corresponding virtual clock register according to the encoded physical clock being accessed, and complete the simulation of reading and writing the physical clock register of the virtual machine by reading and writing the virtual clock register.

4. The virtual machine suspension processing method according to claim 1, wherein In step S3, determine the processing method of the vCPU running thread pause reason according to the number of time slices provided by the required Host OS service thread. The specific method is as follows: If the number of time slices required by the vCPU processing thread is less than or equal to the preset threshold, the vCPU processing thread processes the vCPU running thread pause reason in a synchronous manner. The specific method is: directly call the synchronous service interface provided by the Host OS service thread, and after the operation is completed, wake up the suspended vCPU running thread through a system call; If the number of time slices required by the vCPU processing thread is greater than a preset threshold, the vCPU processing thread processes the reason for the suspension of the vCPU running thread asynchronously. The specific method is as follows: The vCPU processing thread registers a callback function with the asynchronous Host OS service thread. The priority of the asynchronous Host OS service thread is the same as that of the vCPU running thread. Therefore, the asynchronous Host OS service thread and other vCPU running threads are rotated and executed according to the thread scheduling policy of the Host OS service thread. After the asynchronous service thread is completed, the corresponding suspended vCPU running thread is awakened within the corresponding callback function.

Citation Information

Patent Citations

  • Interrupt virtualization processing method and system oriented to ARM (Advanced RISC Machines) architecture virtualization field

    CN112817690A

  • Separate virtual machine and virtual machine architecture, construction method and optimization method thereof

    CN113918272B

  • Hypervisor virtualization system exception handling system and method

    CN117608750A

  • Abnormality processing method and device, processor and electronic equipment

    CN117493114A

  • Implementing fine grain data coherency of a shared memory region

    US20200327048A1