A zvm-based multi-client operating system uefi loading method

Abstract

The application relates to the technical field of virtual machines, and particularly discloses a multi-client operating system UEFI loading method based on a ZVM, which comprises the following steps: S1, a hardware power-on starting stage, after a device is powered on and started, the system enters an early initialization execution flow of UEFI firmware; S2, a UEFI firmware initialization stage, sequentially performing a SEC stage, a PEI stage, a DXE stage and a BDS stage, wherein the BDS stage enters a UEFI Shell to provide an interface for a client operating system; S3, a dynamic loading stage, after the BDS stage, the system reads PCD platform default parameters and user-set Shell parameters in the UEFI Shell, dynamically loads the client operating system according to the parameters, and loads the ZVM into the memory; S4, a running stage, exiting the UEFI environment, handing over the system control right to the ZVM, setting a PC pointer to point to a starting address of the ZVM, entering the ZVM, and loading and running a preset client operating system in the ZVM. The technical scheme of the application can realize dynamic and rapid loading of heterogeneous operating systems and elastic management of running period resources.

Description

Technical Field

[0001] This invention relates to the field of virtual machine technology, and in particular to a method for loading a multi-client operating system UEFI based on ZVM. Background Technology

[0002] Current methods for loading and running multiple operating systems in parallel on multi-core platforms primarily rely on bare-metal loading or non-virtualized architectures. These solutions typically load multiple operating systems directly into the physical address space, running at the EL1 level. They lack hardware-level isolation, cannot guarantee real-time scheduling, lack virtualization management capabilities for memory, interrupts, and peripherals, lack SMP support, and cannot dynamically adjust critical resources such as the number of CPU cores, memory size, and system peripheral parameters of the runtime operating system. Furthermore, they cannot modify system behavior through runtime policy inputs, resulting in complex deployment and maintenance, and poor scalability.

[0003] Current multi-operating system loading technologies for virtualization mostly focus on supporting general-purpose non-real-time systems (such as Linux / Android / Windows) based on the x86 architecture. For example, patent CN115599451A discloses a technology that relies on traditional virtual machine emulation frameworks such as QEMU. Its operation mode is mainly based on software-level complete system simulation of the BIOS / GRUB boot process, and it is highly dependent on the implementation of BIOS and SMM functions, making it difficult to support lightweight embedded real-time operating systems (such as Zephyr). In addition, most emulators such as QEMU are built in user space, making it difficult to directly schedule EL1 guest operating systems at the EL2 layer, resulting in unpredictable scheduling and a lack of operational control and resource guarantee capabilities for real-time operating systems.

[0004] On the other hand, domestic high-performance servers based on NUMA architecture + ARM64 platform, especially platforms such as Phytium S5000C, face scheduling pressures such as flexible core partitioning, uneven memory distribution, and mixed heterogeneous loads. Existing solutions cannot achieve dynamic loading, elastic creation, parallel operation of real-time operating system Zephyr and non-real-time operating system Linux, and can dynamically adjust system parameters.

[0005] Therefore, a solution is needed that supports dynamic loading, elastic creation, parallel execution of heterogeneous operating systems (Zephyr and Linux) and has the ability to dynamically configure resources at runtime. Summary of the Invention

[0006] This invention provides a method for loading UEFI of a multi-client operating system based on ZVM, which enables dynamic and rapid loading of heterogeneous operating systems and elastic management of runtime resources.

[0007] To solve the above-mentioned technical problems, this application provides the following technical solution: A method for loading UEFI into a multi-customer operating system based on ZVM includes the following steps: S1. Hardware power-on startup phase: After the device is powered on and started, the system enters the early initialization execution process of the UEFI firmware. S2, UEFI firmware initialization phase, sequentially executes SEC phase, PEI phase, DXE phase and BDS phase, among which BDS phase enters UEFI Shell, providing an interface for the guest operating system; S3. Dynamic loading stage: After the BDS stage, the system reads the default parameters of the PCD platform and the user-defined Shell parameters in the UEFI Shell, and dynamically loads the guest operating system and ZVM into memory according to the parameters. S4. During the running phase, exit the UEFI environment, transfer system control to ZVM, set the PC pointer to the starting address of ZVM, enter ZVM, and load and run the preset guest operating system in ZVM.

[0008] Furthermore, in step S2, during the SEC phase, the processor performs a reset and security verification; During the PEI phase, the motherboard initializes the memory / chipset; During the DXE stage, drivers are loaded, including PCI, USB, and storage drivers.

