Multi-client operating system UEFI loading method based on ZVM

Abstract

The invention relates to the technical field of virtual machines, and particularly discloses a multi-client operating system UEFI (Unified Extensible Firmware Interface) loading method based on a ZVM (zero virtual machine), which comprises the following steps: S1, in a hardware power-on starting stage, after equipment is powered on and started, a system enters an early initialization execution process of UEFI firmware; s2, in a UEFI firmware initialization stage, an SEC stage, a PEI stage, a DXE stage and a BDS stage are executed in sequence, and in the BDS stage, UEFI Shell is entered to provide an interface for a client operating system; s3, a dynamic loading stage: after the BDS stage, the system reads default parameters of a PCD platform and Shell parameters set by a user in the UEFI Shell, and dynamically loads a client operating system and a ZVM into a memory according to the parameters; and S4, in a running stage, quitting the UEFI environment, transferring the system control right to the ZVM, setting a PC pointer to point to an initial address of the ZVM, entering the ZVM, and loading and running a preset client operating system in the ZVM. By the adoption of the technical scheme, dynamic and rapid loading of the heterogeneous operating system and elastic management of resources in the running period can be achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtual machines, in particular to a multi-guest operating system UEFI loading method based on ZVM. BACKGROUND

[0002] Currently, the way to load multiple operating systems on a multi-core platform and run them in parallel mainly relies on bare-metal loading or non-virtualization architecture. This type of solution usually loads multiple operating systems directly into the physical address space and runs them at the EL1 level, lacks hardware-level isolation, cannot guarantee real-time scheduling, lacks virtualization management capabilities for memory, interrupts, and peripherals, lacks SMP support, and cannot dynamically adjust key resources such as the number of CPU cores, memory size, and system peripheral parameters of the running operating system. It cannot modify system behavior through runtime policy input, resulting in complex deployment and maintenance and poor scalability.

[0003] Existing virtualization-oriented multi-operating system loading technologies mostly focus on supporting general non-real-time systems (such as Linux / Android / Windows) on the x86 architecture. For example, patent CN115599451A discloses a solution that relies on traditional virtual machine simulation frameworks such as QEMU. Its running mode mainly involves software-level complete system simulation of the BIOS / GRUB startup process, and it highly depends on the functionality of BIOS and SMM, making it difficult to support lightweight embedded real-time operating systems (such as Zephyr). In addition, most simulators such as QEMU are built on the user side, making it difficult to directly schedule EL1 guest operating systems at the EL2 level, resulting in unpredictable scheduling and a lack of running control and resource guarantee capabilities for real-time operating systems.

[0004] On the other hand, on domestic high-performance servers based on NUMA architecture + ARM64 platforms, especially platforms such as Feiteng S5000C, there are scheduling pressures such as flexible core division, non-uniform memory distribution, and heterogeneous load mixing. Existing solutions cannot achieve dynamic loading, elastic creation, and parallel running of real-time operating systems Zephyr and non-real-time operating systems Linux, and cannot dynamically adjust system parameters.

[0005] Therefore, there is a need for a solution that supports dynamic loading, elastic creation, and parallel running of heterogeneous operating systems (Zephyr and Linux) and has runtime dynamic resource configuration capabilities. SUMMARY

[0006] The present application provides a multi-guest operating system UEFI loading method based on ZVM, which can achieve dynamic and fast loading of heterogeneous operating systems and elastic management of runtime resources.

[0007] To solve the above technical problems, the application provides the following technical solutions: A UEFI loading method of a multi-client operating system based on ZVM, comprising the following steps: S1, hardware power-on startup stage, after the device is powered on and started, the system enters the early initialization execution flow of the UEFI firmware; S2, UEFI firmware initialization stage, sequentially performing SEC stage, PEI stage, DXE stage and BDS stage, wherein the BDS stage enters the UEFI Shell to provide an interface for the client operating system; S3, dynamic loading stage, after the BDS stage, the system reads the PCD platform default parameters and the user-set Shell parameters in the UEFI Shell, and dynamically loads the client operating system and loads the ZVM into the memory according to the parameters; S4, running stage, exiting the UEFI environment, handing over the system control right to the ZVM, setting the PC pointer to point to the starting address of the ZVM, entering the ZVM, and loading and running the preset client operating system by the ZVM.

