A hybrid criticality system static resource configuration method based on numa topology perception

Abstract

This invention provides a static resource allocation method for hybrid critical systems based on NUMA topology awareness, belonging to the field of computer technology. The method includes the following steps: Step 1: Parsing the platform hardware topology; Step 2: Defining node roles and delineating root cell boundaries; Step 3: Real-time domain resource planning; Step 4: Non-real-time extended domain resource planning; Step 5: Root cell resource convergence and retention; Step 6: Generating and solidifying the configuration. This invention fundamentally eliminates the impact of cross-NUMA node access on real-time performance and determinism.

Description

Technical Field

[0001] This invention relates to a static resource allocation method for hybrid critical systems, and more particularly to a static resource allocation method for hybrid critical systems based on NUMA topology awareness, belonging to the field of computer technology. Background Technology

[0002] With the increasing demands for performance, real-time control capabilities, and security in fields such as industrial control, edge computing, and smart devices, high-core-count NUMA multi-core processors based on architectures such as ARMv8 are gradually becoming the mainstream platform. On these platforms, static partitioning virtualization software (such as Jailhouse) is typically introduced to achieve a hybrid deployment of general-purpose operating systems (Linux) and real-time operating systems (RTOS), enabling services with different I / O throughput, real-time constraints, and security levels to run in parallel on the same hardware platform.

[0003] Static partitioning virtualization software maintains resource isolation between virtual execution units (cells) during operation by statically partitioning CPU cores, physical memory, and peripheral resources, and avoids runtime unpredictability caused by dynamic scheduling and resource sharing mechanisms. Therefore, it is widely regarded as an important technical path for building hybrid mission-critical systems.

[0004] However, under the NUMA architecture, there are significant physical differences in the interconnect topology and I / O mounting relationships between different nodes. Relying solely on traditional logical layer resource isolation mechanisms is insufficient to guarantee the real-time and deterministic performance required for RTOS to complete interrupt response and scheduling decisions within microsecond time windows. When the RTOS's CPU core, code segment, data segment, and exception vector table are distributed across different NUMA points, or when its virtualization control path executes across nodes, structural interference factors such as cross-node memory access, cache coherence communication amplification, and interconnect bandwidth contention will be introduced, thereby compromising the system's real-time performance and determinism.

[0005] Existing resource allocation methods mainly focus on logical-level resource isolation and I / O passthrough, but lack systematic modeling and constraint mechanisms for NUMA topology and high-throughput I / O physical mounting relationships, making it difficult to eliminate real-time risks caused by cross-node access from the architectural level.

[0006] Currently, static partitioning virtualization systems, represented by Jailhouse, primarily employ the following resource configuration methods: Cell physical memory allocation: The required memory is allocated to each Inmate Cell in a linear manner, and the remaining memory is allocated to the Root Cell.

[0007] Cell CPU core allocation: Based on a simple isolation strategy, the CPU cores of the Root Cell and the CPU cores of the Inmate Cell are divided according to demand.

[0008] I / O allocation: Allocation is performed using a pass-through method according to the needs of each cell.

[0009] Hypervisor deployment: No fixed physical address requirement; only the memory size and starting physical address need to be specified in the configuration file.

[0010] Under the NUMA architecture, existing solutions mainly have the following problems: 1. RTOS execution path cross-node access issue The task scheduling, context switching, page table access, cache coherency maintenance, and interrupt handling processes of an RTOS are highly dependent on memory access latency and interconnect communication characteristics. When the CPU core used by the RTOS and its code segment, data segment, or device buffer are distributed across different NUMA nodes, scheduling jitter and worst-case execution time escalation will occur due to remote memory access and interconnect contention, thereby compromising real-time determinism.

[0011] 2. Virtualization control path cross-node issue In a static partitioned virtualization architecture, interrupt injection and access to sensitive instructions in the RTOS must be performed through the Hypervisor. When the Hypervisor and the RTOS are deployed on different NUMA nodes, the virtualization control path will access memory across nodes, further amplifying the uncertainty of real-time response.

[0012] 3. High-throughput I / O data path interference problem The root cell typically manages high-bandwidth peripherals and handles the main DMA data path, allowing a large number of non-real-time, high-throughput I / O data streams to share the interconnect bus and memory subsystem with the real-time execution path. If no NUMA topology-level structural constraints are imposed on these data paths, even with logical resource isolation, the system may still experience unpredictable interference in the real-time domain due to interconnect bandwidth contention and cache coherency communication amplification.

[0013] In summary, existing resource allocation strategies lack constraints on RTOS execution paths, virtualization control paths, and high-throughput I / O data paths in the NUMA topology dimension, making it difficult to guarantee the real-time performance and determinism of hybrid critical systems on high-core platforms from an architectural perspective. Summary of the Invention

