HyperVHE virtual machine system and method based on ZVM

Abstract

The invention relates to the technical field of virtual machines, and particularly discloses a HyperVHE virtual machine system based on a ZVM, which runs on an ARM processor and comprises a host operating system running at an EL2 privilege level; the ZVM runs at an EL2 privilege level, cooperatively runs with the host operating system at the same level, shares control authority, and realizes distribution and management of resources and interrupts through a predefined interface; the at least one guest operating system runs at an EL1 privilege level, and access control, memory isolation and interrupt forwarding of the guest operating system are taken over by the ZVM; wherein the kernel of the host operating system is subjected to EL2 privilege level transformation. By adopting the technical scheme of the invention, the system can run in an ARMv8.0 architecture, and has the advantages of higher real-time performance and light weight.

Description

Technical Field

[0001] This invention relates to the field of virtual machine technology, and in particular to a HyperVHE virtual machine system and method based on ZVM. Background Technology

[0002] With the advancement of heterogeneous computing and multi-system collaboration, deploying multiple operating systems in embedded devices to separate real-time and non-real-time tasks has become an important trend. ZVM (Zephyr Virtual Machine), as a lightweight virtualization platform, supports deploying Zephyr and Linux systems in different virtual environments to improve task isolation and system scalability.

[0003] Currently, ZVM implements virtualization management and context switching based on the VHE (Virtualization Host Extensions) mechanism under the ARM64 architecture, offering advantages such as low interrupt latency and high resource isolation, making it suitable for high-performance embedded devices. However, the VHE mode has high hardware platform requirements, only supporting ARMv8.2 and later processors, preventing ZVM from running properly on older ARMv8.0 architectures (such as Cortex-A53). This limitation severely restricts the deployment scope of ZVM in practical embedded applications, specifically causing the following problems: Compatibility issues between HyperVHE virtualization and ZVM: The existing ZVM virtualization mechanism relies on the VHE feature supported by ARMv8.2 and above architectures. This feature redirects some EL1 register accesses to EL2 register accesses, allowing the host operating system to run at the EL2 virtualization level, simplifying exception management and permission switching processes. Therefore, ZVM cannot be deployed and run on ARM processors based on the ARMv8.0 architecture (such as Cortex-A53).

[0004] Traditional nVHE support, such as Linux-KVM, uses EL1 layer for the host OS and EL2 layer for the KVM virtual machine, resulting in privilege level switching during interaction; KVM is a Type 2 virtual machine. ZVM, on the other hand, is a bare-metal Type 1 hard real-time hypervisor, employing an integrated architecture of "RTOS kernel + native virtualization." It provides strong isolation and determinism while reusing the Zephyr RTOS ecosystem to achieve Type 2 level drivers and extensions. Directly transplanting KVM's nVHE mode to ZVM would sacrifice ZVM's real-time performance, thus turning ZVM into a Type 2 virtual machine.

[0005] Issues with exception handling and access control in virtual machines: In VHE mode, the guest operating system (OS) can run directly at the EL1 privilege level. Through VHE features, the virtual machine hypervisor's access to registers can be routed from EL1 to EL2, resulting in a relatively simple exception handling process. However, in nVHE mode, the guest OS runs in EL1, while the virtual machine hypervisor runs in EL2. All exceptions must be handled by jumping from EL1 to EL2, posing a risk of system instability or security vulnerabilities due to conflicting access permissions.

[0006] Context switching and state synchronization issues in virtual machines: ZVM's original context switching mechanism relies on the simplified EL1 / EL2 switching path of VHE. However, in nVHE mode, more critical registers (such as SPSR_EL1, ELR_EL1, SP_EL0 / 1, etc.) need to be manually saved and restored, and a complete CPU state switch needs to be implemented. Especially when the guest OS is running, the running states of the Guest and Host must be accurately saved to ensure that instruction streams are not lost, stack pointers are not disordered, and system behavior remains consistent during the switching process. The lack of complete context switching support will severely affect the stability of multi-system collaborative operation.

[0007] Memory management and security isolation issues in the host OS: Under the VHE architecture, Stage-1 and Stage-2 page tables can easily achieve memory isolation. However, under nVHE, it is also necessary to ensure complete isolation between Zephyr and guest OSes such as Linux in terms of physical memory access. Furthermore, it is essential to ensure that mechanisms such as TLB refresh and consistency maintenance in nVHE mode comply with the hardware constraints of ARMv8.0 to guarantee system security and prevent memory leaks and unauthorized access.