[0008] Further, in the step S2, the SEC stage, the processor performs reset and security verification; The PEI stage, the mainboard initializes the memory / chipset; The DXE stage, load the driver, the driver includes PCI, USB and storage.

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

[0010] Further, in the step S3, the system in the UEFI Shell loads an execution boot module, reads the PCD platform default parameters and the user-set Shell parameters through the boot module, and the boot module loads the client operating system and loads the ZVM into the memory according to the parameters.

[0011] Further, in the step S3, the boot module loads the client operating system to the specified location in the memory at the EL3 level.

[0012] Further, in the step S4, the ZVM reads the PCD platform default parameters and the user-set Shell parameters after starting to determine whether to load Zephyr, Linux or both subsequently.

[0013] Further, in the step S4, the ZVM runs at the EL2 level, and the client operating system runs at the EL1 level.

[0014] The scheme realizes flexible configuration of the starting strategy by reading the PCD platform default parameters and the user set Shell parameters and dynamically loading the customer operating system and the ZVM according to the parameters. The system can break away from the shackles of the traditional fixed starting sequence, and the user can dynamically select and load different operating systems (such as Zephyr or Linux) according to real-time requirements, thereby significantly improving the flexibility of system deployment and application. The scheme loads the customer operating system and the ZVM into the memory, and transfers the control right to the ZVM running at the EL2 level, and the ZVM loads and runs the customer operating system at the EL1 level. The architecture directly prepares the image in the UEFI stage (EL3) and uniformly manages the customer operating system by the ZVM at the EL2 level, which eliminates the intermediate link of the host operating system in the traditional scheme, realizes direct jump from the firmware to the virtualization layer, effectively shortens the starting path, and improves the loading and starting speed of the whole system. The scheme uniformly schedules and manages multiple customer operating systems running at the EL1 level by the ZVM at the EL2 level, ensures that the execution certainty of the real-time operating system (such as Zephyr) is not disturbed by non-real-time tasks, and at the same time realizes effective isolation and elastic allocation of resources among the customer operating systems, enhances the security and reliability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 A flowchart of a ZVM-based multi-customer operating system UEFI loading method embodiment one; Figure 2 A schematic diagram of the software architecture of the ZVM-based multi-customer operating system UEFI loading method embodiment one. DETAILED DESCRIPTION

[0016] The following will be further described in detail through specific embodiments: Embodiment one As shown in Figure 1 and Figure 2 , the ZVM-based multi-customer operating system UEFI loading method of the embodiment includes the following steps: S1, hardware power-on starting stage, after the device is powered on and started, the system first enters the early initialization execution flow of the UEFI firmware.

[0017] S2, UEFI firmware initialization stage, which is divided into four main stages in turn, including: SEC stage, the processor performs reset and security check; PEI stage, the motherboard initializes the memory / chipset; DXE stage, load drivers, including PCI, USB and storage, etc.; BDS stage, enter UEFI Shell, provide interface for customer operating system Bios.

[0018] S3, dynamic loading stage, after BDS stage, system loads and executes preselected boot module in UEFI Shell, reads PCD (Platform Configuration Database) platform default parameters and user-set Shell parameters through boot module, boot module loads customer operating system according to parameters, and loads ZVM into memory.

[0019] PCD platform default parameters and user-set Shell parameters include customer operating system information to be loaded, such as real-time operating system Zephyr and / or real-time operating system Linux image.

[0020] Through PCD mechanism and environment variable reading capability, this step can pre-set specific parameters through PCD configuration file, that is, PCD platform default parameters, and can read Shell parameters through UEFI Shell, so as to dynamically select and load real-time operating system Zephyr and / or real-time operating system Linux image, instead of traditional way of loading single system in fixed order. After boot module is started, PCD parameters set at compiling time are first read from inside of boot module, and a default start plan is established. Then, it is checked whether user provides additional Shell parameters through command line. If user provides Shell version of a certain parameter (such as -os=linux), Shell parameter has higher priority and will cover corresponding default value in PCD. If user does not provide Shell version of a certain parameter, system continues to use default value in PCD.