[0014] To address the aforementioned issues, this invention provides a static resource allocation method for hybrid critical systems based on NUMA topology awareness, thereby eliminating the impact of cross-NUMA node access on real-time performance and determinism.

[0015] To achieve the above objectives, the technical solution of the present invention is: a static resource allocation method for a hybrid critical system based on NUMA topology awareness, comprising the following steps: Step 1: Analyze the platform hardware topology During the system startup phase, the SRAT and IORT entries in ACPI are obtained through the firmware interface, and the affinity relationship between the CPU and NUMA nodes, memory physical address distribution information, and NUMA affiliation relationship of high-throughput I / O peripherals are obtained. Step 2: Based on the parsing results of Step S1, complete the node role definition and Root Cell boundary delineation, including: Real-time domain center node identification, I / O-intensive node identification, and Root Cell resource boundary calculation and reservation; Step 3: Real-time domain resource planning, including: Based on the real-time domain center node identified in step S2, deploy the Hypervisor and deploy the RTOS Inmate Cell; Step 4: Non-real-time extended domain resource planning Based on the real-time domain resources planned in step S3, the non-real-time computing load in the system will be deployed in the form of Linux Inmate Cell; Step 5: Root Cell Resource Convergence and Retention After completing the allocation of CPU core sets and physical memory regions involved in the deployment of RTOS Inmate Cell in step S3 and Linux Inmate Cell in step S4, the CPU cores and physical memory regions in the platform's physical resources that have not yet been occupied by any Inmate Cell will naturally constitute the available resource pool of Root Cell. Step 6: Generate and solidify the configuration, including: Based on the CPU core set and physical memory region allocation results involved in the deployment of RTOS Inmate Cell in step S3 and Linux Inmate Cell in step S4, virtualization configuration files are written, GRUB boot parameters are modified, and compilation and deployment are performed.

[0016] Furthermore, in step 1, the affinity relationship between the CPU and NUMA nodes and the memory physical address distribution information are extracted from the SRAT table entries, and the NUMA affiliation relationship of high-throughput I / O peripherals is extracted from the IORT table.

[0017] Furthermore, in step 2, based on the results of step 1, a real-time domain center node is selected from the NUMA nodes that meet the following constraints: (1) The local memory capacity is sufficient to meet the deployment requirements of RTOS instances; (2) Sufficient CPU core resources can meet the deployment requirements of instances; (3) Do not mount high-throughput I / O peripherals; (4) When there is more than one NUMA node that meets the conditions, one of them can be selected as the real-time domain center node and the remaining nodes can be used as extension nodes.

[0018] Furthermore, in step 2, based on the results of step 1, the NUMA node carrying high-throughput I / O peripherals is marked as an I / O-intensive node. The high-throughput I / O peripherals include network interface controllers, storage controllers, and high-speed accelerators.

[0019] Furthermore, in step 2, based on the total number of CPU cores and total physical memory capacity of the platform, and combined with the CPU and memory requirements of each RTOS Inmate Cell and Linux Inmate Cell determined during the design phase, the minimum resource boundary required for the Root Cell is calculated using the following formula: Minimum resource boundary size of Root Cell = Total platform resources - ∑(Determined resource requirements of each Inmate Cell), Furthermore, the Root Cell is restricted to inheriting only CPU cores and physical memory resources that satisfy this boundary constraint from I / O-intensive nodes and extended nodes.

[0020] Furthermore, in step 3, deploying the Hypervisor involves, after determining the real-time domain center node, explicitly limiting the Hypervisor's binary code segment and the physical memory area required for its runtime to the physical address range of that node; deploying the RTOS Inmate Cell involves binding the CPU core and memory resources of the RTOS Inmate Cell to the real-time domain center node.

[0021] Furthermore, in step 3, if the resources of the real-time domain center node are insufficient to support the expected scale of RTOS instances during the system design phase, the problem can be solved during the system construction phase by reducing the number of RTOS instances, adjusting the RTOS resource specifications, or reselecting a NUMA node that meets the resource constraints as the real-time domain center node.

[0022] Furthermore, in step 4, the following principles are followed when deploying non-real-time computing loads in the system as Linux Inmate Cells: (1) Linux Inmate Cell should be deployed on extension nodes, and its CPU core set and physical memory region should be bound to the same NUMA node; (2) When the resources of the extended node are insufficient, and the I / O intensive node still has remaining CPU cores and physical memory resources after satisfying the minimum resource boundary constraints of the Root Cell, the Linux Inmate Cell is allowed to be deployed on the I / O intensive node. (3) Linux Inmate Cell is not allowed to be deployed on the real-time domain central node; (4) The resource allocation of Linux Inmate Cell must not encroach on the minimum resource boundary reserved for Root Cell.