[0008] Therefore, there is a need for a ZVM-based HyperVHE virtual machine system and method that can run on the ARMv8.0 architecture and has advantages in real-time performance and lightweight design. Summary of the Invention

[0009] One of the objectives of this invention is to provide a HyperVHE virtual machine system based on ZVM, which can run on the ARMv8.0 architecture and has advantages in real-time performance and lightweight design.

[0010] To solve the above-mentioned technical problems, this application provides the following technical solution: A HyperVHE virtual machine system based on ZVM, running on an ARM processor, includes: The host operating system runs at EL2 privilege level; ZVM virtual machine runs at the EL2 privilege level, cooperating with the host operating system at the same level, sharing control permissions, and distributing and managing resources and interrupts through predefined interfaces; At least one guest operating system, running at the EL1 privilege level, has its access control, memory isolation, and interrupt forwarding handled by the ZVM virtual machine; The kernel of the host operating system has been modified to the EL2 privilege level.

[0011] Furthermore, the EL2 privilege level modification of the host operating system includes: During the initialization of the host operating system, the system registers at the EL2 level are initialized and configured. The system registers include at least the HCR_EL2 register, SP_EL2 register, SPSR_EL2 register, and SCTLR_EL2 register. Specifically, the VHE bit of the HCR_EL2 register is not written, and initialization logic for the SP_EL2 register, SPSR_EL2 register, and SCTLR_EL2 register is added to skip the dependency on the VHE feature.

[0012] Furthermore, the modification of the host operating system's EL2 privilege level also includes: Add EL2 level processing logic to the interrupt and exception handling of the host operating system. The system registers also include the ELR_EL2 register. Add reading logic for the SPSR_EL2 register and the ELR_EL2 register and related processing function jump logic. It also includes the interrupt controller and adds EL2 level initialization logic for the interrupt controller. Make the EL2 level responsible for intercepting and initially processing interrupt and exception events from the EL1 level, and transfer control to the host operating system.

[0013] Furthermore, the EL2 privilege level modification of the host operating system also includes: adding a control flow for initializing the memory-mapped environment at the EL2 level, adding the function enable_mmu_el2 to the control flow, and uniformly configuring the system registers involved in the EL2 level, including the MAIR_EL2 register, TCR_EL2 register, and TTBR0_EL2 register; Specifically, the MAIR_EL2 register is written to define the access attributes of different types of memory regions; the TCR_EL2 register is set to determine the page table granularity, caching strategy, and virtual address space size for EL2 level address translation; and the base address of the first-level page table is written to the TTBR0_EL2 register to establish the virtual-to-physical mapping relationship of the EL2 level's own address space. Modify the relevant control bits in the SCTLR_EL2 register to enable the EL2-level memory management unit function.

[0014] Furthermore, it also includes adding logic for saving and restoring the register states between EL1 and EL2 levels in the thread switching process of the guest operating system, specifically including: When saving the guest operating system thread context, the state of the timer registers that the current thread depends on is archived; the system registers also include the SCTLR_EL1 register, TTBR0_EL1 register, and ELR_EL1 register. During the saving of the system-level status registers, save and load operations are added for the SCTLR_EL1 register, TTBR0_EL1 register, and ELR_EL1 register.

[0015] Furthermore, it also includes building an interrupt and exception vector table mechanism for the guest operating system at the EL2 layer; the vector table covers the entry addresses of common exception types, including synchronous exceptions, interrupt requests, fast interrupts, and system errors; each exception type corresponds to a unique entry processing function in the vector table. This function first performs a preliminary analysis of the exception context at the EL1 level, and selects the exception handling path at the EL2 level based on the identity of the current guest operating system and its page table mapping status, thus completing the dynamic forwarding of the exception and the switching of control.

[0016] The second objective of this invention is to provide a HyperVHE virtual machine method based on ZVM, which, using the aforementioned system, includes the following aspects in the interaction process and task scheduling: Interrupt exception handling steps: When an exception or interrupt request occurs in the guest operating system, the process jumps from the EL1 level to the EL2 level where the ZVM virtual machine is located, and the ZVM virtual machine takes over exception management. ZVM virtual machines selectively forward interrupts to the target guest operating system based on the current guest operating system state through interrupt vector identification and state determination; Context switching steps: Each time the guest operating system is switched, the ZVM virtual machine completely saves the current virtual machine's register state and loads the guest operating system's context information; Memory access isolation control steps: ZVM virtual machines reconfigure the physical address mapping range of each guest operating system based on the Stage-2 page table management mechanism, so that it can only access the authorized memory space.