[0009] Furthermore, in step S3, the default parameters of the PCD platform and the user-defined Shell parameters include the client operating system information to be loaded; the client operating system includes Zephyr and / or Linux.

[0010] Furthermore, in step S3, the system loads and executes the boot module in the UEFI Shell. The boot module reads the default parameters of the PCD platform and the user-defined Shell parameters. The boot module loads the guest operating system and loads ZVM into memory according to the parameters.

[0011] Furthermore, in step S3, the boot module loads the guest operating system into a specified memory location at the EL3 level.

[0012] Furthermore, in step S4, ZVM reads the default parameters of the PCD platform and the user-defined Shell parameters after startup to determine whether to load Zephyr, Linux, or both simultaneously.

[0013] Furthermore, in step S4, ZVM runs at the EL2 level, while the guest operating system runs at the EL1 level.

[0014] This solution achieves flexible configuration of the boot strategy by reading the default parameters of the PCD platform and the user-defined shell parameters, and dynamically loading the guest operating system and ZVM according to the parameters. This allows the system to break free from the constraints of the traditional fixed boot order, enabling users to dynamically select different operating systems (such as Zephyr or Linux) based on real-time needs, thus significantly improving the flexibility of system deployment and application. This solution loads the guest operating system and ZVM into memory and transfers control to ZVM running at the EL2 level, where ZVM loads and runs the guest operating system at the EL1 level. This architecture, which prepares the image directly at the UEFI stage (EL3) and has the EL2-level ZVM uniformly manage the guest operating system, eliminates the intermediate step of the host operating system in traditional solutions, achieving a direct jump from firmware to the virtualization layer, effectively shortening the boot path and improving the overall loading and boot speed of the system. This solution uses ZVM to perform unified scheduling and resource management of multiple guest operating systems running at the EL1 level at the EL2 level. This ensures that the deterministic execution of real-time operating systems (such as Zephyr) is not affected by non-real-time tasks, while also achieving effective isolation and elastic allocation of resources between guest operating systems, thus enhancing the security and reliability of the system. Attached Figure Description

[0015] Figure 1 This is a flowchart of an embodiment of a ZVM-based multi-client operating system UEFI loading method; Figure 2 This is a schematic diagram of the software architecture of an embodiment of a ZVM-based multi-client operating system UEFI loading method. Detailed Implementation

[0016] The following detailed description illustrates the specific implementation method: Example 1 like Figure 1 and Figure 2 As shown in this embodiment, a method for loading a multi-client operating system UEFI based on ZVM includes the following steps: S1. Hardware power-on startup phase: After the device is powered on and started, the system first enters the early initialization execution process of the UEFI firmware.

[0017] The S2 and UEFI firmware initialization phases are divided into four main stages, including: During the SEC phase, the processor performs a reset and security verification. During the PEI phase, the motherboard initializes the memory / chipset; During the DXE stage, drivers are loaded, including PCI, USB, and storage drivers, etc. In the BDS stage, the system enters the UEFI Shell, providing an interface for the guest operating system BIOS.

[0018] S3. Dynamic loading stage: After the BDS stage, the system loads and executes the pre-selected boot module in the UEFI Shell. The boot module reads the PCD (Platform Configuration Database) platform default parameters and user-defined Shell parameters. The boot module loads the guest operating system and ZVM into memory according to the parameters.

[0019] The default parameters of the PCD platform and the user-defined shell parameters include information about the guest operating system that needs to be loaded, such as the real-time operating system Zephyr and / or the real-time operating system Linux image.

[0020] Leveraging the PCD mechanism and environment variable reading capabilities, this step allows for the pre-setting of specific parameters (PCD platform default parameters) via the PCD configuration file, or reading shell parameters via the UEFI Shell. This enables the dynamic selection of loading the real-time operating system Zephyr and / or the real-time operating system Linux image, rather than the traditional method of loading a single system in a fixed order. After the boot module starts, it first reads the PCD parameters set during compilation from its internal memory to establish a default boot plan. Next, it checks if the user has provided additional shell parameters via the command line. If the user provides a shell version for a parameter (e.g., -os=linux), the shell parameter has higher priority and overrides the corresponding default value in the PCD. If the user does not provide a shell version for a parameter, the system continues to use the default value in the PCD.

[0021] This embodiment also employs a redundant loading strategy and a preloading strategy. The redundant loading mechanism loads multiple guest operating system (guest operating system) images or device trees with different configurations during the loading phase. This allows ZVM to select different dynamically loaded guest operating systems after startup, enabling the loading and running of guest operating systems with different configurations. It also provides users with a certain degree of dynamic selection capability during operation.