[0023] Furthermore, in step 5, when the CPU cores and physical memory regions in the platform's physical resources that are not yet occupied by any Inmate Cell naturally constitute the available resource pool of the Root Cell, the following rules apply: (1) The Root Cell preferentially inherits the set of CPU cores and physical memory regions that meet the minimum resource boundary constraints on I / O intensive nodes, and is used to carry high-throughput I / O data paths and DMA access loads. (2) When I / O intensive nodes still have remaining resources after satisfying the deployment constraints of Root Cell and Linux Inmate Cell, Root Cell can further inherit the remaining resources on such nodes; (3) When there are additional extended node resources in the system that are not occupied by the Inmate Cell, the Root Cell can use them as a source of resource extension for non-critical computing loads. (4) The Root Cell must not inherit any CPU cores or physical memory resources on the real-time domain central node.

[0024] Furthermore, in step 6, Modifying the GRUB boot parameters involves using the memmap parameter in the GRUB configuration file to remove the physical memory regions used by the Hypervisor and each Inmate Cell, ensuring that the Root Cell only manages the explicitly allocated memory space after booting. Compilation and deployment involve compiling and deploying the system after modifying the configuration files and GRUB parameters.

[0025] The beneficial effects of the NUMA topology-aware static resource allocation method for hybrid critical systems of the present invention are as follows: The method of this invention imposes deterministic topological constraints on node roles, resource boundaries, and deployment order during the system construction phase, thereby confining the real-time control path to the internal nodes at the physical topology level and constraining the high-throughput I / O data path to the internal nodes of non-real-time nodes, fundamentally eliminating the impact of cross-NUMA node access on real-time performance and determinism.

[0026] This invention analyzes the NUMA topology and I / O mounting relationship, selects NUMA nodes that do not carry high-throughput I / O peripherals as the real-time domain center nodes, and binds the CPU cores and memory resources of the RTOS and Hypervisor to this node. This ensures that the scheduling path, interrupt path, and exception handling path of the RTOS are limited to the node at the physical topology level, thus structurally eliminating the impact of cross-node memory access and interconnect contention on real-time performance.

[0027] This invention identifies NUMA nodes with high-throughput I / O peripherals as I / O-intensive nodes and prioritizes deploying Root Cells on these nodes. This allows non-real-time DMA data streams and I / O access paths to be processed within the node, avoiding entry into the real-time domain central node. This isolates the interference of high-throughput I / O load on the real-time execution path at the physical topology level.

[0028] In the system construction phase, this invention introduces a minimum resource boundary reservation mechanism for the Root Cell and achieves structural separation of the RTOS real-time control path, high-throughput I / O data path, and general computing path at the physical topology level through a deterministic deployment order constraint of "deploying RTOS Inmate Cell resources first, then deploying Linux Inmate Cell resources, and finally having the Root Cell inherit the remaining resources". Attached Figure Description

[0029] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0030] Figure 1 This is a flowchart of the static resource allocation method based on topology awareness of the present invention; Figure 2 This is a schematic diagram of the hybrid critical system architecture based on NUMA topology awareness of the present invention. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0032] Explanation and translation of technical terms NUMA: Non-Uniform Memory Access. In a multiprocessor system that supports NUMA, each processor can access both local and remote memory, but accessing local memory is faster than accessing remote memory.

[0033] Jailhouse: A lightweight static partition virtualization management program based on Linux. It does not provide full-featured emulation of traditional virtual machines, but instead uses hardware-assisted virtualization technology to statically partition and pass through hardware resources.

[0034] Hypervisor: A virtual machine monitor that runs at the highest privilege level of the software layer. It is responsible for creating, managing, and isolating virtual execution units (cells) and providing necessary interrupt forwarding, exception handling, and resource access control capabilities.

[0035] Root Cell: The root unit is a privileged cell in the Jailhouse that runs a Linux system.

[0036] Inmate Cell: A client cell refers to an operating system (such as an RTOS) or bare-metal program running in a Jailhouse isolated partition.

[0037] Hybrid critical systems: Hybrid critical systems refer to multiple software systems or operating system instances running simultaneously on the same hardware platform with different real-time, security and deterministic requirements, at least one of which is a real-time operating system with strict time constraints, and the remaining systems are used to carry general or high-throughput non-real-time tasks.

[0038] RTOS: Real-Time Operating System, is an operating system designed specifically for handling real-time tasks, providing high-priority task scheduling and fast response within strict time constraints.

[0039] Determinism: refers to the predictable, repeatable, and stable upper bound characteristics of the response time, scheduling delay, and task completion time of the critical execution path of a system under the same input and load conditions. It is the core attribute of a real-time system.

