Hyper-kernel method for managing multiple library operating systems on embedded device

Abstract

The invention discloses a hyper-kernel method for managing a plurality of library operating systems on an embedded device. The method comprises the following steps of: firstly, configuring environment configuration information when a super kernel runs, analyzing a corresponding mirror image file according to a directory in which the configured ELF-format mirror image file of a library operating system is located, and converting the mirror image file into a binary file; secondly, constructing a super-kernel runtime environment by utilizing the binary file, and generating a mirror image file of the super-kernel runtime environment; running and initializing the super-kernel runtime environment by using the mirror image file of the super-kernel runtime environment; after starting and initializing the super kernel runtime environment, analyzing and reading library operating system configuration information by the super kernel runtime environment; and allocating resources to the library operating system according to the configuration information, transferring the program execution flow to the library operating system by the super-kernel runtime environment, and starting to execute the library operating system. A hardware virtualization technology is used, and hardware resources can be virtualized into a plurality of virtual resources.

Description

Technical Field

[0001] The invention relates to a hyper-kernel management method, in particular to a hyper-kernel method for managing multiple library operating systems on an embedded device. Background Art

[0002] The library operating system (LibOS) is an operating system kernel design concept. One of its important features is that the kernel components are completely modularized and provided to upper-level applications in the form of micro-libraries, thereby building a minimal operating system. Guided by this design concept, the entire kernel of the library operating system only contains the micro-libraries that the application depends on, which can be customized according to the characteristics of the upper-level application, aiming to achieve an efficient, secure and lightweight operating system. This structure allows the kernel to be flexibly configured, avoiding unnecessary resource overhead. The library operating system has been widely used in the field of cloud computing.

[0003] An embedded operating system is an operating system designed to run on embedded devices. It has the characteristics of low performance overhead and high system real-time performance. It is not difficult to find that the characteristics of the library operating system are highly consistent with the requirements of the embedded operating system, which makes it possible to transplant the library operating system to run on embedded devices.

[0004] However, there are still many problems to be solved to achieve this migration. Due to the limitations of the library operating system architecture, a library operating system can only run one application and can only provide a single service. In order to achieve complete functions on embedded devices, a simple solution is to add multiple applications to a library operating system so that one kernel can provide multiple functions. However, this will lead to a lack of isolation between different applications, which will lead to security issues. In addition, this method also loses the customization feature of the library operating system. Therefore, it is necessary to find a method to manage and run multiple library operating systems on the same embedded device. Summary of the invention

[0005] In view of the above analysis, the present invention aims to provide a hyperkernel method that can support the management and operation of multiple library operating systems on the same embedded device, aiming to give full play to the advantages of the library operating system to solve the problem of insufficient support for multiple library operating systems in the existing embedded runtime environment.

[0006] The invention includes a hyperkernel runtime environment supporting the operation of a library operating system and a hyperkernel construction system for constructing the hyperkernel runtime environment, wherein the hyperkernel runtime environment includes a core module and an optional hyperkernel runtime microlibrary. The method can be used to manage and operate multiple library operating systems, but does not include the construction of the library operating system, so it is necessary to pre-construct the library operating system ELF format image file.

[0007] Based on the above premise, the method of the present invention comprises the following steps:

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

[0009] Step (2) The hyperkernel construction 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 hyperkernel runtime environment and participate in the construction process of the hyperkernel runtime environment.

[0010] Step (3) builds 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. In this process, the hyperkernel build system can flexibly select and integrate specific hyperkernel runtime micro libraries based on the configuration file. This step generates an image file of the hyperkernel runtime environment.

[0011] Step (4) uses the image file of the hyperkernel runtime environment to run and initialize the hyperkernel runtime environment, including key data such as the hyperkernel runtime environment's own memory information and CPU information.

[0012] Step (5) Initialization of the library operating system. After starting and initializing the hyperkernel runtime environment, the hyperkernel runtime environment will parse and read the library operating system configuration information and allocate resources to the library operating system according to the configuration information.

[0013] Step (6) Running the library operating system: After completing the initialization of the library operating system, the hypercore runtime environment transfers the program execution flow to the library operating system and starts executing the library operating system.

[0014] It also includes step (7): when the hyper-kernel processes related operations that will cause the library operating system to exit to the hyper-kernel operating environment, the hyper-kernel will return to the corresponding library operating system to continue execution after processing, such as device input and output, interrupts, etc.

[0015] Furthermore, in step (1), the hyper-kernel 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, the device tree file address information, etc. 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, the library operating system device information, etc. The above two configuration information covers all necessary configurations that support the hyper-kernel runtime environment and the library operating system.

