A hypervisor method for managing multiple library operating systems on an embedded device

Abstract

This invention discloses a hyperkernel method for managing multiple library operating systems on embedded devices. The invention first configures the hyperkernel runtime environment configuration information. Based on the directory containing the configured library operating system ELF format image files, it parses the corresponding image files and converts them into binary files. Next, it uses the binary files to build the hyperkernel runtime environment, generating a hyperkernel runtime environment image file. The hyperkernel runtime environment image file is then used to run and initialize the hyperkernel runtime environment. After starting and initializing the hyperkernel runtime environment, it parses and reads the library operating system configuration information. Resources are allocated to the library operating systems according to the configuration information. Finally, the hyperkernel runtime environment transfers the program execution flow to the library operating systems, and execution of the library operating systems begins. This invention uses hardware virtualization technology, which can virtualize hardware resources into multiple virtual resources.

Description

Technical Field

[0001] This invention relates to a super kernel management method, specifically a super kernel method for managing multiple library operating systems on embedded devices. Background Technology

[0002] LibOS is an operating system kernel design philosophy. A key feature is its fully modular kernel components, provided to upper-layer applications as micro-libraries, resulting in a lightweight operating system. Guided by this design philosophy, the entire LibOS kernel contains only the micro-libraries that applications depend on, allowing for customization based on the characteristics of upper-layer applications. This aims to achieve a high-efficiency, secure, and lightweight operating system. This structure enables flexible kernel configuration and avoids unnecessary resource overhead. LibOS has already been widely adopted in the cloud computing field.

[0003] An embedded operating system is an operating system specifically designed to run on embedded devices. Embedded operating systems are characterized by low performance overhead and high system real-time performance. It's easy to see that the characteristics of library operating systems are highly compatible with the needs of embedded operating systems, making the porting of library operating systems to embedded devices a huge potential solution.

[0004] However, many problems remain to be solved to achieve this porting. Due to the limitations of the library operating system architecture, a single library operating system can only run one application and provide only a single service. A simple solution to achieve full functionality on embedded devices is to add multiple applications to a single library operating system, allowing a single kernel to provide multiple functionalities. However, this leads to a lack of isolation between different applications, resulting in security issues. Furthermore, this approach loses the customization capabilities of the library operating system. Therefore, a method is needed to manage and run multiple library operating systems on the same embedded device. Summary of the Invention

[0005] Based on the above analysis, the present invention aims to provide a super kernel method that can support the management and running of multiple library operating systems on the same embedded device, thereby fully leveraging the advantages of library operating systems to solve the problem of insufficient support for multiple library operating systems in existing embedded runtime environments.

[0006] This invention includes a hyperkernel runtime environment that supports the operation of a library operating system, and a hyperkernel build system for building the hyperkernel runtime environment. The hyperkernel runtime environment includes core modules and optional hyperkernel runtime micro-libraries. This method can be used to manage and run multiple library operating systems, but it does not include the construction of the library operating systems; therefore, a pre-built ELF format image file of the library operating system is required.

[0007] Based on the above premises, the method of the present invention includes the following steps:

[0008] Step (1) Manually configure the hyperkernel runtime environment configuration file. In this step, detailed configuration information needs to be set, including the configuration of the library operating system, such as the storage directory of the corresponding library operating system ELF format image file. In addition, the resource information of the hyperkernel runtime environment also needs to be configured.

[0009] Step (2): The super kernel building system parses the corresponding image file according to the directory where the library operating system ELF format image file configured in Step 1 is located, and converts it into a binary (BIN) file. This binary file will be used as one of the source files of the super kernel runtime environment and participate in the construction process of the super kernel runtime environment.

[0010] Step (3) Build the hyperkernel runtime environment image file. The hyperkernel build system uses the library operating system image binary file generated in step 2 to build the hyperkernel runtime environment. During this process, the hyperkernel build system can flexibly select and integrate specific hyperkernel runtime micro-libraries according to the configuration file. This step will generate the hyperkernel runtime environment image file.

[0011] Step (4) Run the image file of the super kernel runtime environment and initialize the super kernel runtime environment, including key data such as memory information and CPU information of the super kernel runtime environment itself.