[0040] UEFI: Unified Extensible Firmware Interface, a firmware interface standard for modern computing platforms, used to complete hardware initialization, device enumeration and bootloader execution after system power-on, and to provide a unified boot and hardware description interface to the operating system.

[0041] GRUB: GRand Unified Bootloader, a general-purpose bootloader used to load the operating system kernel and initialization image during the system startup phase, and can configure and control memory layout and system behavior through boot parameters.

[0042] ACPI: Advanced Configuration and Power Interface, is a standardized firmware interface specification that provides operating systems with hardware topology, power management capabilities, and device configuration capabilities, supporting structural descriptions of multiprocessor systems and NUMA architectures.

[0043] SRAT: System Resource Affinity Table, one of the ACPI entries, is used to describe the physical affinity relationship between CPU cores, memory regions, and NUMA nodes.

[0044] IORT: Input Output Remapping Table, one of the ACPI entries, used to describe the physical connections between PCIe devices, I / O controllers, SMMU and NUMA nodes, and memory controllers.

[0045] I / O: Input / output devices.

[0046] This invention discloses a static resource configuration method for hybrid critical systems based on NUMA topology awareness. During the system construction phase, it performs detailed analysis of the NUMA topology and high-throughput I / O mounting relationships of the hardware platform, and introduces a node role division mechanism and a resource deployment order constraint mechanism. This maps different types of loads to NUMA nodes with different physical attributes, ensuring that real-time control paths are confined within nodes, while non-real-time high-throughput I / O data paths are accessed and processed within other nodes. This eliminates uncontrollable latency and interconnect bandwidth contention caused by cross-node access at the physical topology level. This method does not rely on vendor-specific automated configuration tools or introduce additional runtime components. Instead, it guides system integrators in writing configuration files through a set of explicit and engineering-implementable configuration order rules. The following detailed description of the method, along with specific embodiments, further illustrates this invention.

[0047] Example 1 This invention discloses a static resource configuration method for a hybrid critical system based on NUMA topology awareness. Configuration is implemented using UEFI and GRUB, ensuring that the resource distribution of all critical components is planned and fixed according to the NUMA topology before the Root Cell starts. This achieves topology-aware deployment without modifying the operating system or virtualization framework. The hardware topology information required by this invention mainly comes from the SRAT and IORT entries provided in the ACPI standard. 1. CPU-NUMA node affinity By parsing the SRAT table, the physical binding relationship between the CPU core and the NUMA node is obtained, which is used to guide the CPU affinity configuration of each cell.

[0048] 2. Memory physical address distribution information By parsing the SRAT table, the starting address and length range of the local memory of each NUMA node are obtained, enabling precise memory binding between each cell and the hypervisor.

[0049] 3. NUMA attribution for high-throughput I / O peripherals By parsing the IORT table, the physical connection relationships between PCIe and various high-throughput I / O, NUMA nodes, and memory controllers are obtained, providing a structural basis for the selection of Root Cell deployment nodes and the physical isolation of I / O data paths.

[0050] The aforementioned topology information, as objective physical attributes that can be obtained during the platform startup phase, provides a deterministic input basis for the static topology-aware configuration of system resources, enabling real-time performance and deterministic constraints to be implemented during the system construction phase.

[0051] Based on the topology information obtained above, a node role assignment mechanism and a resource deployment order constraint mechanism are introduced to map different types of loads to NUMA nodes with different physical attributes, as detailed below: 1. Real-time domain center node NUMA nodes without high-throughput I / O peripherals are selected as the real-time domain center nodes. Only the RTOS InmateCell and Hypervisor are deployed, ensuring that the RTOS scheduling, interrupt, and exception handling paths are confined to the node at the physical topology level. The real-time domain center node is used to carry the real-time control paths with the most stringent constraints on real-time performance and determinism. Its deployment principles are as follows: (1) Deploy only RTOS Inmate Cell; (2) Do not deploy Root Cell or Linux Inmate Cell; (3) Do not mount high-throughput I / O peripherals; (4) The number of RTOS instances is determined by the number of CPU cores in the node, the physical memory capacity, and the real-time business requirements of the project. (5) The critical execution code segment and runtime memory area of ​​the Hypervisor are limited to the physical address range of the node, so that the virtualization control path and the RTOS execution path remain consistent within the node.

[0052] By employing the above methods, the scheduling path, interrupt response path, and exception handling path of the RTOS are confined to the node at the physical topology level, thus structurally eliminating the impact of cross-NUMA node access on real-time determinism.