[0016] Furthermore, in step (2), the hyperkernel 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 through the incbin pseudo-instruction. The advantages of using binary files are: 1. The structure is simple and does not contain any relocation information or metadata, which makes it convenient for the hyperkernel to load it directly into the memory for execution without the support of the operating system loader. 2. The binary file can be executed with only the entry address, without the need for a complex image parsing process. This speeds up the loading of the library operating system by the hyperkernel runtime environment.

[0017] Furthermore, in step (3), the hyperkernel build system can use the configuration file configured in step (1) to specify the corresponding micro-library to participate in the construction. This step draws on the design ideas of the library operating system for optimization, 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 to select the most appropriate version. In step 3, a hyperkernel runtime environment image file will be generated, which can be deployed on an embedded device to manage and run multiple library operating systems.

[0018] Furthermore, in step (4), the hyperkernel runtime environment is run and initialized. This includes two parts:

[0019] (4-1) Initialize the part that supports the operation of the hyperkernel runtime environment: This part is mainly the physical memory management module of the hyperkernel runtime environment.

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

[0021] Further, in step (5), after completing its own initialization, the hyperkernel 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 to each library operating system as its runtime memory. And configure the stage 2 page table for virtual memory-physical memory conversion. This step is used to run and isolate multiple library operating systems at the same time.

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

[0025] Furthermore, step (7) is an asynchronous, repetitive process, which is an unexpected event during runtime. The hyperkernel needs to handle the cause of the event. Specifically, the following events are handled in step (7):

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

[0027] Hypercall: Hypercall is initiated by the library operating system and requires the runtime environment to provide services. Based on the hypercall, the hyperkernel environment can implement more process-level service support according to the characteristics of the library operating system. In the present invention, based on the hypercall, a snapshot system is implemented according to the characteristics of the library operating system. The snapshot system includes creating snapshots, restoring snapshots, snapshot pools, etc.

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

[0029] In summary, the method of the present invention includes the process of constructing and initializing the library operating system: including the hyperkernel environment physical memory and virtual memory design strategy. When the present invention is implemented, the library operating system based on the open source project Unikraft is based on this principle: the library operating system virtual address directly maps the library operating system physical address. Therefore, based on this principle, the present invention proposes a corresponding memory design strategy.

[0030] The method of the present invention includes all optimization strategies designed for library operating systems running on the hyper-kernel architecture, including: hyper-kernel environment snapshot system, snapshot creation and snapshot recovery, snapshot pool, etc.

[0031] The method of the present invention can virtualize hardware resources into multiple virtual resources by using hardware virtualization technology, and allocate them to multiple library operating systems. Compared with traditional virtualization solutions, the present invention provides many optimizations for the library operating system so as to give full play to the advantages of the library operating system on embedded devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0033] The preferred embodiments of the present invention are described in detail below in conjunction with the accompanying drawings, wherein the accompanying drawings constitute a part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not used to limit the scope of the present invention. The method provided by the present invention implements a hyper-kernel runtime environment named avisor for a library operating system, and avisor can manage multiple library operating systems upward and manage resources downward. Avisor can support the deployment of multiple library operating systems on the same embedded device.

[0034] Avisor is a bare-metal program developed in C language. Its main functions are: 1. Running on the hardware environment to manage hardware resources. 2. Maintaining and managing the context of the library operating system, including initializing the library operating system state, guiding the startup of multiple library operating systems, and being responsible for the context switching of multiple library operating systems.

[0035] like Figure 1 The embodiment of the present application includes the following steps:

[0036] Step 1: Manually configure the necessary hyperkernel runtime environment configuration. This step will specify the configuration information of the hyperkernel runtime environment and all library operating systems in the configuration file for subsequent resource allocation. The configuration is saved in a data structure organized by the C language, which is designed to facilitate the deployment of the hyperkernel runtime environment on embedded devices that lack a file system.

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

[0038] Step 1-1: Manually select and configure the hyperkernel runtime environment configuration: You need to configure the number of physical CPUs, physical memory size, interrupt controller version, device tree file address information, etc. required by the hyperkernel runtime environment. The configuration of the hyperkernel runtime environment will determine the range of available resources for the entire hyperkernel runtime environment.

[0039] Step 1-2: Manual configuration of the library operating system configuration: The library operating system information that needs to be configured includes: the number of library operating system CPUs, library operating system memory information, library operating system device information, etc. 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 to further determine the resource allocation in the entire system.

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

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

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