[0021] The embodiment also adopts redundancy loading strategy and preloading strategy. Redundancy loading mechanism is to load multiple different configurations of customer operating system (customer operating system) images or device trees in loading stage, so that ZVM can load and run different configurations of customer operating systems after being started, and also provides certain dynamic selection capability during running for user.

[0022] Specifically, in step S3, boot module loads customer operating system according to parameters, and loads ZVM into memory, directly loads customer operating system image to specified position in memory in EL3 level, eliminates step of reading customer operating system from persistent device through I / O interface in EL2 stage by Hypervisor, so as to accelerate start speed, and eliminates dependence of Hypervisor on persistent device driver.

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

[0024] Specifically, ZVM reads the PCD platform default parameters and user-set Shell parameters at the initial stage of startup to determine whether to load Zephyr, Linux, or both subsequently.

[0025] In the loading process, ZVM does not rely on the image loading, parameter passing, or kernel entry jump functions provided by the traditional Bootloader, but uses the self-defined UEFI image writing interface to use the UEFI access to the FAT32 file system and the ability to read Shell parameters to complete the preparation work before operating system booting. This structure is more modular, facilitating debugging, tailoring, and cross-platform deployment.

[0026] In some embedded systems with extremely high real-time requirements, developers can enable only Zephyr at build time to ensure that the system can respond to interrupts and event processing with minimal delay. In complex application scenarios, such as multi-task concurrency, graphical user interface, multi-protocol stack running, etc., developers can choose to load and run the Linux kernel to support user-level running with its mature software ecosystem and system service framework. In more advanced hybrid architecture design, if the device has multi-core support, ZVM can run Zephyr on one core to handle real-time tasks and run Linux on another core to handle non-real-time tasks, both of which work together to complete complex business logic, thus balancing real-time performance and system functionality.

[0027] This solution fully utilizes the Boot Manager capabilities provided by UEFI in the UEFI startup phase. Users directly load and execute the boot module through the Shell in the UEFI Shell environment, breaking free from the static control of the loading process by traditional Bootloader (such as GRUB or U-Boot), and no longer need to manually maintain startup configuration files, disk partitions, or specific boot programs, which is closer to the concept of on-demand loading and multi-configuration running in modern systems.

[0028] Taking a domestic high-performance NUMA+ARM64 architecture server, such as Feiteng S5000C, as an example, ZVM is introduced as a Hypervisor layer, and after the UEFI environment in step S4, i.e., after the UEFI phase is completed (EL3 level), the UEFI system hands over control directly to run at the EL2 level.

[0029] Compared with the traditional Host OS, that is, the operating system not carried by the virtualization technology, the Hypervisor is carried as an intermediate layer. Before and after entering the ZVM in step S4, the system needs to enter the EL1 level from the EL3 level, and then run from the EL1 level to the EL2 level after the HostOS starts the virtual machine. This way shortens the startup path and improves the loading speed.

[0030] This embodiment fully utilizes the hardware-level isolation capability and hard real-time task scheduling capability provided by the ZVM. Specifically, in step S4, the ZVM completes the necessary virtualization platform initialization operation immediately after starting, including processor mode setting, paging mechanism enabling, kernel space mapping, etc.

[0031] Zephyr and Linux are loaded as client operating systems to the specified NUMA node and run in the EL1 level. The running state of each client operating system is uniformly scheduled and isolated by the ZVM in the EL2 level, effectively guaranteeing the execution priority and resource exclusive demand of the real-time operating system, and ensuring that the non-real-time client operating system does not interfere with the system response time.

[0032] The ZVM, as a lightweight virtualization layer running in the EL2 level, realizes independent running space isolation and resource dynamic configuration for each client operating system through hardware virtualization technology (such as Stage-2 page table, GIC virtualization).