[0053] 2. I / O-intensive nodes NUMA nodes with high-throughput I / O peripherals are identified as I / O-intensive nodes, and Root Cells are deployed preferentially to ensure that non-real-time DMA data streams are accessed and processed within the node, avoiding entry into the real-time domain central node. I / O-intensive nodes are used to handle high-throughput I / O data paths and DMA access loads, and their deployment principles are as follows: (1) Mount high-throughput I / O peripherals such as network interface controllers, storage controllers, and high-speed accelerators; (2) Root Cells are preferentially deployed on this type of node; (3) After satisfying the minimum resource boundary constraints of the Root Cell, the Linux Inmate Cell can be deployed; (4) All DMA buffers, IOMMU page tables, I / O ring buffers, etc. are preferentially allocated to the physical memory area to which the node belongs.

[0054] By employing the above methods, non-real-time high-throughput I / O data paths can be accessed and processed within the node, avoiding cross-node access to the real-time domain central node. This physically isolates the non-real-time load from interfering with the real-time domain's memory bandwidth and access latency determinism.

[0055] 3. Expanding Nodes NUMA nodes that neither support real-time domains nor high-throughput I / O are defined as extension nodes, used to deploy Linux Inmate Cells or as a source of resource extension for the Root Cell. Extension nodes must not host RTOS instances or hypervisors to avoid the propagation of real-time execution paths across nodes, ensuring that the latency and bandwidth characteristics of the real-time domain center node remain stable and predictable at the physical topology level. Extension nodes are used to support non-real-time computing loads or as a source of resource extension for the Root Cell, and their deployment principles are as follows: (1) Linux Inmate Cell can be deployed; (2) Remaining CPU cores and physical memory resources can be inherited by the Root Cell; (3) It does not undertake real-time path control; (4) Do not mount high-throughput I / O peripherals.

[0056] The presence of extended nodes enables the platform to improve overall resource utilization and support the expanded deployment of multi-instance general-purpose services while maintaining real-time domain physical isolation constraints.

[0057] Example 2 Based on Example 1, combined with Figure 1 The overall process of the method of the present invention will be described in detail, specifically including the following steps: Step 1: Analyze the platform hardware topology During the system startup phase, the SRAT and IORT entries in ACPI are obtained through the firmware interface, and the following parsing is performed: (1) Extract the relationship between CPU cores and NUMA nodes in memory regions from the SRAT table; (2) Extract the connection relationship between high-throughput I / O and NUMA nodes from the IORT table.

[0058] Step 2: Node Role Definition and Root Cell Boundary Delineation 2.1 Real-time Domain Center Node Identification Based on the results of step 1, select the real-time domain center node from the NUMA nodes that meet the following constraints: (1) The local memory capacity is sufficient to meet the deployment requirements of RTOS instances; (2) Sufficient CPU core resources can meet the deployment requirements of instances; (3) Do not mount high-throughput I / O peripherals; (4) When there is more than one NUMA node that meets the conditions, one of them can be selected as the real-time domain center node and the remaining nodes can be used as extension nodes.

[0059] 2.2 I / O-intensive node identification Based on the results of step 1, NUMA nodes that carry high-throughput I / O peripherals such as network interface controllers, storage controllers, and high-speed accelerators are marked as I / O-intensive nodes.

[0060] 2.3 Root Cell Resource Boundary Calculation and Reservation Based on the platform's total CPU cores and total physical memory capacity, and combined with the CPU and memory requirements of each RTOS Inmate Cell and Linux Inmate Cell determined during the design phase, the minimum resource boundary required for the Root Cell is calculated, namely: Minimum resource boundary size of Root Cell = Total platform resources - ∑(Determined resource requirements of each Inmate Cell), Furthermore, the Root Cell is restricted to inheriting only CPU cores and physical memory resources that satisfy this boundary constraint from I / O-intensive nodes and extended nodes.

[0061] Step 3: Real-time Domain Resource Planning (Hypervisor & RTOS) 3.1 Deploying the Hypervisor After determining the central node of the real-time domain, the binary code segment of the Hypervisor and the physical memory area required for its runtime are explicitly limited to the physical address range of the node. This ensures that the virtualization control path is always confined to the central node of the real-time domain, avoiding the additional memory access and synchronization overhead introduced by the control path migration across nodes, thereby improving the stability and determinism of the RTOS interrupt response path and exception handling path.

[0062] 3.2 Deploying RTOS Inmate Cell By binding the CPU cores and memory resources of the RTOS Inmate Cell to the real-time domain central node, the scheduling path, interrupt response path, and exception handling path of the RTOS are all confined to the execution within the real-time domain central node.

[0063] If the resources of the real-time domain center node are insufficient to support the scale of RTOS instances expected during the system design phase, it is necessary to address this during the system construction phase by reducing the number of RTOS instances, adjusting the RTOS resource specifications, or reselecting a NUMA node that meets the resource constraints as the real-time domain center node, rather than deploying the RTOS to extended nodes or I / O-intensive nodes, in order to maintain the intra-node convergence characteristics of the real-time execution path.