[0017] This solution modifies the host operating system of the embedded real-time virtual machine at the EL2 level, enabling it to run at the EL2 privilege level. This avoids the context overhead caused by frequent switching between the host operating system and the hypervisor in the original EL1 privileged mode. Thus, without relying on Arm VHE feature support, it achieves the goal of peer-to-peer operation and same-level interaction between the host operating system and the ZVM virtual machine, significantly reducing virtualization communication latency and enhancing the overall real-time response capability and execution determinism of the system. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the existing virtual machine system architecture; Figure 2 This is a schematic diagram of the architecture of a HyperVHE virtual machine system based on ZVM. Detailed Implementation

[0019] The following detailed description illustrates the specific implementation method: Example 1 Figure 1 This diagram illustrates a comparison of common virtual machine system architectures under different virtualization modes, including... Figure 1 (a) VHE mode and Figure 1 (b) nVHE mode corresponds to two deployment methods in the current mainstream ARMv8 virtualization architecture. Figure 1 It also illustrates the typical running locations of the virtual machine Hypervisor, host operating system (host OS), and guest operating system (guest OS) in each privilege level (EL0~EL2).

[0020] The deployment architecture of virtual machines in VHE (Virtualization Host Extensions) mode is as follows: Figure 1 As shown in (a). In this mode, the host operating system (host OS) runs on EL1, the virtual machine (Hypervisor) runs on the higher privilege level EL2, and the guest operating system (guest OS) runs in the EL1 virtualization context (typically labeled EL1 / EL0) via virtual CPUs (vCPUs). Because the VHE mode allows the host OS to access some registers of EL2 from within EL1, the host OS can run with almost native performance. The virtual machine is primarily responsible for the virtual resource management and interrupt forwarding of the guest OS.

[0021] The deployment architecture of virtual machines in nVHE (non-Virtualization Host Extensions) mode, such as Figure 1As shown in (b). In this mode, because the ArmV8.0 architecture processor does not support VHE features, the host OS runs at the EL1 privilege level, and the virtual machine runs at the EL2 privilege level. The guest OS still runs at EL1, and its access control, memory isolation, and interrupt forwarding are all handled by the virtual machine. This architecture is suitable for processors that do not support VHE, and the interaction between the host OS and the virtual machine involves cross-privilege level issues, which leads to increased overhead and greatly affects the real-time performance of the virtual machine system.

[0022] like Figure 2 As shown, this embodiment of a HyperVHE virtual machine system based on ZVM includes a ZVM virtual machine, a host operating system (host OS), and a guest operating system (guest OS). Both the host OS and the ZVM virtual machine run at the EL2 privilege level. The ZVM virtual machine and the host OS operate collaboratively at the same level, sharing control permissions and distributing and managing resources and interrupts through predefined interfaces. For example, the `vm_mem_domain_add()` interface function is used to allocate platform memory and device memory to the guest OS; the `vm_irq_enable()` interface function is used to register interrupts for the guest OS.

[0023] The guest OS runs on EL1, and its access control, memory isolation, and interrupt forwarding are all handled by the ZVM virtual machine.

[0024] This architecture is suitable for processors that do not support VHE, and HyperVHE can also support processors that do support VHE features. Furthermore, since the host OS and ZVM virtual machine both run at the same privilege level, their interaction does not involve cross-privilege level issues. Compared with traditional nVHE, this solution maintains virtualization capabilities while optimizing system response latency and resource management efficiency, resulting in higher real-time performance and lightweight advantages.

[0025] In response to the issue that the host OS cannot run directly in EL2 when the ARMv8.0 architecture does not support VHE, this solution modifies the host OS kernel to EL2, enabling it to run in EL2 privilege level that does not support VHE features in HyperVHE mode.

[0026] The main registers involved in the modification are shown in Table 1: Table 1. Main registers involved in the EL2 modification