[0012] Step (5) Library Operating System Initialization. After starting and initializing the superkernel runtime environment, the superkernel runtime environment parses and reads the library operating system configuration information. Resources are allocated to the library operating system according to the configuration information.

[0013] Step (6) Run the library operating system. After the library operating system is initialized, the superkernel runtime environment transfers the program execution flow to the library operating system and begins executing the library operating system.

[0014] It also includes step (7): the super kernel will process the related operations that cause the library operating system to exit to the super kernel running environment. The super kernel will process and return to the corresponding library operating system to continue execution, such as device input / output, interrupts, etc.

[0015] Furthermore, in step (1), the hyperkernel runtime environment configuration information that needs to be manually configured includes: the number of physical CPUs, the size of physical memory, the interrupt controller version, and the device tree file address information. The library operating system configuration information that needs to be manually configured includes: the number of library operating system CPUs, the library operating system physical memory information, and the library operating system device information. The above two configuration information cover all the necessary configurations to support the hyperkernel runtime environment and the library operating system.

[0016] Furthermore, in step (2), the superkernel build system needs to further parse the library operating system ELF format image file into a binary file, and then expand it in the assembly file using the incbin pseudo-instruction. The advantages of using a binary file are: 1. Simple structure, containing no relocation information or metadata, making it easy for the superkernel to be directly loaded into memory for execution without the need for an operating system loader. 2. Binary files only require the entry address to execute, without going through a complex image parsing process. This speeds up the loading of the library operating system by the superkernel runtime environment.

[0017] Furthermore, in step (3), the superkernel build system can use the configuration file configured in step (1) to specify the corresponding micro-libraries to participate in the build. This step is optimized by drawing on the design ideas of the library operating system, aiming to eliminate unnecessary libraries in the runtime environment. For example, if there are multiple interrupt controller version drivers, it is only necessary to analyze the version requirements of the library operating system for the interrupt controller, and then select the most suitable version. In step 3, a superkernel runtime environment image file will be generated. This image file can be deployed on embedded devices to manage and run multiple library operating systems.

[0018] Further, in step (4), the superkernel runtime environment will be run and initialized. This includes two parts:

[0019] (4-1) Initialization of the part that supports the operation of the super kernel runtime environment: This part mainly consists of the physical memory management module of the super kernel runtime environment.

[0020] (4-2) Initialization of the support library operating system: This part includes enabling hardware virtualization and snapshot system for the library operating system.

[0021] Furthermore, in step (5), after completing its own initialization, the superkernel runtime environment will read and parse the library operating system configuration information and allocate corresponding resources to each library operating system. This includes:

[0022] (5-1) CPU allocation: bind a unique physical CPU to each library operating system.

[0023] (5-2) Memory allocation: Allocate physical memory for each library operating system as its runtime memory. Configure stage 2 page tables for virtual memory-physical memory translation. This step is used to run and isolate multiple library operating systems simultaneously.

[0024] (5-3) Interrupt allocation: Maintain the mapping information between interrupt ID and library operating system ID, so that when an interrupt occurs, the interrupt is sent to the target that handles the interrupt.

[0025] Furthermore, step (7) is an asynchronous, repetitive process, a sudden event occurring during runtime. The superkernel needs to handle the cause of this event. Specifically, step (7) handles the following types of events:

[0026] Interrupt: When an external interrupt causes the library operating system to exit, the CPU execution flow will switch from the library operating system to the hyperkernel environment. The hyperkernel environment needs to further process the external interrupt based on the interrupt ID.

[0027] Hypercall: A hypercall is initiated by the library operating system and requires runtime environment services. Based on hypercalls, the hyperkernel environment can implement more process-level service support according to the characteristics of the library operating system. In this invention, a snapshot system is implemented based on hypercalls and tailored to the characteristics of the library operating system. The snapshot system includes snapshot creation, snapshot restoration, and snapshot pooling.

[0028] Memory access: When accessing memory that does not exist in the page table, the CPU state will switch from the library operating system to the hyperkernel environment. This event is the basis for implementing MMIO (Memory-Map IO) technology. Based on this event, device virtualization and device passthrough can be further implemented.