[0033] During system operation, the ZVM supports dynamic adjustment of the CPU core number, memory size, peripheral system parameters, etc. of the client operating system according to the task strategy during operation, ensuring the determinacy of the real-time system operation and enhancing the task flexibility and platform adaptability of the overall system.

[0034] This scheme integrates a custom boot module in the standard UEFI startup chain and starts manually through the UEFI Shell command. The boot module reads the startup strategy configuration (such as NVRAM parameters), judges the type, number and startup order of the client operating systems to be loaded, and finally loads the ZVM into the memory. Then, the PC pointer is set to the starting address of the ZVM loading, and the system control is formally handed over to the Hypervisor layer. Unlike the traditional GRUB and U-Boot static loading method, this scheme moves the control right of operating system image loading to the EL2 level, which is uniformly managed by the ZVM, significantly improving the decoupling and flexible management capability between client operating systems.

[0035] ZVM runs in EL2 privilege level after starting, first completes detection of underlying NUMA topology information, and binds its scheduling domain to the specified NUMA node. ZVM constructs an independent virtual running context for each guest operating system instance, including: virtual CPU (vCPU) allocation and mapping; stage-2 page table establishment, isolating its physical address access permission; virtual interrupt controller (VGIC) injection mechanism, supporting Trap interrupt management; virtual device model and I / O MMIO forwarding interface.

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

[0037] The present scheme provides a unified guest operating system on-demand loading mechanism, which supports dynamically determining the operating system combination to be loaded through startup parameters or configuration strategies. For example, only Zephyr is loaded in industrial scenarios to handle low-latency real-time tasks; and Linux can be loaded in computing-intensive services to run complex services.

[0038] The present scheme also adopts a redundant loading mechanism, and simultaneously loads multiple Zephyr images and Linux device trees with different configurations, so that ZVM can dynamically select the number of CPU cores, memory size, and system peripheral parameters of the guest operating system during operation, providing high flexibility for the Hypervisor.

[0039] The present scheme also adopts a preloading mechanism. Before ZVM starts, the boot module (EFI application based on UEFI) directly loads all core components of the guest operating system, including the kernel image, device tree (DTB), root file system (initramfs), etc., to the specified address in memory, rather than reading and loading from a virtual disk image or physical hard disk after starting in the traditional virtual machine scheme. This method completely avoids the simulation overhead and interrupt falling process in the virtual I / O process, improving the startup efficiency and resource isolation granularity.

[0040] This solution is applicable to domestic high-performance server platforms with ARMv8 architecture, support for EL2 virtualization extensions, and NUMA topology (such as Feiteng S5000C). It does not rely on new hardware components at the hardware level, but rather configures existing processors, interrupt controllers, memory resources, and other parameters based on existing general server architectures to achieve flexible loading of operating systems, runtime resource adjustment, and real-time performance guarantees.

[0041] Embodiment Two This embodiment describes the actual deployment process.

[0042] In the actual deployment process, developers first need to complete a series of preparatory work, including the compilation of various system components, the organization of storage media, and the configuration of EFI startup files.

[0043] First, in the compilation phase, developers need to use a cross-compilation tool chain to build a ZVM (virtual machine manager) image for the target ARM platform. Due to the NUMA architecture characteristics, the CPU group and GICR (general interrupt controller group) of a certain NUMA node need to be selected during construction, and the CPU node is added to the S5000C device tree of ZVM.

[0044] At the same time, it is also necessary to generate corresponding image files for each type of operating system required, such as Linux kernel images and executable images of Zephyr. In addition, according to the needs of different operating systems and the needs of different system parameter configurations of the same operating system, corresponding device tree files need to be generated to ensure that the system can correctly identify and initialize hardware resources and dynamically select different configurations during the startup process. At the same time, to ensure that the operating system can start and run normally, the necessary root file system should also be built in advance and consistent with the startup configuration of each operating system.

[0045] After these image files are compiled and built, they will be placed uniformly in the startup medium. This medium can be a USB mobile device, a SATA hard disk, an Nvme hard disk, or other persistent storage devices, and the startup medium needs to be formatted to FAT32 format.