[0064] Step 4: Non-real-time extended domain resource planning After completing the deployment of the Hypervisor and RTOS Inmate Cell on the real-time domain center node, and establishing the minimum resource boundary constraints for the Root Cell on I / O-intensive nodes, the non-real-time computing load in the system is deployed in the form of Linux Inmate Cells, following these principles: (1) Linux Inmate Cell should be deployed on extension nodes, and its CPU core set and physical memory region should be bound to the same NUMA node; (2) When the resources of the extended node are insufficient, and the I / O intensive node still has remaining CPU cores and physical memory resources after satisfying the minimum resource boundary constraints of the Root Cell, the Linux Inmate Cell is allowed to be deployed on the I / O intensive node. (3) Linux Inmate Cells are not allowed to be deployed on the real-time domain center node in order to avoid the potential interference of non-real-time operating system behavior on the determinism of real-time control paths. (4) The resource allocation of Linux Inmate Cell must not encroach on the minimum resource boundary reserved for Root Cell, so as to ensure that Root Cell can fully carry high-throughput I / O data path.

[0065] By constraining the deployment order as described above, non-real-time computing loads are preferentially distributed to expansion nodes and I / O-intensive nodes, and the resource boundaries required for the Root Cell to carry high-throughput I / O data paths are structurally guaranteed during the system construction phase.

[0066] Step 5: Root Cell Resource Convergence and Retention After the CPU core sets and physical memory regions of the RTOS Inmate Cell and Linux Inmate Cell are allocated, the CPU cores and physical memory regions in the platform's physical resources that are not yet occupied by any Inmate Cell naturally constitute the available resource pool of the Root Cell, and follow these rules: (1) The Root Cell preferentially inherits the set of CPU cores and physical memory regions that meet the minimum resource boundary constraints on I / O intensive nodes, and is used to carry high-throughput I / O data paths and DMA access loads. (2) When I / O intensive nodes still have remaining resources after satisfying the deployment constraints of Root Cell and Linux Inmate Cell, Root Cell can further inherit the remaining resources on such nodes; (3) When there are additional extended node resources in the system that are not occupied by the Inmate Cell, the Root Cell can use them as a source of resource extension for non-critical computing loads. (4) The Root Cell must not inherit any CPU cores or physical memory resources on the real-time domain central node.

[0067] By adopting the above resource inheritance order, the high-throughput I / O data path of the Root Cell is preferentially limited to I / O-intensive nodes at the physical topology level. The remaining extended resources are only used for non-real-time computing load expansion, thereby avoiding DMA traffic and cache consistency communication across NUMA nodes from entering the real-time domain center node. This ensures that the latency and bandwidth characteristics of the real-time control path remain stable and predictable, while improving the overall platform resource utilization.

[0068] Step 6: Generate and solidify configuration 6.1 Writing Virtualization Configuration Files Based on the aforementioned results regarding the CPU core set and physical memory segmentation of RTOS Inmate Cell and Linux Inmate Cell, a configuration file is written to explicitly specify: (1) The physical memory area occupied by the Hypervisor; (2) The memory mapping range and CPU binding set of each RTOS Inmate Cell; (3) The memory mapping range and CPU binding set of each Linux Inmate Cell; (4) The physical memory mapping range of the Root Cell.

[0069] The CPU core set of the Root Cell does not need to be configured separately; its available cores are automatically obtained by subtracting the core set allocated to each Inmate Cell from the total core set of the system.

[0070] 6.2 Modify GRUB boot parameters In the GRUB configuration file, the memmap parameter is used to remove the physical memory regions used by the Hypervisor and each Inmate Cell, ensuring that the Root Cell only manages the memory space that is explicitly allocated after startup.

[0071] 6.3 Compilation and Deployment After modifying the configuration files and GRUB parameters, the system is compiled and deployed. During startup, GRUB parameters ensure that critical memory areas are correctly preserved, the virtualization configuration files ensure that the CPU and memory mapping relationships of each Inmate Cell are loaded as expected, and the Root Cell automatically inherits the remaining CPU cores and runs using its explicitly configured memory areas, thus ensuring that physical topology constraints are consistently applied at runtime.

[0072] Example 3 Based on the above embodiments, combined with Figure 2The specific application of the method of the present invention is described in detail. This embodiment is based on an ARMv8 architecture server platform with four NUMA nodes (Node 0 - Node 3) to build a hybrid mission-critical system. The platform has a total of 96 physical cores and unified memory addressing.

[0073] Step 1: Topology Analysis and Node Role Definition During system startup, the SRAT and IORT entries of ACPI are parsed.

[0074] (1) Node 0 (CPU 0-23): According to the IORT table, it is found to be equipped with an RDMA network card and an AI acceleration card. Due to the high throughput peripherals it carries, it is defined as an I / O intensive node.