[0027] The renovation mainly includes: During host OS initialization, the VHE bit of the HCR_EL2 register is not written. Instead, initialization logic for registers such as SP_EL2, SPSR_EL2, and SCTLR_EL2 is added (initializing the EL2 layer, referring to the characteristics of each register in the Arm manual, and writing values). This bypasses the dependency on VHE features, allowing the host OS to initialize and run normally in the EL2 privilege level without VHE support. The host OS's interrupt and exception handling is enhanced with EL2-level processing logic. This includes adding logic for reading registers such as SPSR_EL2 and ELR_EL2, and related function jumps. It also includes an interrupt controller with EL2-level initialization logic to ensure proper interrupt and exception handling at the EL2 level. In this logic, the EL2 level intercepts and performs preliminary processing of interrupts and exceptions from the EL1 level. When an interrupt or exception is outside the virtualization control scope and does not affect the virtualization framework's operational state, the EL2 level should transfer control to the host OS for normal processing. For example, peripheral interrupts (such as network cards and storage controllers) belong to physical devices managed by the host OS. To achieve this, an exception context saving and restoration mechanism is established at the EL2 level. By reading and processing the contents of key registers such as SPSR_EL2 and ELR_EL2, the correctness of the exception return path is ensured. Furthermore, to ensure that interrupts can be captured and scheduled promptly by the EL2 level in the virtualization environment, the Generic Interrupt Controller (GIC) is initialized at the EL2 level. This configuration ensures that interrupt events are correctly received and managed by the EL2 layer before entering the host operating system, thereby ensuring that the host system has complete and controllable interrupt and exception handling capabilities under virtualization conditions.

[0028] The host OS's MMU (Memory Management Unit) is modified to the EL2 privilege level to enable virtualization control support for the MMU. Specifically, a new control flow is added to initialize the memory-mapped environment at the EL2 level. This flow uses the `enable_mmu_el2` function to uniformly configure key system registers involved in EL2. The main functions of this function include: first, defining the access attributes of different types of memory regions (such as device memory and cache-coherent memory) by writing to the `MAIR_EL2` register; second, setting the `TCR_EL2` register to determine key parameters such as the page table granularity, caching strategy, and virtual address space size for EL2 address translation; and finally, writing the base address of the first-level page table to the `TTBR0_EL2` register to establish the virtual-to-physical mapping relationship of the EL2 level's own address space, supporting Stage-1 address translation. After completing the above configuration, the system officially enables the EL2-level MMU function by modifying the relevant control bits in the `SCTLR_EL2` register. Meanwhile, to ensure address translation consistency, a TLB refresh operation is introduced into this process to ensure that the address mapping results are effective in the hardware cache after the page table is updated.

[0029] As a lightweight hypervisor running at the EL2 level, ZVM virtual machine needs to be adapted for the scheduling, isolation, and management of guest OSs in HyperVHE mode. Therefore, this embodiment modifies the ZVM virtual machine's guest OS context switching and guest OS interrupt management using HyperVHE features.

[0030] The main registers involved in this modification are shown in Table 2: Table 2. Major Registers Involved in ZVM Modification

[0031] The renovation specifically includes: Add register saving and loading logic in HyperVHE mode to the relevant functions of guest OS thread context switching. When running the guest OS in HyperVHE mode, to implement a complete thread context switching and exception recovery mechanism, add logic for saving and restoring the state of key registers between EL1 and EL2 levels to the thread switching process of the guest OS. Detailed logic includes: when saving the guest OS thread context, archiving the states of timer registers that the current thread depends on (such as CNTV_TVAL_EL0, CNTV_CVAL_EL0, CNTP_TVAL_EL0, CNTP_CVAL_EL0, etc.) for accurate restoration of time states in subsequent scheduling; simultaneously, during the saving of system-level status registers, add save and load operations for SCTLR_EL1 (system control register), TTBR0_EL1 (page table base address register), and ELR_EL1 (exception return address). These operations ensure that in multi-threaded scheduling, task migration, or exception return scenarios, the guest OS thread can achieve semantically complete and context-consistent switching under EL2 control.

[0032] Furthermore, to achieve unified management and precise distribution of guest OS interrupts and exceptions at the EL2 layer, the system constructs a dedicated interrupt and exception vector table mechanism for guest OS at the EL2 layer. This vector table covers the entry addresses of common exception types, including four exception sources: Synchronous Exception, IRQ (Interrupt Request), FIQ (Fast Interrupt), and SError (System Error). Each type of exception corresponds to a unique entry handling function in the vector table. This function first performs a preliminary analysis of the EL1 exception context and, based on the current guest OS identity (such as Zephyr or Linux) and its page table mapping state, selects an appropriate exception handling path at the EL2 layer, thereby completing the dynamic forwarding of the exception and the switch of control.