[0022] Specifically, in step S3, the boot module loads the guest operating system according to the parameters and loads ZVM into memory. The guest operating system image is directly loaded into the specified memory location at the EL3 level, eliminating the step of the Hypervisor reading the guest operating system from the persistent device through the I / O interface in the EL2 stage, thereby speeding up the boot process and eliminating the Hypervisor's dependency on the persistent device driver.

[0023] S4. During the running phase, first exit the UEFI environment, transfer system control to the guest operating system, set the PC pointer to the starting address of ZVM, enter ZVM, and load and run the preset guest operating system in ZVM.

[0024] Specifically, ZVM reads the PCD platform's default parameters and the user-defined Shell parameters during the initial startup phase to determine whether to load Zephyr, Linux, or both.

[0025] During the loading process, ZVM does not rely on the image loading, parameter passing, or kernel entry jump functions provided by traditional bootloaders. Instead, it uses a custom-implemented UEFI image writing interface, leveraging UEFI's access to the FAT32 file system and its ability to read shell parameters to complete the pre-boot preparations for the operating system. This structure is more modular, facilitating debugging, customization, and cross-platform deployment.

[0026] In embedded systems with extremely high real-time requirements, developers can configure the system to enable only Zephyr during the build process, ensuring that the system can respond to interrupts and events with minimal latency. In complex application scenarios, such as multi-tasking concurrency, graphical user interfaces, and multi-protocol stack operation, developers can choose to load and run the Linux kernel, leveraging its mature software ecosystem and system service framework to support user-level operation. In more advanced hybrid architecture designs, if the device supports multiple cores, ZVM can run Zephyr on one core to handle real-time tasks and Linux on another core to handle non-real-time tasks. Both can collaborate to complete complex business logic, thus simultaneously achieving both real-time performance and system functionality.

[0027] This solution fully utilizes the Boot Manager capabilities provided by UEFI during the UEFI boot phase. Users can directly load and execute the boot module through the Shell in the UEFI Shell environment, thus eliminating the static control of the loading process by traditional bootloaders (such as GRUB or U-Boot). It also eliminates the need to manually maintain boot configuration files, disk partitions, or specific boot programs, and is closer to the modern system's concept of on-demand loading and multi-configuration operation.

[0028] Taking a domestically produced high-performance NUMA+ARM64 architecture server, such as Phytium S5000C, as an example, ZVM is introduced as the Hypervisor layer. After the UEFI environment in step S4, that is, after the UEFI stage is completed (EL3 level), the UEFI system relinquishes control and directly switches to running at the EL2 level.

[0029] Compared to the traditional approach that requires a Host OS (an operating system without virtualization technology) to act as an intermediate layer for the Hypervisor, in step S4, before entering ZVM, the system needs to first enter the EL1 layer from the EL3 layer, and then run from the EL1 layer to the EL2 layer after the Host OS starts the virtual machine. This approach shortens the boot path and improves loading speed.

[0030] This embodiment makes full use of the hardware-level isolation capabilities and hard real-time task scheduling capabilities provided by ZVM. Specifically, in step S4, ZVM immediately completes the necessary virtualization platform initialization operations after startup, including processor mode settings, enabling paging mechanism, kernel space mapping, etc.

[0031] Zephyr and Linux are loaded as guest operating systems onto designated NUMA nodes and run at the EL1 level. The running status of each guest operating system is uniformly scheduled and isolated by ZVM at the EL2 level, which effectively guarantees the execution priority and exclusive resource requirements of the real-time operating system, while ensuring that the non-real-time guest operating system does not interfere with the system response time.

[0032] ZVM, as a lightweight virtualization layer running at the EL2 level, uses hardware virtualization technologies (such as Stage-2 page tables and GIC virtualization) to achieve independent runtime space isolation and dynamic resource allocation for each guest operating system.

[0033] During system operation, ZVM supports dynamically adjusting the number of CPU cores, memory size, and peripheral system parameters of the guest operating system according to the task strategy during runtime, ensuring the determinism of real-time system operation and enhancing the overall system's task flexibility and platform adaptability.

[0034] This solution integrates a custom boot module into the standard UEFI boot chain, allowing manual startup via UEFI Shell commands. The boot module reads the boot policy configuration (such as NVRAM parameters), determines the type, number, and boot order of the guest operating systems to be loaded, and ultimately loads ZVM into memory. It then sets the PC pointer to the starting address of the ZVM load and enters the EL2 level, where system control is formally transferred to the Hypervisor layer. Unlike traditional GRUB and U-Boot static loading methods, this solution moves the control of operating system image loading to the EL2 level, managed uniformly by ZVM, significantly improving the decoupling and flexible management capabilities between guest operating systems.