[0075] (2) Node 1 (CPU 24-47): No high-throughput peripherals are mounted, and local memory and CPU resources are complete. Defined as the real-time domain center node.

[0076] (3) Node 2 (CPU 48-71): Equipped with an NVMe storage controller and a display controller. Defined as an I / O intensive node.

[0077] (4) Node 3 (CPU 72-95): No critical peripherals are mounted. Defined as an extension node.

[0078] Step 2: Root Cell Resource Boundary Calculation According to the system design, the Root Cell needs to reserve at least 40 cores and corresponding DMA buffers to maintain I / O throughput. Therefore, resource reservation locks are established on Node 0 and Node 2 to prevent other Inmate Cells from encroaching on the resources of these two nodes.

[0079] Step 3: Constructing the Real-Time Domain Center Node (Node 1) like Figure 2 As shown, the Hypervisor's code segment and stack are explicitly specified to be loaded into the starting region of Node 1's physical memory (e.g., physical addresses 0x4000000000 - 0x4004000000). Meanwhile, RTOS Inmate Cell 1 is configured to use Node 1's CPUs 24-35 and the local memory segment immediately adjacent to the Hypervisor; RTOS Inmate Cell 2 is configured to use Node 1's CPUs 36-47 and subsequent local memory. This layout ensures that RTOS interrupt responses, context switching, and Hypervisor exception handling are all handled within a closed loop within Node 1, completely eliminating access latency across the NUMA interconnect bus.

[0080] Step 4: Building a Non-Real-Time Extended Domain (Node 3) Deploy general computing workloads on the extended node Node 3. Linux Inmate Cell 1 is bound to CPUs 72-83, and Linux Inmate Cell 2 is bound to CPUs 84-95, both strictly utilizing Node 3's local physical memory. This deployment does not encroach on the reserved resources of Node 0 / 2, nor does it interfere with the real-time performance of Node 1.

[0081] Step 5: Root Cell Resource Convergence (Node 0 & Node 2) After all Inmate Cells have been allocated, the Root Cell automatically inherits the remaining resources, mainly including all resources of the I / O-intensive nodes Node 0 (CPU 0-23) and Node 2 (CPU 48-71). At this point, the network data streams generated by the RDMA network card and the DMA data streams of the storage controller are both processed by the Root Cell within their respective local NUMA nodes, achieving complete isolation between the high-throughput I / O path and the real-time control path at the physical hardware level.

[0082] Step 6: Configuration Generation and Parameter Examples Assuming the hardware topology analysis results, the starting address of the physical memory of the real-time domain center node (Node 1) is 0x4000000000.