[0046] Developers need to configure the system's built-in UEFI Shell default startup source according to the target platform's startup sequence and disable the built-in security startup function of the BIOS. Subsequently, the boot module program is also placed under the startup medium. The user enters the UEFI Shell and uses the Shell command to directly load and run the ZVM startup program, and can pass command line parameters.

[0047] In the Hypervisor boot module, ZVM first reads the PCD platform default parameters configured by the dec file at compile time to obtain the default loading strategy of the current system. Then read the command line parameters, ZVM will automatically execute the loading process of the corresponding system, including reading the kernel image, device tree, initialization parameters, etc., and finally through the ExitBootService and other UEFI provided exit boot stage interface, set the PC pointer to the starting position of ZVM code, hand over the control to ZVM to take over the EL2 level, and finally realize the parallel running of Zephyr and Linux by embedded real-time virtual machine ZVM.

[0048] This scheme first introduces the virtualization layer ZVM as Hypervisor in the EL3 level startup architecture, realizes the cross-layer boot logic from firmware to EL2 through the boot module, and breaks the dependence of traditional bare machine boot mode on static booters such as GRUB / U-Boot. The system automatically identifies and loads multiple heterogeneous operating system images through strategy files or startup parameters in the startup phase, assigns independent running parameters (CPU number, memory size, device resources) to each guest operating system, and starts in parallel mode after ZVM constructs its virtual running context, and is uniformly scheduled. This mechanism has high universality and scalability, adapts to various UEFI firmware implementations and ARM64+NUMA architecture server platforms, and significantly reduces the complexity of multi-system deployment and integration.

[0049] This scheme uses ZVM as an embedded real-time virtual machine running in the EL2 layer, supports fine control of Trap, virtual interrupt (VGIC), and Stage-2 address space access of guest operating systems, provides hardware-level interrupt isolation, affinity scheduling, preemption priority, and other hard real-time guarantee mechanisms for Zephyr instances running in the EL1 layer, effectively eliminates the interference of non-real-time tasks on real-time response paths. Through the NUMA node binding mechanism, ZVM can be exclusively allocated to a specific kernel / memory domain, ensuring low jitter and high determinism of task execution. At the same time, by implementing the preloading mechanism, the guest operating system is directly loaded to the specified location in memory, eliminating the step of reading the image file from the persistent storage device through the I / O interface after starting the virtual machine, speeding up the startup speed. This capability is particularly suitable for TSN network, industrial control, flight control, and other server scenarios with strong constraints on system real-time performance.

[0050] The application successfully verifies the loading of ZVM and the simultaneous running of 15 single-core customer operating systems or 7 SMP-enabled multi-core customer operating systems on the domestic server Feiteng S5000C on the NUMA+ARM64 architecture, constructs a mechanism for multi-heterogeneous customer operating system hardware-level isolation and hard real-time task guarantee, and realizes the cooperative running of a high real-time, multi-task, isolated and configurable operating system stack on a domestic server (such as Feiteng S5000C), thereby providing a basic running platform for next-generation intelligent manufacturing, edge cloud, industrial AI and other scenarios.

[0051] The above is only an embodiment of the application, and the application is not limited to the field involved in this embodiment. Well-known specific structures and characteristics in the scheme and other common knowledge are not described in detail here. The ordinary skilled person in the art knows all the ordinary technical knowledge in the field of the application before the filing date or the priority date, can know all the prior art in the field, and has the ability to apply conventional experimental means before that date. The ordinary skilled person in the art can perfect and implement the scheme under the guidance of this application combined with their own ability. Some typical known structures or known methods should not be an obstacle for the ordinary skilled person in the art to implement the application. It should be noted that, for those skilled in the art, without departing from the structure of the application, a number of modifications and improvements can be made, which should also be considered as the protection scope of the application, and these will not affect the effect and practicality of the application. The protection scope of the present application should be subject to the content of its claims, and the specific implementation mode and the like in the specification can be used to explain 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