Virtual machine pause processing method of micro kernel Hypervisor based on ARM VHE
By adopting the separation design of vCPU running threads and vCPU processing threads in ARM VHE mode, the virtual machine pause processing is optimized, and the problems of resource waste and complexity in the existing technology are solved, and system performance and resource utilization efficiency are improved.
Patent Information
- Application Number
- CN202411575408.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2025-02-14
- Estimated Expiration
- 2044-11-06
AI Technical Summary
The prior art has resource waste and complexity in virtual machine pause processing, especially in ARM VHE mode, which does not fully utilize hardware virtualization extensions, resulting in frequent abnormal state transitions and context switching, affecting system performance.
The virtual machine pause processing method based on ARM VHE is adopted. The separation design of vCPU running threads and vCPU processing threads is optimized, and interrupt and exception handling is reduced to the saving and recovery overhead of Hypervisor context.
Improve the performance of virtual machine pause processing, reduce the overhead of abnormal state transitions and context switching, and optimize resource utilization efficiency and system response speed.
Smart Images

Figure CN119440735A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the technical field of virtual machines, and more specifically, relates to a virtual machine suspension processing method of a microkernel Hypervisor based on ARM VHE. Background Art
[0002] A microkernel is a streamlined version of the kernel that provides the core functions of the operating system. It is significantly different from a macrokernel in that it only provides the most basic functions, such as task scheduling, inter-process communication, and memory management, while services such as device drivers, networks, and file systems are implemented in user space. Applications communicate with kernel service modules through IPC (usually message passing). This design reduces the amount of kernel code, achieves low coupling of services, and isolates address spaces, thereby improving system stability, security, and portability.
[0003] The core of virtualization technology is to abstract and centrally manage the underlying hardware resources to form a resource pool, which can then be shared by multiple independent execution environments. This technology allows multiple such environments to run in parallel on the same hardware platform. In order to ensure that these environments do not interfere with each other and are securely isolated, virtualization technology relies on a key management component, the hypervisor, which is responsible for coordinating and managing the allocation and use of these resources.
[0004] Virtualization technology mainly includes full virtualization and paravirtualization. The biggest difference between full virtualization technology and other virtualization technologies is that the client can run on the virtualization platform without any modification; paravirtualization also uses Hypervisor to communicate with the underlying hardware, but unlike full virtualization, paravirtualization needs to modify the client's kernel source code according to functional requirements, including replacing some privileged operations of the original client operating system. In this way, some protection tasks that originally needed to be executed directly through 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 Hypervisor simulation, which effectively improves the efficiency of the virtual machine. Therefore, in scenarios with high real-time requirements, paravirtualization has more significant advantages.
[0005] The implementation methods of virtualization are mainly divided into Type-1 hypervisor and Type-2 hypervisor. Type-1 hypervisor runs directly on the host hardware, controls the hardware and manages the client operating system, and provides a higher level of isolation (Xen); Type-2 hypervisor runs as an application on the host operating system. Unlike Type-1 hypervisor that runs directly on the hardware, 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 microkernel Hypervisor architecture generally includes two modes: cross-layer mode and ARM VHE (virtualization extension) mode. The cross-layer mode mainly splits the hypervisor into three layered components: Lowvisor, Midvisor and Highvisor. Lowvisor is the only functional component running on Hypervisor (EL2), and its main function is to communicate directly with the hardware; Midvisor and Highvisor run in the kernel state (EL1) and user state (EL0) of Host OS respectively to provide management services for virtual machines. ARM VHE mode allows the Hypervisor kernel to run as a whole at the EL2 level, while the virtual machine runs at the EL1 and EL0 levels in the form of threads.
[0007] Virtual machine suspension refers to the process that the virtual machine is suspended due to a virtual machine exception or an interruption of the current CPU core. The hypervisor handles the exception or interrupt. After the hypervisor completes the processing, the virtual machine resumes running. For virtual machine suspension processing, the cross-layer mode design does not fully utilize the virtualization host extensions (Virtualization Host Extensions) supported by ARMv8. The layered design will cause additional time overhead caused by frequent abnormal state transitions. The ARM VHE mode runs the kernel of the hypervisor as a whole in EL2, EL1 only runs the kernel of the virtual machine, and EL0 runs the threads of the virtual machine and the hypervisor, which makes it easier to handle virtual machine suspension in hardware. However, the current focus of the ARM VHE mode is to determine whether to call the vCPU thread of the general system or the vCPU thread of the real-time system to ensure real-time performance based on the priority of the virtual machine process to be scheduled reported by the recorder, but the optimization of virtual machine interrupt and exception processing under this architecture has not been explored.
[0008] As for the specific virtual machine suspension processing method, the existing exception and interrupt processing methods have the following shortcomings:
[0009] (1) The exception handling method proposed in the patent with patent number “CN202311606091.9” and patent name “Hypervisor virtualization system exception handling system and method” requires additional resources to run the Host VM and transmit the exception information of the Guest OS through the event channel, which increases the complexity of the kernel.
[0010] (2) The separation strategy proposed in the patent number "CN202010660215.1" and the patent name "Separated 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, which increases CPU overhead.
[0011] (3) In the patent with patent number "CN202110088713.8" and patent name "A method and system for interrupt virtualization processing in the field of ARM architecture virtualization", a design of user-state hypervisor intervention in interrupt injection is proposed. This design scheme has additional costs for context recovery and exception level transition of user-state threads for each virtual interrupt injection.
[0012] (4) For the KVM and ZVM designs, 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 the hypervisor context to be saved and restored, which increases the complexity and overhead of the virtual machine pause process. Summary of the invention
[0013] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a virtual machine suspension processing method based on an ARM VHE microkernel Hypervisor. By improving the architecture of the ARM VHE microkernel Hypervisor and proposing a separation design of vCPU running threads and vCPU processing threads, the Hypervisor is optimized to handle interrupts and exceptions of virtual machines, thereby improving the temporary processing performance of virtual machines.
[0014] In order to achieve the above-mentioned object of the invention, the virtual machine suspension processing method of the microkernel Hypervisor based on ARM VHE of the present invention comprises the following steps:
[0015] S1: Deploy the ARM VHE-based microkernel Hypervisor in the microkernel, including the Hypervisor microkernel module, Host OS service thread, and virtual machine user state management thread, 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 to support virtualization functions, including CPU virtualization module, memory virtualization module, clock virtualization module, interrupt virtualization module, and device virtualization module, among which:
[0017] The CPU virtualization module includes vCPU running threads and vCPU processing threads. The priority of vCPU processing threads is higher than that of 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. The vCPU running thread is responsible for saving the context related to the virtual machine and the code for running the virtual machine. The vCPU processing thread is responsible for processing the suspension reason of the vCPU running thread in user mode.
[0018] The interrupt virtualization module is used to support GICv3's interrupt management of virtual machines;
[0019] The memory virtualization module is used to use the two-stage address translation mechanism provided by the ARM architecture to translate physical addresses and virtual addresses to ensure address isolation between the virtual machine and the Hypervisor;
[0020] The clock virtualization module is used to use the virtual clock in EL1 mode to perform time management and time isolation on the client operating system;
[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 thread runs in EL0 mode and is used to provide user-mode services to the host machine.
[0023] The virtual machine user state management thread runs in the main core of the Host OS service thread and is responsible for virtual machine level control;
[0024] S2: Hypervisor automatically deploys virtual machines through shell commands. After the virtual machine is running, the virtual machine kernel operates at the EL1 privilege level, while the application program inside the virtual machine is executed at the EL0 user level. When a specific sensitive instruction is executed or an abnormal access occurs, the system will switch to EL2 mode and the Hypervisor will handle it accordingly.
[0025] S3: The Hypervisor monitors the vCPU running thread. When the vCPU running thread is suspended, the Hypervisor performs a suspension process to resume the running of the vCPU running thread. The specific method is as follows:
[0026] S3.1: Determine whether the pause reason is an interrupt trigger. If yes, proceed to step S3.2; otherwise, proceed to step S3.5;
[0027] S3.2: Determine whether the current interrupt belongs to a virtual machine. If so, proceed to step S3.3; otherwise, proceed to step S3.4;
[0028] S3.3: The interrupt virtualization module in the Hypervisor performs virtual interrupt injection and then downgrades the current interrupt; proceed to step S3.9;
[0029] S3.4: Hypervisor calls the interrupt service routine belonging to its own interrupt; enter step S3.9;
[0030] S3.5: The Hypervisor reads and parses the values of the relevant registers to determine the specific type of the exception;
[0031] S3.6: Determine whether the current exception trigger can be processed in the Hypervisor microkernel. If so, proceed to step S3.7; otherwise, proceed to step S3.8;
[0032] S3.7: The Hypervisor completes exception handling in EL2 mode and then proceeds 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 the vCPU running thread;
[0035] 2) The Hypervisor writes the pause reason information of the vCPU running thread into the buffer shared by the vCPU processing thread user state and kernel state;
[0036] 3) The Hypervisor wakes up the vCPU processing thread, causing the current vCPU running thread to block and wait;
[0037] 4) The vCPU processing thread reads and parses the information about the pause reason of the vCPU running thread from the buffer shared by the user state and the kernel state, processes it in the EL0 mode, wakes up the corresponding vCPU running thread after the processing is completed, and the vCPU running thread joins the thread ready queue and waits to be scheduled;
[0038] 5) Hypervisor suspends the vCPU processing thread that has been processed;
[0039] S3.9: The Hypervisor restores the context of the vCPU running thread, and the vCPU running thread continues to execute.
[0040] The invention discloses a virtual machine suspension processing method of a microkernel Hypervisor based on ARM VHE. The microkernel Hypervisor based on ARM VHE is deployed, including a Hypervisor microkernel module, a Host OS service thread and a virtual machine user state management thread. 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 an EL0 / EL1 mode and a vCPU processing thread running in an EL0 mode. When the Hypervisor detects that the vCPU running thread is suspended, a corresponding processing operation is adopted according to the suspension triggering reason: if the current suspension reason belongs to an interrupt trigger or an abnormal 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 that the Host OS user state service needs to be called, 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 extension to build Type-2 Hypervisor running in EL2, runs only virtual machine kernel in EL1, and runs Hypervisor and user state services of virtual machine in EL0. By utilizing ARM VHE hardware virtualization extension, the overhead caused by abnormal state transition 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 pause processing, the present invention uses the design of separating vCPU running threads and vCPU processing threads to optimize the Hypervisor's processing of virtual machine interrupts and exceptions: (1) In terms of interrupt processing, the vCPU running thread in the present invention will be suspended when processing an interrupt and resumed after the processing is completed. The entire process only involves the saving and restoring of the virtual machine context, thus avoiding the overhead of saving and restoring the Hypervisor context in each VM ENTRY and VM EXIT, thereby shortening the interrupt processing time. (2) In terms of exception processing, the present invention efficiently handles exceptions that can be directly processed in EL2 mode, reduces the dependence on the Hypervisor context, and enables the vCPU running thread to quickly resume operation; for exceptions that cannot be directly processed in EL2, the Hypervisor will suspend the current vCPU running thread, write the suspension reason information, and wake up the vCPU processing thread, thereby optimizing the exception processing process. This design rationally utilizes CPU resources, avoids long-term resource monopoly by setting the priority of the vCPU processing thread higher than the vCPU running thread, and optimizes the service response time and system resource utilization efficiency through asynchronous processing support. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] Figure 1 It is a flow chart of a specific implementation method of a virtual machine suspension processing method of a microkernel Hypervisor based on ARM VHE of the present invention;
[0045] Figure 2 It is an architecture diagram of the microkernel Hypervisor based on ARM VHE in the present invention;
[0046] Figure 3 It is a working mode diagram of vCPU running thread and vCPU processing thread of the microkernel Hypervisor based on ARM VHE in the present invention;
[0047] Figure 4 This is a flow chart of the Hypervisor pausing the vCPU running thread in the present invention. DETAILED DESCRIPTION
[0048] The specific implementation of the present invention is described below in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be 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 1FIG. 1 is a flow chart of a specific implementation method of a virtual machine suspension processing method based on a microkernel Hypervisor of ARM VHE of the present invention. Figure 1 As shown, the virtual machine suspension processing method of the microkernel Hypervisor based on ARM VHE of the present invention includes the following steps:
[0051] S101: Configuring the ARM VHE-based microkernel hypervisor:
[0052] In order to optimize virtual machine interrupts, the present invention designs a Hypervisor architecture based on the ARM VHE microkernel, fully utilizes the hardware support provided by ARM VHE, and realizes a more reasonable Hypervisor component deployment. Figure 2 It is an architecture diagram of the microkernel Hypervisor based on ARM VHE in the present invention. Figure 3 : is a diagram of the working mode of the vCPU running thread and vCPU processing thread of the microkernel Hypervisor based on ARM VHE in the present invention. Figure 2 and Figure 3 As 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 mode management thread (VMM), and each module is described in detail below.
[0053] 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 (IPC), and address space management; the kernel virtualization extension module is used to support virtualization functions, including CPU virtualization module, memory virtualization module, clock virtualization module, interrupt virtualization module, and device virtualization module, among which:
[0054] 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 the code for running the virtual machine; the vCPU processing thread is responsible for processing the reason for the suspension of the vCPU running thread in the user state. The vCPU processing thread reads and parses the reason for the suspension of the vCPU running thread from the buffer shared by the user state and the kernel state, performs corresponding processing (for example, calling the service thread of the Host OS in EL0), and wakes up the corresponding vCPU running thread to resume operation after the processing is completed. This design only adds one Host OS thread context recovery like the ZVM-like design, and the present invention places the specific processing functions in the user state, reduces the kernel code, and maintains the advantages of the microkernel.
[0055] The interrupt virtualization module is used to support GICv3's interrupt management of virtual machines, 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. Maintenance interrupt design.
[0056] The memory virtualization module is used to use the two-stage address translation mechanism provided by the ARM architecture to perform physical address and virtual address translation to ensure address isolation between the virtual machine and the Hypervisor. The specific implementation method of physical address and virtual address translation in this embodiment is as follows:
[0057] (1) In EL0 mode, the root service rooterver of the Host OS service thread applies for a memory area of a specified size in user mode, and reversely parses the corresponding host physical address HPA 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 EL0 mode, the kernel is entered through a system call, and the IPA and HPA as well as the corresponding memory attribute information are passed to the kernel, and the kernel completes the second stage mapping of memory virtualization.
[0060] The clock virtualization module is used to use the virtual clock in EL1 mode to perform time management and time isolation on the client operating system. The specific method of time management and clock isolation in this embodiment is: the access of the virtual machine's physical clock in EL1 mode is captured to EL2, the corresponding virtual clock register is located according to the accessed physical clock code, and the simulation of the virtual machine reading and writing the physical clock register is completed by reading and writing the virtual clock register.
[0061] The device virtualization module is used to create virtual versions of computer hardware devices to abstract and share 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-mode services for the host machine.
[0063] The virtual machine user mode management thread runs in the main core of the Host OS service thread, which also runs in EL0 mode. It is responsible for virtual machine-level control, mainly including the creation, suspension, resumption and deletion of virtual machines.
[0064] S102: Deploy virtual machines:
[0065] In the present invention, the Hypervisor realizes the automatic deployment of the virtual machine through the shell command. After the virtual machine is running, the virtual machine kernel operates at the EL1 privilege level, and the application program inside the virtual machine is executed at the EL0 user level. When a specific sensitive instruction is executed or an abnormal access occurs, the system will switch to the EL2 mode, and the Hypervisor will perform corresponding processing.
[0066] S103: Suspend processing:
[0067] The Hypervisor monitors the vCPU running thread. When the vCPU running thread is suspended, the Hypervisor performs a suspension process to resume the running of the vCPU running thread. Figure 4 FIG. 1 is a flow chart of the Hypervisor suspending the vCPU running thread in the present invention. Figure 4 As shown, the specific method for the Hypervisor in the present invention to suspend the vCPU running thread is as follows:
[0068] S401: Determine whether the pause reason is an interrupt trigger, if yes, go to step S402, otherwise go to step S405.
[0069] S402: Determine whether the current interrupt belongs to a virtual machine, if so, proceed to step S403, otherwise proceed to step S404.
[0070] S403: Virtual interrupt injection:
[0071] The interrupt virtualization module in the Hypervisor performs virtual interrupt injection and then downgrades the current interrupt. The process proceeds to step S409.
[0072] S404: Hypervisor interrupt processing:
[0073] The Hypervisor calls the interrupt service routine belonging to its own interrupt, and then proceeds to step S409.
[0074] S405: Analysis suspension reason:
[0075] After research, it was found that the reasons for the exception triggering of the vCPU running thread suspension other than the interrupt triggering mainly include sensitive instruction exception capture (HVC32, HVC64, SMC32 and SMC64, etc.), DATA ABORT exception capture (such as second-stage memory access error) and sensitive register access exception capture (such as virtual machine access to the physical clock register under EL1), etc. Different exception triggers are handled differently. When an exception is triggered, the values of related 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 processed in the Hypervisor microkernel. If so, proceed to step S407; otherwise, proceed to step S408.
[0077] S407: Hypervisor exception handling:
[0078] The Hypervisor completes exception processing in EL2 mode and then proceeds to step S409.
[0079] The specific processing methods for different types of exception triggers may be different. Taking GICD access simulation as an example, the Hypervisor reads and writes the structure information storing the virtual interrupt according to the type and method of the GICD register accessed by the virtual machine. If it is a write operation, the corresponding hardware register may be modified, and then the context of the vCPU running thread is restored, and the vCPU running thread continues to execute. This process is similar to the case of virtual interrupt injection, which reduces the preservation and restoration of Hypervisor-related context information.
[0080] S408: Calling vCPU processing thread:
[0081] If the current exception type cannot be directly processed in the microkernel (for example, it is necessary to call the host OS driver at EL0 or other service threads of the host OS), then it is necessary to call the vCPU processing thread for processing. 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 vCPU processing thread user state and kernel state;
[0084] 3) The Hypervisor wakes up the vCPU processing thread, causing the current vCPU running thread to block and wait;
[0085] 4) The vCPU processing thread reads and parses the information about the pause reason of the vCPU running thread from the buffer shared by the user state and the kernel state, processes it in the EL0 mode, wakes up the corresponding vCPU running thread after the processing is completed, and the vCPU running thread joins the thread ready queue and waits to be scheduled;
[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 where the vCPU processing thread runs for a long time and monopolizes CPU resources due to the suspension of a specific vCPU running thread, resulting in all other vCPU running threads on the same CPU physical core being unable to be scheduled to run, this embodiment also proposes the following optimization scheme for the vCPU processing thread:
[0088] Determine the method for handling the pause reason of the vCPU processing thread based on the number of time slices required by the 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 uses a synchronous method to handle the reason for the suspension of the vCPU running thread. 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 service takes a short time to complete, the synchronous processing method is used, 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 the preset threshold, the vCPU processing thread handles the reason for the suspension of the vCPU running thread in an asynchronous manner. The specific method is: the vCPU processing thread registers a callback function for 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 executed in rounds 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 in the corresponding callback function.
[0091] S409: Resume operation:
[0092] The Hypervisor restores the context of the vCPU running thread, and the vCPU running thread continues to execute.
[0093] It should be noted here that in the conventional ARM architecture virtual machine interrupt processing method, whether it is GICv2 or GICv3, all interrupts need to be routed to EL2 and processed by the Hypervisor, the vCPU running thread will suspend running, and the Hypervisor will determine whether the current interrupt belongs to the Hypervisor or the virtual machine, and then perform Hypervisor interrupt processing and virtual interrupt injection respectively. After the processing is completed, the vCPU running thread resumes running. That is to say, each interrupt triggering will involve the suspension and resumption of the vCPU running thread, which also includes the preservation and restoration of the vCPU thread context. According to the above process, it can be seen that the vCPU thread under the architecture of the present invention only contains the context of the virtual machine operation, so in the interrupt processing scenario, compared with the vCPU thread design such as ZVM, the Hypervisor context recovery is reduced when the virtual machine exits, and the Hypervisor context preservation is reduced before the virtual machine enters.
[0094] Although the above describes the illustrative specific embodiments of the present invention to facilitate those skilled in the art to understand the present invention, 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, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations using the concept of the present invention are protected.
Claims
1. A virtual machine suspension processing method for a microkernel Hypervisor based on ARM VHE, characterized in that: The following steps are involved: S1: Deploy the ARM VHE-based microkernel Hypervisor in the microkernel, including the Hypervisor microkernel module, Host OS service thread, and virtual machine user state 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 to support virtualization functions, including CPU virtualization module, memory virtualization module, clock virtualization module, interrupt virtualization module, and device virtualization module, among which: The CPU virtualization module includes vCPU running threads and vCPU processing threads. The priority of vCPU processing threads is higher than that of 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. The vCPU running thread is responsible for saving the context related to the virtual machine and the code for running the virtual machine. The vCPU processing thread is responsible for processing the suspension reason of the vCPU running thread in user mode. The interrupt virtualization module is used to support GICv3's interrupt management of virtual machines; The memory virtualization module is used to use the two-stage address translation mechanism provided by the ARM architecture to translate physical addresses and virtual addresses to ensure address isolation between the virtual machine and the Hypervisor; The clock virtualization module is used to use the virtual clock in EL1 mode to perform time management and time isolation on the client operating system; The device virtualization module is used to create virtual versions of computer hardware devices to achieve abstraction and sharing of physical resources; The Host OS service thread runs in EL0 mode and is used to provide user-mode services to the host machine. The virtual machine user state management thread runs in the main core of the Host OS service thread and is responsible for virtual machine level control; S2: Hypervisor automatically deploys virtual machines through shell commands. After the virtual machine is running, the virtual machine kernel operates at the EL1 privilege level, while the application program inside the virtual machine is executed at the EL0 user level. When a specific sensitive instruction is executed or an abnormal access occurs, the system will switch to EL2 mode and the Hypervisor will handle it accordingly. S3: The Hypervisor monitors the vCPU running thread. When the vCPU running thread is suspended, the Hypervisor performs a suspension process to resume the running of the vCPU running thread. The specific method is as follows: S3.1: Determine whether the pause reason is an interrupt trigger. If yes, proceed to step S3.2; otherwise, proceed to step S3.5; S3.2: Determine whether the current interrupt belongs to a virtual machine. If so, proceed to step S3.3; otherwise, proceed to step S3.4; S3.3: The interrupt virtualization module in the Hypervisor performs virtual interrupt injection and then downgrades the current interrupt; proceed to step S3.9; S3.4: Hypervisor calls the interrupt service routine belonging to its own interrupt; enter step S3.9; S3.5: The Hypervisor reads and parses the value of the exception trigger-related register 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, proceed to step S3.7; otherwise, proceed to step S3.8; S3.7: The Hypervisor completes exception handling in EL2 mode and then proceeds 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 vCPU processing thread user state and kernel state; 3) The Hypervisor wakes up the vCPU processing thread, causing the current vCPU running thread to block and wait; 4) The vCPU processing thread reads and parses the information about the pause reason of the vCPU running thread from the buffer shared by the user state and the kernel state, processes it in the EL0 mode, wakes up the corresponding vCPU running thread after the processing is completed, and the vCPU running thread joins the thread ready queue and waits to be scheduled; 5) 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 converting the physical address and the virtual address in step S1 is as follows: (1) In EL0 mode, the root service rooterver of the Host OS service thread applies for a memory area of a specified size in user mode, and reversely parses the corresponding host physical address HPA as the memory area of the virtual machine; (2) Parse the intermediate physical address IPA of each device / memory in the virtual machine configuration file; (3) In EL0 mode, the kernel is entered through a system call, and the IPA and HPA as well as the corresponding memory attribute information are passed 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, characterized in that: The specific method of time management and clock isolation in step S1 is: capturing the access of the virtual machine's physical clock in EL1 mode to EL2, locating the corresponding virtual clock register according to the accessed physical clock code, and completing the simulation of the virtual machine reading and writing the physical clock register by reading and writing the virtual clock register.
4. The virtual machine suspension processing method according to claim 1, characterized in that: In step S3, the method for handling the suspension reason of the vCPU processing thread is determined according to the number of time slices required to be provided by the Host OS service thread, and the specific method is: 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 uses a synchronous method to handle the suspension reason of the vCPU running thread. 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 the preset threshold, the vCPU processing thread handles the reason for the suspension of the vCPU running thread in an asynchronous manner. The specific method is: the vCPU processing thread registers a callback function for 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 executed in rounds 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 in 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
Cited By
Audio virtualization method based on microkernel
CN120669951A
Lightweight virtualized VirtIO model implementation method, device and equipment
CN122220033A