[0029] In summary, the method of this invention includes the process of constructing and initializing a library operating system, including the design strategies for the physical memory and virtual memory of the hyperkernel environment. In implementing this invention, the library operating system based on the open-source project Unikraft adheres to this principle: the library operating system's virtual addresses are directly mapped to its physical addresses. Therefore, this invention proposes a corresponding memory design strategy based on this principle.

[0030] The method of this invention includes all optimization strategies designed for library operating systems running on a hyperkernel architecture. These include: a hyperkernel environment snapshot system, snapshot creation and recovery, snapshot pools, etc.

[0031] This invention utilizes hardware virtualization technology to virtualize hardware resources into multiple virtual resources and allocate them to multiple library operating systems. Compared to traditional virtualization schemes, this invention provides numerous optimizations for library operating systems to leverage their advantages on embedded devices. Attached Figure Description

[0032] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0033] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and, together with the embodiments of the present invention, serve to illustrate the principles of the invention, but are not intended to limit the scope of the invention. The method provided by the present invention implements a super-kernel runtime environment called Avisor for library operating systems. Avisor can manage multiple library operating systems at the top and manage resources at the bottom. Avisor enables the deployment of multiple library operating systems on the same embedded device.

[0034] Avisor is a bare-metal program developed in C. Its main functions are: 1. To run on the hardware environment and manage hardware resources. 2. To maintain and manage the library operating system context, including initializing the library operating system state, booting multiple library operating systems, and handling context switching between multiple library operating systems.

[0035] like Figure 1 As shown. The embodiments of this application include the following steps:

[0036] Step 1: Manually configure the necessary hyperkernel runtime environment. This step specifies the configuration information for the hyperkernel runtime environment and all library operating systems in the configuration file for subsequent resource allocation. The configuration is stored in a data structure organized in C language, which facilitates the deployment of the hyperkernel runtime environment on embedded devices lacking a file system.

[0037] In one embodiment, this step specifically includes:

[0038] Step 1-1: Manually select and configure the superkernel runtime environment: This involves configuring the required number of physical CPUs, physical memory size, interrupt controller version, device tree file address information, etc. The configuration of the superkernel runtime environment will determine the available resource range of the entire superkernel runtime environment.

[0039] Step 1-2: Manually Configure Library Operating System: The library operating system information that needs to be configured includes: the number of CPUs in the library operating system, library operating system memory information, and library operating system device information. This configuration will determine the available resources for each library operating system. The information configured in this step will be parsed in steps 4 and 5, further determining the resource allocation within the entire system.

[0040] The above two steps mean that system resources will be statically allocated when building the superkernel runtime environment.

[0041] Step 2: Convert the ELF format image file of the library operating system into a binary file format that can be parsed and used by the super kernel.

[0042] In one embodiment, this step is performed in two steps, as follows:

[0043] Step 2-1: In Step 1, the directory containing the library operating system image file was configured. The super kernel build system can locate the required library operating system ELF format image file based on the directory, and use a cross-compilation chain or compilation chain to convert the library operating system ELF format image file into a binary file without any relocation information and metadata.

[0044] Step 2-2: The hyperkernel build system expands the binary file built in Step 2-1 into the corresponding assembly file using the `incbin` pseudo-instruction. This assembly file is then used as the source file for the hyperkernel runtime environment during its construction. It should be noted that the contents of this assembly file will exist as the runtime code segment for the library operating system.

[0045] Step 3: Build the hyperkernel runtime environment image file. In this step, the hyperkernel build system can select specific runtime micro-libraries to participate in the build, especially when dealing with micro-libraries that the library operating system image depends on. By performing pre-analysis, the actual micro-libraries required by the library operating system can be accurately identified. This not only optimizes the runtime environment configuration but also effectively reduces unnecessary resource consumption.

[0046] In one embodiment, taking the Interrupt Controller (GIC) as an example, the process is as follows: The library operating system provides two main versions of GIC support for different hardware platforms and requirements: GICv2 and GICv3. Each version of GIC has its specific features and optimizations; therefore, selecting the appropriate GIC version based on the specific needs of the library operating system and the target platform is crucial. When building and setting up the hyperkernel runtime environment, there is an opportunity to select and specify the corresponding micro-library for either GICv2 or GICv3 based on the exact requirements of the library operating system.