[0043] Step 2-1: In step 1, the directory where the library operating system image file is located is configured. The hyperkernel build system can find the required library operating system ELF format image file according to the directory, and use the 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 will expand the binary file built in step 2-1 into the corresponding assembly file through the incbin pseudo instruction, and use the assembly file as the source file of the hyperkernel runtime environment to participate in the construction of the hyperkernel runtime environment. It should be noted that the content of the assembly file will exist as a code segment when the library operating system is running.

[0045] Step 3: Build the hyperkernel runtime environment image file. In this step, the hyperkernel build system can select the specified runtime micro-library to participate in the build: especially when dealing with the micro-library that the library operating system image depends on. By performing a pre-analysis first, the micro-library actually required by the library operating system can be accurately identified, which can not only optimize the configuration of the runtime environment, but also effectively reduce unnecessary resource usage.

[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 own specific features and optimization points. Therefore, it is very important to select the appropriate GIC version according to the specific requirements and target platform of the library operating system. When building and setting up the hyperkernel runtime environment, there is an opportunity to select and specify the corresponding micro library using GICv2 or GICv3 according to the exact needs of the library operating system.

[0047] Step 4: Initialize the hyperkernel runtime environment. In the specific implementation, you can choose to deploy the hyperkernel runtime environment on QEMU. In this step, use the hyperkernel runtime image file generated in step 3 to start the hyperkernel runtime environment. And initialize it according to the configuration information that has been configured in the previous step.

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

[0049] Step 4-1: Initialize the part supporting the operation of the hyperkernel runtime environment, which needs to configure the content required to support the operation of the hyperkernel runtime environment, such as the hyperkernel runtime environment physical memory management module.

[0050] Step 4-2: Initialize the support library operating system running part. It mainly includes two modules:

[0051] First, the hardware virtualization module is a necessary module to support the library operating system to run on the hyper-kernel runtime environment.

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

[0053] Step 5: Library operating system initialization. In step 5, the hyperkernel runtime environment starts to create and initialize the library operating system.

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

[0055] Step 5-1: CPU allocation: Mark the allocated CPUs through a bitmap. In this step, each CPU core will traverse all library operating system configuration entries to check whether the number of CPUs is met. If not, the CPU will be allocated to the library operating system. At the same time, the code is guaranteed to be executed only once and the concurrent protection of the bitmap data can be ensured to ensure that the same CPU will not be repeatedly allocated to multiple library operating systems.

[0056] Step 5-2: Memory allocation: Step 5-2 configures separate memory areas for different library operating systems as their runtime memory based on the memory configuration information in the configuration information and the characteristics of the single address space of the library operating system, and establishes the Stage-2 page table of the library operating system respectively. At the same time, according to the serial port information in the device, the address mapping of the serial port device is cancelled in the Stage-2 page table, thereby realizing the full virtualization of the serial port device. The same applies to other fully virtualized devices.

[0057] The Stage-2 page table base address will be written into the vttbr_el2 register of the physical CPU as the library operating system context information. When the context is switched, the hyperkernel runtime environment needs to maintain the page table base address. In addition, combined with the characteristics of limited embedded resources and process-level abstraction capabilities of the library operating system. The hyperkernel runtime environment designed by the present invention disables the MMU (memory management unit) for itself, that is, the physical memory is directly used at the hyperkernel runtime environment level. This design improves the system operation efficiency, reduces the overhead caused by memory translation, and further brings into play the advantages of the library operating system.

[0058] Step 5-3: Interrupt allocation: All interrupts will be uniformly processed by the runtime environment for the first time. If the target of the corresponding interrupt is a library operating system, the hyper-kernel runtime environment will find the corresponding library operating system according to the pre-configured interrupt maintenance bitmap to forward the interrupt. If the target of the interrupt is the hyper-kernel runtime environment itself, the hyper-kernel runtime environment will handle the interrupt by itself.

[0059] Step 6: Run the library operating system. After all library operating systems are created, the system will start to execute the library operating system. The 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 innovation of the hyper-kernel runtime environment providing services for the library operating system and giving full play to the potential of the library operating system. When the system hardware and software are abnormal, the external device generates an interrupt, and the library operating system actively evokes the runtime environment, the control flow of the physical CPU will return from the library operating system to the hyper-kernel runtime environment. This process is called the library operating system exit. The reverse process is called the library operating system entry. The hyper-kernel runtime environment will respond to the following three events during operation.

[0061] Interrupts. In the hyperkernel runtime environment, interrupts come from interrupt requests from external devices. They are often the library operating system's access to hardware resources. When each interrupt occurs, the same execution library operating system exits, and the hyperkernel runtime environment performs further interrupt forwarding, thereby forwarding the interrupt request to the target library operating system.

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

[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 hyperkernel runtime environment will simulate the memory access request and return data to the library operating system.

[0064] In addition, the present invention utilizes hardware virtualization technology and the abstract capability of the library operating system process level to design a lightweight snapshot system for the library operating system. The snapshot system is implemented based on a hypercall, which is similar to the normal virtual machine exit process. The specific steps are as follows:

[0065] Step 1: Assign specific hypercall IDs to two basic operations: create a checkpoint and restore a snapshot of a specified version. This allows the runtime environment to correctly find the corresponding processing function based on the hypercall ID. At the same time, initialize the snapshot pool.

[0066] Step 2: The library operating system actively uses a hypercall to create a checkpoint. After the library operating system initiates a hypercall, the hardware transfers control to the hyperkernel, which means that a library operating system exit occurs. At this time, the runtime environment recognizes that this is a checkpoint operation based on the hypercall ID, and calls the corresponding function. In this function, the CPU state and memory area of ​​the corresponding library operating system are copied to the snapshot for backup. After the backup is completed, the library operating system is executed to enter, and the snapshot version ID is returned to the library operating system, allowing the library operating system to continue execution.

[0067] Step 3: When the library operating system needs to perform a restore operation, it can actively initiate a hypercall. When the version information is specified when initiating the hypercall, the version ID will also be passed as a parameter to the hyperkernel, and the hyperkernel will try to restore the library operating system to the snapshot of the specified version. If the version information does not exist or is not provided, the default is to restore to the most recent snapshot.

[0068] In summary, the example provided by the present invention can deploy multiple library operating systems on the same embedded device at the same time, thereby improving resource utilization. Moreover, compared with the traditional embedded runtime environment, the hyperkernel method implemented by the present invention optimizes the strategy according to the characteristics of the library operating system, aiming to give full play to the potential of the library operating system in an embedded environment.

[0069] The above is only a preferred specific implementation of the present invention, but the protection scope of the present invention is not limited thereto.

[0070] Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the protection scope of the present invention.

Claims

1. A hyperkernel method for managing multiple library operating systems on an embedded device, characterized in that The method comprises 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 hyper-kernel construction 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 file; Step 3, the hyperkernel construction system uses the library operating system image binary file generated in step 2 to build the hyperkernel runtime environment, and generates an image file of the hyperkernel runtime environment; Step 4: Run the hyperkernel runtime environment using the image file, and initialize the hyperkernel runtime environment, including the hyperkernel runtime environment's own memory information and CPU information; Step 5: After the hyperkernel runtime environment is started and initialized, the hyperkernel runtime environment parses and reads the library operating system configuration information; allocates resources to the library operating system according to the configuration information, thereby completing the initialization of the library operating system; Step 6: After completing the initialization of the library operating system, the hyperkernel runtime environment transfers the program execution flow to the library operating system and starts executing the library operating system.

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

3. The method according to claim 2, characterized in that: It also includes that the hyperkernel construction system expands the binary file into a corresponding assembly file through the incbin pseudo instruction, and uses the assembly file as a source file of the hyperkernel runtime environment to participate in the construction of the hyperkernel runtime environment.

4. The method according to claim 1, characterized in that: The step 4 comprises: Initialize the part that supports the operation of the hyperkernel runtime environment: This part is mainly the hyperkernel runtime environment physical memory management module; Initialize the part that supports the library operating system: This part includes enabling hardware virtualization and the snapshot system for the library operating system.

5. The method according to claim 1, characterized in that: The step 5 comprises: CPU allocation, binding a unique physical CPU to each library operating system; Memory allocation, for each library the operating system allocates physical memory as its runtime memory; Interrupt allocation maintains the mapping information between the interrupt ID and the library operating system ID, so that when an interrupt occurs, the interrupt is sent to the target that specifically handles the interrupt.

6. The method according to claim 5, characterized in that: Also included is the configuration stage 2 page table for virtual memory-to-physical memory translation.

7. The method according to claim 1, characterized in that: It also includes the situation where the hyper-kernel processing related operations will cause the library operating system to exit to the hyper-kernel operating environment. After processing, the hyper-kernel returns to the corresponding library operating system to continue execution.

8. The method according to claim 7, characterized in that: The situations that cause the library operating system to exit to the hyper-kernel operating environment include: external interruption, hyper-call and memory access.

Images