[0035] After startup, ZVM runs at the EL2 privilege level. It first probes the underlying NUMA topology and binds its own scheduling domain to the specified NUMA node. ZVM constructs an independent virtual runtime context for each guest operating system instance, including: virtual CPU (vCPU) allocation and mapping; Stage-2 page table establishment to isolate physical address access permissions; a virtual interrupt controller (VGIC) injection mechanism to support Trap interrupt management; and a virtual device model and I / O MMIO forwarding interface.

[0036] Zephyr and Linux are loaded independently as guest operating systems in the virtual EL1 layer, each running in an independent address space, vCPU mapping, and I / O channel. When ZVM encounters sensitive instructions from the guest operating system (such as system register access, WFI, etc.), it triggers an exception trap, and performs scheduling behaviors such as interrupt arbitration, preemption, and clock synchronization at the EL2 layer, thereby ensuring the determinism of real-time task execution while maintaining low latency.

[0037] This solution provides a unified on-demand loading mechanism for guest operating systems, supporting the dynamic determination of the combination of operating systems to be loaded through startup parameters or configuration policies. For example, in industrial scenarios, only Zephyr can be loaded to handle low-latency real-time tasks; while in compute-intensive services, Linux can be loaded to run complex services.

[0038] This solution also employs a redundant loading mechanism, which loads multiple Zephyr images and Linux device trees with different configurations, allowing ZVM to dynamically select the number of CPU cores, memory size, and system peripheral parameters of the guest operating system during runtime, providing the hypervisor with highly flexible options.

[0039] This solution also employs a pre-loading mechanism, whereby the boot module (an EFI application based on UEFI) directly loads all core components of the guest operating system, including the kernel image, device tree (DTB), and root file system (initramfs), into a specified memory address before ZVM starts, instead of reading and loading from the virtual disk image or physical hard drive after startup as in traditional virtual machine solutions. This method completely avoids the simulation overhead and interrupt trapping process in virtual I / O, improving boot efficiency and resource isolation granularity.

[0040] This solution is applicable to domestically produced high-performance server platforms (such as Phytium S5000C) that have ARMv8 architecture, support EL2 virtualization extension and NUMA topology. At the hardware level, it does not rely on new hardware components, but on the existing general server architecture, it achieves elastic loading of the operating system, runtime resource adjustment and real-time guarantee by configuring parameters such as existing processors, interrupt controllers and memory resources.

[0041] Example 2 This example illustrates the actual deployment process.

[0042] In actual deployment, developers first need to complete a series of preparatory work, including compiling various system components, organizing storage media, and configuring EFI boot files.

[0043] First, during the compilation phase, developers need to use a cross-compilation toolchain to build a ZVM (hypervisor) image for the target ARM platform. Due to the characteristics of the NUMA architecture, during the build process, it is necessary to select a CPU group and GICR (generic interrupt controller group) of a certain NUMA node and add the CPU node in the S5000C device tree of ZVM.

[0044] At the same time, corresponding image files need to be generated for each required operating system, such as the Linux kernel image and the Zephyr executable image. Furthermore, based on the requirements of different operating systems and the different system parameter configurations required for the same operating system, corresponding device tree files also need to be generated to ensure that the system can correctly identify and initialize hardware resources and dynamically select different configurations during the boot process. Meanwhile, to ensure that the operating system can boot and run normally, the necessary root file system should also be built in advance and kept consistent with the boot configuration of each operating system.

[0045] After compilation and building, these image files will be placed on the boot media. This media can be a USB mobile device, a SATA hard drive, an NVMe hard drive, or other persistent storage devices. The boot media must be formatted as FAT32.

[0046] Developers need to select the default boot source of the system's built-in UEFI Shell according to the target platform's boot order and disable the BIOS's built-in Secure Boot feature. The boot module program is then placed on this boot media. Users can enter the UEFI Shell and use the Shell command to directly load and run the ZVM boot program, and can also use command-line parameters.

[0047] In the Hypervisor boot module, ZVM first obtains the default loading strategy of the current system by reading the PCD platform default parameters configured in the dec file during compilation. Then, it reads command-line parameters and automatically executes the loading process of the corresponding system, including reading the kernel image, device tree, initialization parameters, etc. Finally, it exits the boot phase through the UEFI-provided interfaces such as ExitBootService, sets the PC pointer to the starting position of the ZVM code, and hands over control to ZVM to enter the EL2 level. Finally, the embedded real-time virtual machine ZVM enables the parallel execution of Zephyr and Linux.