[0083] (1) Hypervisor memory configuration .hypervisor_memory = { .phys_start = 0x4000000000, / Starting physical address of Node 1 (at 256GB) / .size = 0x004000000, / Size: 64MB / }, (2) Cell configuration, taking RTOS Inmate Cell 1 as an example / Adjacent to Hypervisor / .mem_regions = { / RTOS has exclusive access to RAM / { .phys_start = 0x4004000000, / Immediately following the end of the Hypervisor (0x4000000000 + 64MB) / .virt_start = 0x0, / The client's internal perspective starts from address 0. / .size = 0x0800000000, / Size: 32GB (hexadecimal 0x800000000) / .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE, }, ... / Other memory segment configurations omitted / }, / CPU core configuration / .cpus = { 0x00000000fff000000, / Node 1: Only uses 24-35% of CPU. / 0x0000000000000000, }, (3) GRUB configuration GRUB_CMDLINE_LINUX="memmap=64M$0x4000000000 memmap=32G$0x4004000000..." / Other Inmate Cell memory that needs to be retained is not listed. /

[0084] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A static resource allocation method for a hybrid critical system based on NUMA topology awareness, characterized in that, Includes the following steps: Step 1: Analyze the platform hardware topology During the system startup phase, the SRAT and IORT entries in ACPI are obtained through the firmware interface, and the affinity relationship between the CPU and NUMA nodes, memory physical address distribution information, and NUMA affiliation relationship of high-throughput I / O peripherals are obtained. Step 2: Based on the parsing results of Step S1, complete the node role definition and Root Cell boundary delineation, including: real-time domain center node identification, I / O intensive node identification, and Root Cell resource boundary calculation and reservation; Step 3: Real-time domain resource planning, including: deploying the Hypervisor and RTOS Inmate Cell based on the real-time domain central node identified in step S2; Step 4: Non-real-time extended domain resource planning Based on the real-time domain resources planned in step S3, the non-real-time computing load in the system will be deployed in the form of Linux InmateCell; Step 5: Root Cell Resource Convergence and Retention After completing the allocation of CPU core sets and physical memory regions involved in the deployment of RTOS Inmate Cell in step S3 and Linux Inmate Cell in step S4, the CPU cores and physical memory regions in the platform's physical resources that have not yet been occupied by any Inmate Cell will naturally constitute the available resource pool of Root Cell. Step 6: Generate and solidify the configuration, including: Based on the CPU core set and physical memory region allocation results involved in the deployment of RTOS Inmate Cell in step S3 and Linux Inmate Cell in step S4, virtualization configuration files are written, GRUB boot parameters are modified, and compilation and deployment are performed.

2. The method according to claim 1, characterized in that, In step 1, the affinity relationship between the CPU and NUMA nodes and the physical address distribution information of memory are extracted from the SRAT table entries, and the NUMA affiliation relationship of high-throughput I / O peripherals is extracted from the IORT table.

3. The method according to claim 1, characterized in that, In step 2, based on the results of step 1, the real-time domain center node is selected from the NUMA nodes that meet the following constraints: (1) The local memory capacity is sufficient to meet the deployment requirements of RTOS instances; (2) Sufficient CPU core resources can meet the deployment requirements of instances; (3) Do not mount high-throughput I / O peripherals; (4) When there is more than one NUMA node that meets the conditions, one of them can be selected as the real-time domain center node and the remaining nodes can be used as extension nodes.

4. The method according to claim 1, characterized in that, In step 2, based on the results of step 1, the NUMA node carrying high-throughput I / O peripherals is marked as an I / O-intensive node. The high-throughput I / O peripherals include network interface controllers, storage controllers, and high-speed accelerators.

5. The method according to claim 1, characterized in that, In step 2, based on the total number of CPU cores and total physical memory capacity of the platform, and combined with the CPU and memory requirements of each RTOS Inmate Cell and Linux Inmate Cell determined during the design phase, the minimum resource boundary required for the Root Cell is calculated using the following formula: Minimum resource boundary size of Root Cell = Total platform resources - ∑(Determined resource requirements of each Inmate Cell), Furthermore, the Root Cell is restricted to inheriting only CPU cores and physical memory resources that satisfy this boundary constraint from I / O-intensive nodes and extended nodes.

6. The method according to claim 1, characterized in that, In step 3, deploying the Hypervisor involves explicitly limiting the Hypervisor's binary code segment and the physical memory area required for its runtime to the physical address range of that node after determining the real-time domain center node; deploying the RTOS Inmate Cell involves binding the CPU core and memory resources of the RTOS Inmate Cell to the real-time domain center node.

7. The method according to claim 6, characterized in that, In step 3, if the resources of the real-time domain center node are insufficient to support the scale of RTOS instances expected in the system design phase, the problem can be solved in the system construction phase by reducing the number of RTOS instances, adjusting the RTOS resource specifications, or reselecting a NUMA node that meets the resource constraints as the real-time domain center node.

8. The method according to claim 1, characterized in that, In step 4, the following principles should be followed when deploying non-real-time computing workloads in the system as Linux Inmate Cells: (1) Linux Inmate Cell should be deployed on extension nodes, and its CPU core set and physical memory region should be bound to the same NUMA node; (2) When the resources of the extended node are insufficient, and the I / O intensive node still has remaining CPU cores and physical memory resources after satisfying the minimum resource boundary constraints of the Root Cell, the Linux Inmate Cell is allowed to be deployed on the I / O intensive node. (3) Linux Inmate Cell is not allowed to be deployed on the real-time domain central node; (4) The resource allocation of Linux Inmate Cell must not encroach on the minimum resource boundary reserved for Root Cell.

9. The method according to claim 1, characterized in that, In step 5, when the CPU cores and physical memory regions in the platform's physical resources that are not yet occupied by any Inmate Cell naturally constitute the available resource pool of the Root Cell, the following rules apply: (1) The Root Cell preferentially inherits the set of CPU cores and physical memory regions that meet the minimum resource boundary constraints on I / O intensive nodes, and is used to carry high-throughput I / O data paths and DMA access loads. (2) When I / O intensive nodes still have remaining resources after satisfying the deployment constraints of Root Cell and Linux Inmate Cell, Root Cell can further inherit the remaining resources on such nodes; (3) When there are additional extended node resources in the system that are not occupied by the Inmate Cell, the Root Cell can use them as a source of resource extension for non-critical computing loads. (4) The Root Cell must not inherit any CPU cores or physical memory resources on the real-time domain central node.

10. The method according to claim 1, characterized in that, In step 6, Modifying the GRUB boot parameters involves using the memmap parameter in the GRUB configuration file to remove the physical memory regions used by the Hypervisor and each InmateCell, ensuring that the Root Cell only manages the explicitly allocated memory space after booting. Compilation and deployment involve compiling and deploying the system after modifying the configuration files and GRUB parameters.

Images