[0047] Step 4: Initialize the superkernel runtime environment. In practice, you can choose to deploy the superkernel runtime environment on QEMU. In this step, use the superkernel runtime image file generated in Step 3 to start the superkernel runtime environment and initialize it according to the configuration information configured in previous steps.

[0048] In one embodiment, this step specifically includes:

[0049] Step 4-1: Initialize the components that support the superkernel runtime environment. This requires configuring the necessary components to support the superkernel runtime environment, such as the superkernel runtime environment physical memory management module.

[0050] Step 4-2: Initialize the operating system runtime support libraries. This mainly includes two modules:

[0051] First, the hardware virtualization module. The hardware virtualization module is an essential module that supports the library operating system to run in the hyperkernel runtime environment.

[0052] Second, for the snapshot system of the library operating system, it is necessary to allocate corresponding physical memory for the system to build the memory space of the snapshot pool.

[0053] Step 5: Library Operating System Initialization. In step 5, the superkernel runtime environment begins creating and initializing the library operating system.

[0054] In one embodiment, this step specifically includes:

[0055] Step 5-1: CPU Allocation: Allocated CPUs are marked using a bitmap. In this step, each CPU core iterates through all library operating system configuration entries to check if the required number of CPUs is met. If not, the CPU is allocated to the library operating system. Simultaneously, ensuring that code executes only once and using locks to protect the bitmap data from concurrency issues guarantee that the same CPU will not be repeatedly allocated to multiple library operating systems.

[0056] Step 5-2: Memory Allocation: Based on the memory configuration information in the configuration details and considering the single address space characteristic of the library operating system, Step 5-2 allocates separate memory regions as their runtime memory for different library operating systems and establishes Stage-2 page tables for each library operating system. Simultaneously, based on the serial port information in the device, the address mapping of the serial port device is removed from the Stage-2 page table, thereby achieving full virtualization of the serial port device. The same principle applies to other fully virtualized devices.

[0057] The Stage-2 page table base address, used as library operating system context information, is written to the physical CPU's vttbr_el2 register. During context switching, the hyperkernel runtime environment needs to maintain the page table base address. Furthermore, considering the resource constraints of embedded systems and the process-level abstraction capabilities of the library operating system, the hyperkernel runtime environment designed in this invention disables its own MMU (Memory Management Unit), meaning it directly uses physical memory at the hyperkernel runtime environment level. This design improves system efficiency, reduces the overhead of memory translation, and further leverages the advantages of the library operating system.

[0058] Step 5-3: Interrupt Assignment: All interrupts will be handled initially by the runtime environment. If the target of the interrupt is a library operating system, the superkernel runtime environment will look up the corresponding library operating system based on the pre-configured interrupt maintenance bitmap and forward the interrupt. If the target of the interrupt is the superkernel runtime environment itself, the superkernel runtime environment will handle the interrupt itself.

[0059] Step 6: Run the library operating system. After all library operating systems have been created, the system will begin executing them. CPU control will be handed over to the corresponding library operating system.

[0060] In one embodiment, step 7 may also be included; step 7 describes the innovations of the hyperkernel runtime environment in providing services to the library operating system and fully leveraging the potential of the library operating system. When system hardware or software malfunctions, external devices generate interrupts, or the library operating system actively invokes the runtime environment, the control flow of the physical CPU will return from the library operating system to the hyperkernel runtime environment. This process is called library operating system exit. The reverse process is called library operating system entry. The hyperkernel runtime environment responds to the following three events during runtime.

[0061] Interrupts. In a hyperkernel runtime environment, interrupts originate from interrupt requests from external devices. These are often library operating systems accessing hardware resources. Each interrupt causes the same execution library operating system to exit, and the hyperkernel runtime environment then performs further interrupt forwarding, thus forwarding the interrupt request to the target library operating system.

[0062] Hypercall. A hypercall is initiated by the library operating system to request services from the hyperkernel runtime environment. In this invention, a lightweight snapshot system is designed for the library operating system based on hypercalls.

[0063] Memory access. When the library operating system accesses memory, if a page fault occurs in the Stage-2 page table, the library operating system will exit, and the superkernel runtime environment will simulate the memory access request and return data to the library operating system.