[0033] This embodiment also provides a HyperVHE virtual machine method based on ZVM. Using the above system, the interaction process and task scheduling include the following: Interruption exception handling steps: When an exception or interruption request occurs in the Zephyr or Linux guest OS, the process jumps from the EL1 level to the EL2 level where the ZVM virtual machine resides, and the ZVM virtual machine takes over the exception management. ZVM virtual machines selectively forward interrupts to the target guest OS based on the current guest OS state through interrupt vector identification and status determination, avoiding permission disorder and interrupt chaos caused by EL1 sharing, and ensuring stable system operation.

[0034] Context switching steps: Each time the guest OS switches, the ZVM virtual machine fully saves the current virtual machine's register state (such as ELR_EL1, SPSR_EL1, SP_EL1, etc.) and loads the guest OS's context information to ensure the continuity of the execution flow during task switching. This mechanism supports high-frequency scheduling and switching of the guest OS, ensuring the continuity and security isolation of each task. Due to the characteristics of VHE, the host OS and ZVM virtual machine can access the corresponding XXX_EL2 / XXX_EL1 registers by accessing the XXX_EL1 / XXX_EL12 registers. Therefore, to add support for nVHE, it is necessary to modify the guest OS's context switching logic, add register state saving logic in nVHE mode, and strictly distinguish between EL2 and EL1 privileged registers.

[0035] Memory access isolation control steps: To avoid memory access conflicts between guest OSes, ZVM reconfigures the physical address mapping range of each guest OS based on the Stage-2 page table management mechanism, ensuring that it can only access authorized memory spaces. By precisely controlling TLB flushing and memory marking, unauthorized access is prevented, and memory read / write efficiency is improved, thus safeguarding system security and operational efficiency from the ground up. The host OS's MMU memory management module is modified to EL2, adding an mm_init initialization function at the EL2 privilege level and adding flush operation logic for the ttbr0 page table base address register at the EL2 layer.

[0036] This invention modifies the host OS of the embedded real-time virtual machine at the EL2 level, enabling it to run at the EL2 privilege level. This avoids the context overhead caused by frequent switching between the host OS and the Hypervisor in the original EL1 privilege mode. Thus, without relying on Arm VHE feature support, it achieves the goal of equal operation and same-level interaction between the host OS and the virtual machine, significantly reducing virtualization communication latency and enhancing the overall real-time response capability and execution determinism of the system.

[0037] In contrast, while traditional virtualization architectures using the VHE (Virtualization Privilege Extension) mechanism simplify virtualization context switching, they are limited by hardware dependencies and cannot be deployed on processors below Armv8.2 that do not support VHE features, severely restricting their applicability on domestic embedded platforms such as the Phytium E2000 / D2000. Furthermore, in the Type 1 virtualization architecture using the traditional nVHE mechanism, the Hypervisor and the host OS belong to the EL2 and EL1 privilege levels respectively. Every interaction between the virtual machine and the host involves a privilege level switch and related system register state recovery operations, resulting in significant performance bottlenecks and interrupt latency.

[0038] The novel HyperVHE virtualization mechanism adopted in this invention, which is applicable to the ZVM "RTOS kernel + native virtualization" integrated architecture, reconstructs the privileged level operation mode of the host OS under the ZVM architecture, thereby eliminating the need for VHE feature support, reducing privilege translation, and achieving both high real-time performance and good platform compatibility.

[0039] This invention also reconstructs the core virtualization components in ZVM (such as interrupt control, memory mapping, virtual device management, etc.) using HyperVHE to ensure that the ZVM virtual machine can cooperate equally with the host OS and maintain the integrity of virtualization capabilities while running at the EL2 layer.

[0040] One of the key functional requirements of virtual machines is device virtualization (virtual device management). In contrast, in traditional nVHE virtualization solutions, due to the different privilege levels of the virtual machine and the host OS, whether it is full virtualization or a paravirtualization mechanism like virtIO, the virtual machine needs to access host driver resources through EL1 / EL2 cross-level interaction. This process involves a large number of privilege level switches and system context state saving and restoration, which directly leads to increased interrupt injection latency, reduced I / O throughput, and ultimately affects the overall real-time responsiveness and execution efficiency of the system.

[0041] This invention achieves a new HyperVHE virtualization mechanism by modifying and optimizing the virtualization mechanism of the ZVM virtual machine using HyperVHE, combined with the EL2 modification and optimization of the host OS. This improves interrupt, memory, and device responsiveness in HyperVHE mode while retaining the native advantages of the ZVM architecture in supporting flexible device modeling and driver reuse, ultimately forming a lightweight virtualization solution that combines real-time performance, flexibility, and broad adaptability.