[0048] This solution introduces ZVM as a hypervisor in the EL3-level boot architecture for the first time. It implements cross-layer boot logic from firmware to EL2 through a boot module, breaking the dependence of traditional bare-metal boot methods on static bootloaders such as GRUB / U-Boot. During the boot phase, the system automatically identifies and loads multiple heterogeneous operating system images through policy files or boot parameters, assigning each guest operating system independent runtime parameters (CPU count, memory size, device resources). ZVM then builds its virtual runtime context and boots it in parallel mode with unified scheduling. This mechanism is highly versatile and scalable, adaptable to various UEFI firmware implementations and ARM64+NUMA architecture server platforms, significantly reducing the complexity of multi-system deployment and integration.

[0049] This solution utilizes ZVM as an embedded real-time virtual machine running at the EL2 layer, supporting fine-grained control over guest operating system traps, virtual interrupts (VGIC), and Stage-2 address space access. It provides hardware-level interrupt isolation, affinity scheduling, and preemption priority mechanisms for Zephyr instances running at the EL1 layer, effectively eliminating interference from non-real-time tasks on the real-time response path. Through a NUMA node binding mechanism, Zephyr guests can be exclusively allocated to specific kernel / memory domains, ensuring low jitter and high determinism in task execution. Simultaneously, by implementing a preloading mechanism, the guest operating system is directly loaded into a specified memory location, eliminating the step of the virtual machine accessing persistent storage to read the image file via I / O interface after startup, thus accelerating startup speed. This capability is particularly suitable for server scenarios with strong constraints on system real-time performance, such as TSN networks, industrial control, and flight control.

[0050] This invention successfully verified on the Phytium S5000C, a domestic server based on the NUMA+ARM64 architecture, that this solution loads ZVM and runs 15 single-core guest operating systems or 7 multi-core guest operating systems with SMP enabled simultaneously. It constructs a mechanism for hardware-level isolation and hard real-time task guarantee of multiple heterogeneous guest operating systems. It realizes high real-time performance, multi-tasking, isolation and configurable operating system stack collaborative operation on domestic servers (such as Phytium S5000C), and provides a basic operating platform for next-generation intelligent manufacturing, edge cloud, industrial AI and other scenarios.

[0051] 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 method for loading UEFI into a multi-client operating system based on ZVM, characterized in that, Includes the following steps: S1. Hardware power-on startup phase: After the device is powered on and started, the system enters the early initialization execution process of the UEFI firmware. S2, UEFI firmware initialization phase, sequentially executes SEC phase, PEI phase, DXE phase and BDS phase, among which BDS phase enters UEFI Shell, providing an interface for the guest operating system; S3. Dynamic loading stage: After the BDS stage, the system reads the default parameters of the PCD platform and the user-defined Shell parameters in the UEFI Shell, and dynamically loads the guest operating system and ZVM into memory according to the parameters. S4. During the running phase, exit the UEFI environment, transfer system control to ZVM, set the PC pointer to the starting address of ZVM, enter ZVM, and load and run the preset guest operating system in ZVM.

2. The ZVM-based multi-client operating system UEFI loading method according to claim 1, characterized in that: In step S2, during the SEC phase, the processor performs a reset and security verification. During the PEI phase, the motherboard initializes the memory / chipset; During the DXE stage, drivers are loaded, including PCI, USB, and storage drivers.

3. The ZVM-based multi-client operating system UEFI loading method according to claim 1, characterized in that: In step S3, the default parameters of the PCD platform and the user-defined Shell parameters include the client operating system information to be loaded; the client operating system includes Zephyr and / or Linux.

4. The ZVM-based multi-client operating system UEFI loading method according to claim 3, characterized in that: In step S3, the system loads and executes the boot module in the UEFI Shell. The boot module reads the default parameters of the PCD platform and the shell parameters set by the user. The boot module loads the guest operating system and loads ZVM into memory according to the parameters.

5. The ZVM-based multi-client operating system UEFI loading method according to claim 4, characterized in that: In step S3, the boot module loads the guest operating system into a specified memory location at the EL3 level.

6. The ZVM-based multi-client operating system UEFI loading method according to claim 5, characterized in that: In step S4, ZVM reads the default parameters of the PCD platform and the user-defined Shell parameters after startup to determine whether to load Zephyr, Linux, or both.

7. The ZVM-based multi-client operating system UEFI loading method according to claim 6, characterized in that: In step S4, ZVM runs at the EL2 level, and the guest operating system runs at the EL1 level.

Images