[0064] Furthermore, this invention utilizes hardware virtualization technology and the process-level abstraction capabilities of the library operating system to design a lightweight snapshot system for the library operating system. This snapshot system is implemented based on hypercalls, similar to the normal virtual machine exit process. The specific steps are as follows:

[0065] Step 1: Assign specific supercall IDs to two basic operations: create a checkpoint and restore a snapshot of a specified version. This ensures the runtime environment can correctly locate the corresponding handler function based on the supercall ID. Simultaneously, initialize the snapshot pool.

[0066] Step 2: The library operating system actively creates a checkpoint using a supercall. After the library operating system initiates the supercall, the hardware transfers control to the superkernel, resulting in a library operating system exit. At this point, the runtime environment recognizes this as a checkpoint operation based on the supercall ID and calls the corresponding function. Within this function, the CPU state and memory regions of the corresponding library operating system are copied to a snapshot for backup. After the backup is complete, the library operating system enters, and the snapshot version ID is returned to the library operating system, allowing it to continue execution.

[0067] Step 3: When the library operating system needs to perform a snapshot restore operation, it can proactively initiate a hypercall. When initiating the hypercall, version information is specified, and the version ID will also be passed as a parameter to the superkernel. The superkernel will attempt to restore the library operating system to the specified snapshot version. If no version information exists or is provided, it will default to restoring to the most recent snapshot.

[0068] In summary, the examples provided by this invention can deploy multiple library operating systems simultaneously on the same embedded device, thereby improving resource utilization. Moreover, compared with traditional embedded runtime environments, the super kernel method implemented in this invention optimizes strategies for the characteristics of library operating systems, aiming to fully leverage the potential of library operating systems in embedded environments.

[0069] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto.

[0070] Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this invention should be included within the protection scope of this invention.

Claims

1. A superkernel method for managing multiple library operating systems on an embedded device, characterized in that... The method includes the following steps: Step 1: Configure the hyperkernel runtime environment configuration information, including the configuration of the library operating system and the resource information configuration of the hyperkernel runtime environment; Step 2: The super kernel building system parses the corresponding image file according to the directory where the library operating system ELF format image file is located, as configured in Step 1, and converts it into a binary file; Step 3: The super kernel building system uses the library operating system image binary file generated in Step 2 to build the super kernel runtime environment and generate the super kernel runtime environment image file; Step 4: Run the image file of the hyperkernel runtime environment and initialize the hyperkernel runtime environment, including its own memory and CPU information; Initialize the part that supports the operation of the hyperkernel runtime environment: This part includes the hyperkernel runtime environment physical memory management module; Initialize the support library operating system: This part includes enabling hardware virtualization and a snapshot system for the library operating system; Step 5: After starting and initializing the superkernel runtime environment, the superkernel runtime environment parses and reads the library operating system configuration information; according to the configuration information, it allocates resources to the library operating system, thereby completing the library operating system initialization; Step 6: After the library operating system is initialized, the superkernel runtime environment transfers the program execution flow to the library operating system and begins executing the library operating system.

2. The method according to claim 1, characterized in that: The cross-compilation chain is used to convert the library operating system ELF format image file into a binary file that does not contain any relocation information and metadata.

3. The method according to claim 2, characterized in that: It also includes the super kernel building system expanding the binary file into a corresponding assembly file using the incbin pseudo-instruction, and using the assembly file as the source file for the super kernel runtime environment to participate in the construction of the super kernel runtime environment.

4. The method according to claim 1, characterized in that: Step 5 specifically includes: CPU allocation binds each library operating system to a unique physical CPU; Memory allocation: Allocate physical memory for each library to the operating system as its runtime memory; Interrupt allocation maintains the mapping information between interrupt IDs and library operating system IDs, thereby sending the interrupt to the specific target that handles the interrupt when it occurs.

5. The method according to claim 4, characterized in that: It also includes a configuration phase 2 page table, which is used for virtual memory to physical memory translation.

6. The method according to claim 1, characterized in that: This also includes situations where superkernel processing-related operations would cause the library operating system to exit into the superkernel runtime environment. After processing, the superkernel would return to the corresponding library operating system to continue execution.

7. The method according to claim 6, characterized in that: The situations that cause the library operating system to exit the hyperkernel runtime environment include: external interrupts, hypercalls, and memory accesses.

Images