[0042] The above are merely embodiments of the present invention. The invention is not limited to the fields covered by these embodiments. Commonly known structures and characteristics in the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are able to access all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A ZVM-based Hyper-V HE virtual machine system running on an ARM processor, characterized in that, Comprise: a host operating system running at EL2 privilege level; a ZVM virtual machine running at EL2 privilege level, co-operating with the host operating system at the same privilege level, sharing control authority, and realizing distribution and management of resources and interrupts through a predefined interface; at least one guest operating system running at EL1 privilege level, whose access control, memory isolation and interrupt forwarding are taken over by the ZVM virtual machine; wherein the kernel of the host operating system is modified at EL2 privilege level.

2. The ZVM-based Hyper-V HE virtual machine system of claim 1, wherein: The modification of the host operating system at EL2 privilege level comprises: when the host operating system is initialized, the system registers at EL2 level are initialized and configured, including at least HCR_EL2 register, SP_EL2 register, SPSR_EL2 register, SCTLR_EL2 register; wherein the VHE bit of the HCR_EL2 register is not written, and at the same time, the initialization logic of the SP_EL2 register, SPSR_EL2 register and SCTLR_EL2 register is added, and the dependence on VHE feature is skipped.

3. The ZVM-based Hyper-V HE virtual machine system of claim 2, wherein: The modification of the host operating system at EL2 privilege level further comprises: EL2 level processing logic is added in the interrupt and exception handling of the host operating system, the system registers further include ELR_EL2 register, and the reading of the SPSR_EL2 register and ELR_EL2 register and the related processing function jump logic are added; an interrupt controller is further included, and EL2 layer initialization logic of the interrupt controller is added; the EL2 level is responsible for intercepting and preliminarily processing the interrupt and exception events from the EL1 level, and transferring the control right to the host operating system.

4. The ZVM-based Hyper-V HE virtual machine system of claim 3, wherein: The modification of the host operating system at EL2 privilege level further comprises: adding a control flow for initializing the memory mapping environment at the EL2 level, the control flow adds the function of enable_mmu_el2, and uniformly configures the system registers related to the EL2 level, including MAIR_EL2 register, TCR_EL2 register, TTBR0_EL2 register; wherein the MAIR_EL2 register is written to define the access attributes of different types of memory regions; the TCR_EL2 register is set to determine the page table granularity, cache strategy and virtual address space size of the EL2 level address translation; the base address of the first level page table is written to the TTBR0_EL2 register to establish the virtual-to-physical mapping relationship of the EL2 level itself address space; the related control bits in the SCTLR_EL2 register are modified to enable the memory management unit function of the EL2 level.

5. The ZVM-based Hyper-V HE virtual machine system of claim 4, wherein: Further comprising adding saving and restoring logic for the register state between the EL1 level and the EL2 level in the thread switching related flow of the guest operating system, specifically comprising: In saving the context of the customer operating system thread, the timer register state relied on by the current thread is archived; the system registers also include the SCTLR_EL1 register, the TTBR0_EL1 register, and the ELR_EL1 register, and the saving and loading operations of the SCTLR_EL1 register, the TTBR0_EL1 register, and the ELR_EL1 register are added in the saving process of the system-level state registers.

6. The ZVM-based Hyper-V HE virtual machine system of claim 5, wherein: A customer operating system-oriented interrupt and exception vector table mechanism is also constructed at the EL2 level; the vector table covers the entry addresses of common exception types, including synchronous exceptions, interrupt requests, fast interrupts, and system errors; each type of exception type corresponds to a unique entry processing function in the vector table, which first completes preliminary analysis of the EL1 level exception context, and selects an exception processing path at the EL2 level according to the identity of the current customer operating system and its page table mapping state, to complete dynamic forwarding and control right switching of the exception.

7. A method of ZVM-based Hyper-V HE virtualization using the system as claimed in any one of claims 1 to 6, characterized by, In the interaction process and task scheduling, the following contents are included: An interrupt exception processing step: when an exception or interrupt request occurs in the customer operating system, jump from the EL1 level to the EL2 level where the ZVM virtual machine is located, and the ZVM virtual machine takes over the exception management; The ZVM virtual machine selectively forwards the interrupt to the target customer operating system according to the current customer operating system state through interrupt vector identification and state determination; A context switching step: each time the customer operating system is switched, the ZVM virtual machine completely saves the register state of the current virtual machine and loads the context information of the customer operating system; A memory access isolation control step: the ZVM virtual machine reconfigures the physical address mapping range of each customer operating system based on the Stage-2 page table management mechanism, so that it can only access the authorized memory space.

Images