A heterogeneous computing hardware level isolation and dynamic slicing method based on independent control units

Abstract

This invention discloses a method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit, relating to the field of computer hardware. The method includes: upon node power-on, starting an out-of-band management and control unit independently of the host processor to take over control of the heterogeneous computing hardware and construct a physical resource pool; configuring an access control list to divide the management domain and service isolation domain and fixing the access path; after receiving service computing power requests, modifying the address mapping table to map physical resources to the corresponding service isolation domain to generate hardware computing power slices; dynamically updating the address mapping table in real time with load data and adjusting hardware resource quotas without interruption; disconnecting the bus connection of the fault domain and migrating services to a backup slice when hardware anomalies are detected; and triggering hardware-level memory clearing and resource reclamation after slice termination. This invention achieves hardware root-trust level physical isolation, microsecond-level dynamic adjustment without service awareness, and high-reliability management and control, completely eliminating the "noisy neighbor" effect and significantly improving resource utilization and system stability.

Description

Technical Field

[0001] This invention belongs to the field of computer hardware and cloud computing infrastructure, specifically relating to a heterogeneous computing resource management method and system based on independent management and control units. It encompasses hardware-level resource pooling, physical isolation, dynamic slice scheduling, and fault tolerance. Applicable to data centers, edge computing, and high-performance computing scenarios, it aims to solve the problems of high performance loss, poor isolation, and operating system dependence in traditional virtualization solutions, providing native hardware-level computing power management capabilities. Background Technology

[0002] In this example, the applicant conducted a prior art search and evaluation before applying for the application. The current background technology is as follows: 1. Software Virtualization (VMware) Workflow: Software virtualization solutions like VMware work by installing a hypervisor software layer on top of the physical hardware. This software layer simulates multiple virtual hardware environments, allowing multiple operating systems to run simultaneously. When a business needs computing resources, the request is first sent to the hypervisor, which then translates it to the physical CPU and memory. It uses time-slicing to allow different virtual machines to share the physical hardware. Resource allocation relies on software scheduling; the operating system may perceive it as having exclusive access to the hardware, but in reality, it coexists with other virtual machines. At startup, the virtualization layer is loaded first, followed by the guest operating system. Data read / write operations must be translated by the virtualization layer, and instruction execution must be intercepted and simulated by software to ensure that each virtual machine is logically independent. All operations rely on the main CPU's computing power.

[0003] Pain points: Significant performance overhead, instructions require software translation, consuming main CPU resources. Poor security, vulnerabilities in the virtualization layer can lead to the leakage of all virtual machines. Dependence on the stability of the host system, system crashes result in business interruption. Isolation is logical, making it difficult to completely eliminate interference. Hardware-level fault isolation is impossible; a single virtual machine crash can cripple the entire host machine, exhibiting a "noisy neighbor" effect and severe resource contention.

[0004] 2. Server Management (BMC) Workflow: The Server Management Chip (BMC) is a small computer system independent of the main CPU. It connects via a dedicated network interface and can operate even when the server is powered off. Its main function is real-time monitoring of hardware sensors, such as temperature, voltage, and fan speed. Administrators can remotely control the power switch or restart the system. It has its own independent operating system and storage, and does not consume main business resources. However, it only operates at the management level and does not intervene in the data computation path. When the main system is running, the BMC only collects status information; it cannot directly allocate computing cores or video memory resources to specific businesses, nor can it modify hardware data access permissions; it is only responsible for hardware health monitoring.

[0005] Pain points: Limited functionality; it can only monitor and manage power, unable to schedule computing resources. It cannot achieve business-level resource isolation. When a business logic failure occurs, the BMC cannot intervene in the computing process. It acts as a bystander, unable to dynamically adjust hardware resource quotas or cope with load fluctuations. It lacks unified control over heterogeneous computing power, only managing hardware health status, unable to intervene in data paths, and unable to resolve computing power allocation issues.

[0006] 3. Graphics card slicing (NVIDIA MIG) Workflow: Multi-Instance Group (MIG) technology allows a physical GPU to be divided into multiple independent instances. The workflow involves locking specific computing cores and memory blocks at the hardware firmware level. Each instance has independent memory bandwidth and computing units, operating independently. Configuration is typically completed during the initialization phase, with the configuration file generated and then loaded. Application programs directly access their assigned hardware instances without going through a software virtualization layer. This achieves hardware-level performance isolation. However, the partitioning granularity is fixed; once set, the instance size cannot be changed at runtime, requiring a device reset for repartitioning. This is suitable for scenarios with stable loads but cannot respond to changes in real time.

[0007] Pain points: Configuration is static and cannot be dynamically resized at runtime. Adjustments typically require resetting the GPU or restarting the service, causing business interruptions. Only GPU devices are supported; unified management of CPUs or other heterogeneous chips is not possible. Insufficient flexibility makes it difficult to handle fluctuating business loads. Unified resource pooling across chips is not possible; resource utilization is low under uneven loads; dynamic scheduling capabilities are lacking, and seamless resource scaling is impossible.

[0008] 4. Cloud Native (Kubernetes) Workflow: The cloud-native orchestration system Kubernetes (K8s) schedules containerized applications through software. The workflow involves the user submitting an application description, the K8s scheduler analyzing cluster resource availability, and allocating containers to specific nodes. The operating system kernel on each node provides namespaces and cgroups for resource limiting. Data flow is processed directly within the operating system kernel, and scheduling decisions are based on software metrics. It excels at managing the lifecycle and deployment of large-scale applications. Resource allocation relies on feedback from the operating system kernel; scheduling instructions are issued via software APIs; containers share kernel resources, are logically isolated but physically coexist, and rely on the stability of the host operating system for operation.

[0009] In summary, current technology relies on the operating system kernel for isolation, which is a form of soft isolation and suffers from the "noisy neighbor" effect. Scheduling response times are slow, typically on the order of seconds or minutes, and cannot handle microsecond-level load fluctuations. If the operating system kernel crashes, all container services will be affected. Security depends on system patches, which carries the risk of privilege escalation. Hardware-level fault isolation is not possible, software-level limitations are easily breached, performance overhead is significant, and complete physical-level isolation is not achievable.

[0010] Existing heterogeneous computing power isolation and scheduling solutions suffer from core bottlenecks that fail to balance security, performance, and flexibility. The root cause lies in three deeply ingrained technical biases within the field: First, there's a widespread belief that BMC (Body Control Controller) can only be used for hardware monitoring and power management, and absolutely cannot intervene in business data paths or take over computing power scheduling and isolation, otherwise it would severely impact business real-time performance and stability. Second, there's a widespread belief that hardware-level computing power isolation must rely on the chip manufacturer's native firmware, and general solutions cannot achieve dynamic hardware-level isolation across vendors and architectures. Third, there's a widespread belief that hardware resource address remapping and quota adjustments require interrupting services and resetting hardware to take effect, making seamless adjustments during business operation impossible. These biases have long constrained research and development, preventing the industry from escaping the technical predicament of high performance degradation from soft isolation and insufficient flexibility from hard isolation.

[0011] In addition, existing technologies for the application of Input / Output Memory Management Unit (IOMMU) and PCIe Access Control List (ACL) have two inherent limitations that cannot be overcome: First, the configuration rights of IOMMU and ACL belong entirely to the host operating system or the Hypervisor virtualization layer, and the isolation policy is software-defined. Once the operating system or virtualization layer is compromised, the isolation policy can be arbitrarily tampered with, making it impossible to achieve root-trust level security isolation. Second, modifications to conventional IOMMU address mapping rules and ACL policies must interrupt business processes, reset hardware devices, or reload drivers to take effect. They cannot achieve seamless dynamic adjustment of policies during business operation, and can only achieve static isolation, which cannot adapt to the needs of elastic computing power scheduling. Summary of the Invention

[0012] Existing computing resource management methods generally suffer from the following drawbacks: Software virtualization solutions (such as VMware) rely on the Hypervisor layer for resource simulation and instruction translation, resulting in significant performance loss, and logical isolation cannot eliminate the "noisy neighbor" effect and the risk of unauthorized access; Server Management Chips (BMCs) can only perform hardware monitoring and power management, and cannot intervene in business data paths and computing power scheduling, resulting in limited functionality and the inability to achieve resource isolation; Graphics card slicing technology (such as NVIDIA MIG) achieves hardware-level performance isolation, but the configuration is static and rigid, and the slice size cannot be dynamically adjusted at runtime. Adjustment requires resetting the device, causing business interruption, and it only supports a single type of hardware; Cloud-native solutions (such as Kubernetes) rely on the operating system kernel for soft isolation, resulting in slow scheduling response speeds (seconds to minutes), inability to cope with microsecond-level load fluctuations, and kernel crashes will cause all services to be interrupted. None of the above solutions can simultaneously meet the core requirements of high performance, strong isolation, dynamic elasticity, and heterogeneous unification. The root cause lies in the long-standing technical bias in this field: out-of-band management units can only be used for monitoring and cannot intervene in the data path; hardware-level isolation must rely on the chip's native firmware and cannot achieve cross-vendor dynamic adjustment; hardware resource remapping must interrupt services and cannot achieve seamless adjustment at runtime.

[0013] This invention provides a method and system for hardware-level isolation and dynamic slicing of heterogeneous computing power based on independent management and control units, to solve the problems of high performance loss, weak isolation, inability to dynamically adjust, and lack of unified heterogeneous management and control in existing computing power resource management technologies. It achieves independent hardware management and control, bypassing system dependencies, physical-level isolation, secure and interference-free operation, dynamic slicing, seamless business operation, heterogeneous unification, and global resource pooling.

[0014] The following is the technical solution of the present invention: a method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit, comprising the following steps: S1. When the node is powered on, it starts the out-of-band management unit independently of the host processor. By directly accessing the hardware configuration space, it enumerates and takes over the control of heterogeneous computing hardware (including CPU core clusters, GPU stream processors, NPU computing arrays, and FPGA acceleration units) to build a global resource pool. S2. The out-of-band management unit configures an access control list (ACL) at the hardware bus level to divide the physical hardware resource pool into a management domain and multiple service isolation domains, and solidifies the hardware access path so that the hardware resources between different service isolation domains are not visible at the physical link layer. S3. Receive the service computing power demand instruction. The out-of-band management and control unit matches idle hardware resources in the resource pool, modifies the hardware address mapping table, maps the physical hardware resources to the corresponding service isolation domain, and generates a hardware computing power slice. S4. The out-of-band control unit collects the load data of each computing power slice in real time through the hardware performance counter. When the load exceeds the threshold, the address mapping table is dynamically updated to increase or decrease the allocated hardware resource quota without resetting the hardware device. S5. When a hardware anomaly signal is detected, the out-of-band control unit directly cuts off the hardware bus connection or clock signal of the faulty service isolation domain and migrates the service traffic to the backup slice. S6. Upon receiving the slice termination instruction, the out-of-band management unit triggers a hardware-level zeroing instruction to release the address mapping and return the resources to the resource pool.

[0015] Preferably, step S1 specifically includes: S1.1 Independent Power-On Startup: After the node is connected to the power supply, the independent out-of-band control unit (OOCU) is powered on first through the independent power domain, executes the internal hard-coded boot program, initializes its own memory and communication interface physical layer, completes the PCIe Non-Transparent Bridge (NTB) link layer configuration and port initialization, establishes an out-of-band hardware control channel physically isolated from the service data bus through the NTB, and outputs a ready status signal to the system bus after initialization, triggering subsequent hardware enumeration instructions and entering the hardware takeover standby state; S1.2 Hardware Enumeration and Takeover: The OOCU scans the Peripheral Component Interconnect Express (PCIe) bus configuration space of the entire node through the PCIe NTB management channel, reads the full space information of the hardware ID register and base address register (BAR), identifies the hardware specifications, number of cores, and address space boundary parameters of the CPU core cluster, GPU stream processor, NPU computing array, and FPGA acceleration unit, and simultaneously scans the configuration space of the PCIe switch and Input / Output Memory Management Unit (IOMMU) and identifies hardware capabilities. Based on the scan results, it constructs a full node hardware topology table and outputs a list of all schedulable hardware resources. S1.3 Control Locking: The OOCU writes lock bits to the management control registers of all heterogeneous computing hardware, prohibiting the host operating system and upper-layer software from directly modifying the hardware core configuration parameters, taking over the interrupt routing table and Direct Memory Access (DMA) mapping permissions, initializing the hardware-level double-buffered address mapping table in the IOMMU, dividing the active mapping partition and the mapping partition to be updated into physically isolated partitions, marking all physical hardware resources as unallocated after configuration, and outputting the global resource pool. Furthermore, step S2 specifically includes: S2.1 Domain partitioning definition: Based on the security policy, the resource pool is partitioned, one control domain and multiple business isolation domains are defined, a unique domain identifier (Domain Identifier, Domain ID) is assigned to each business isolation domain, and a domain partitioning configuration table is output. The configuration table includes the domain ID, resource quota limit and access permission level. S2.2 Access Control Policy Configuration: The Out-of-Band Control Unit (OOCU) takes over all configuration permissions of the Input / Output Memory Management Unit (IOMMU) and the PCIe switch. It configures Access Control Lists (ACLs) in the IOMMU and PCIe switch, setting that only requests carrying specific domain identifiers are allowed to access the corresponding physical address range. It outputs hardware access policy rules to prevent the host operating system and upper-layer software from modifying the IOMMU and ACL configurations. S2.3 Physical Link Fixation: Shields unauthorized interrupt signals and cache consistency messages, fixes hardware access paths, makes hardware resources between different service isolation domains invisible at the physical link layer, and outputs physical link status signals.

[0016] Furthermore, step S3 specifically includes: S3.1 Demand parsing and matching: Receive the business computing power demand instruction, including computing power type, video memory size and bandwidth requirements, search for idle hardware resource blocks in the resource pool, perform admission verification to ensure that resources are sufficient and comply with the isolation policy, and output the physical hardware resource block identifier that meets the conditions. S3.2 Mapping Table Instantiation: Create a dedicated hardware address mapping table to map the business virtual hardware address to the actual physical hardware address, set access permission bits, and only open the minimum set of permissions required for computing, and output the instantiated address mapping relationship. S3.3 Slice Activation and Verification: Enable the mapping table, return the slice handle to the service. When the service initiates its first access, the hardware unit verifies the consistency between the Domain ID and the mapping table. After the verification is successful, the hardware computing power slice is officially generated, the service starts running, and the hardware computing power slice activation status is output.

[0017] Furthermore, step S4 specifically includes: S4.1 Real-time load acquisition: The computing power slice data is acquired through the hardware performance counter (Performance Monitoring Unit, PMU), and the utilization, power consumption and queue depth data are uploaded through the out-of-band channel to output the real-time load data stream; S4.2 Decision Generation: The internal scheduling algorithm analyzes the load data, determines whether the utilization rate exceeds the threshold, generates expansion or reduction decisions, and outputs resource adjustment instructions. S4.3 Seamless Mapping Update: Performs atomic operations to update the hardware-level double-buffered address mapping table in the IOMMU. After constructing a new mapping table using a double-buffering mechanism and completing the verification, the mapping table activation pointer is atomically switched. The entire process does not reset hardware devices or interrupt the business instruction flow, and completes the dynamic increase or decrease of computing power quota, outputting the hardware resource quota status after the increase or decrease.

[0018] Furthermore, step S5 specifically includes: S5.1 Abnormal Signal Monitoring: Listen for hardware error signals, detect PCIe Uncorrectable Error (UE) or Error Correcting Code (ECC) errors, locate the service isolation domain where the fault is located, and output the fault location information; S5.2 Physical Isolation Blocking: Controls the clock gating circuit or PCIe link disable signal to cut off the bus connection or clock signal of the fault domain and outputs a physical isolation blocking status; S5.3 Recovery and Migration: Send a reset signal to the faulty hardware block, trigger the service migration process to the backup slice, record the fault log, and output a service migration completion signal.

[0019] Furthermore, step S6 specifically includes: S6.1, Command Validity Verification: Receive slice termination command, verify the initiator's digital signature and permissions, lock the slice isolation domain, block new access requests, and output access blocking status. S6.2 Data security erasure: Send a hardware-level clear instruction to the video memory and memory area occupied by the slice, overwrite the original business data with random data, and output a data erasure completion signal; S6.3 Resource Recycling and Archiving: Remove address mapping, mark hardware resource status as idle, record archiving operations to the audit storage area, and output resources to return to the global resource pool status. Attached Figure Description

[0020] Figure 1 This is a flowchart of a heterogeneous computing power hardware-level isolation and dynamic slicing method based on an independent management and control unit in an embodiment of the present invention.

[0021] Figure 2 This is a module structure diagram of a heterogeneous computing power hardware-level isolation and dynamic slicing system based on an independent management and control unit in an embodiment of the present invention. Detailed Implementation

[0022] Terminology Definitions: To facilitate understanding of this invention, the core terms involved are first defined as follows: Out-of-Band Control Unit (OOCU): This refers to a hardware control chip that is independent of the host processor, has its own power domain and clock domain, and powers on before the host processor. In this invention, this unit has complete control over direct access to the PCIe configuration space, IOMMU registers, and hardware address mapping table, unlike traditional BMC chips that can only access monitor registers.

[0023] Hardware computing power slicing refers to an independent hardware operating environment formed by binding physical hardware resources (including CPU cores, GPU stream processors, NPU computing arrays, etc.) to specific service isolation domains through a hardware address mapping table. In this environment, different slices are completely isolated at the physical link layer and cannot access each other.

[0024] Hardware-level double-buffered address mapping table: This refers to two physically isolated address mapping tables maintained in the IOMMU, one being the currently active mapping table and the other being the mapping table to be updated. One possible implementation is to switch the active pointer using atomic instructions, achieving resource adjustments without the business being aware of them.

[0025] Domain ID: A unique hardware-level identifier assigned to each business isolation domain. As a specific implementation, all hardware access requests must carry an identifier matching the domain to receive a response; otherwise, they will be blocked by the hardware. Example

[0026] See Figure 1 , Figure 1 This is a flowchart illustrating the complete process of the heterogeneous computing power hardware-level isolation and dynamic slicing method based on an independent management unit. This embodiment provides a heterogeneous computing power hardware-level isolation and dynamic slicing method based on an independent management unit, including the following steps:

[0027] After a node is powered on, it starts the out-of-band management unit (OOCU) independently of the host processor. As a specific implementation, the OOCU is powered on first through an independent power domain, executes an internally embedded bootloader, completes the PCIe Non-Transparent Bridge (NTB) link layer configuration and port initialization, and establishes an out-of-band hardware management channel that is physically isolated from the service data bus through the NTB.

[0028] Subsequently, the OOCU scans the PCIe bus configuration space of the entire node through the PCIe NTB management channel, reading the hardware ID register and base address register information. The heterogeneous computing hardware that can be identified and managed includes one or more of the following: CPU core clusters, GPU stream processors, NPU computing arrays, and FPGA acceleration units. The OOCU simultaneously scans the PCIe switch and IOMMU configuration space and identifies hardware capabilities, constructing a full-node hardware topology table based on the scan results.

[0029] After identification, the OOCU writes lock bits to the management control registers of all heterogeneous computing hardware, preventing the host operating system and upper-layer software from directly modifying the hardware core configuration parameters, and taking over interrupt routing tables and DMA mapping permissions. In the IOMMU, a hardware-level double-buffered address mapping table is initialized, dividing the system into physically isolated active mapping partitions and pending mapping partitions. After configuration, all physical hardware resources are marked as unallocated, and a global physical hardware resource pool is constructed.

[0030] OOCU configures access control lists at the hardware bus level according to preset security policies. One possible partitioning method is to define a control domain (for OOCU's own management) and multiple service isolation domains. A unique domain identifier (Domain ID) is assigned to each service isolation domain.

[0031] The OOCU takes over all configuration permissions for the IOMMU and PCIe switches, configuring Access Control Lists (ACLs) in the IOMMU and PCIe switches. As a specific implementation, ACL rules set only requests carrying specific domain identifiers to access the corresponding physical address range, output hardware access policy rules, and prohibit the host operating system and upper-layer software from modifying the IOMMU and ACL configurations.

[0032] OOCU masks unauthorized interrupt signals and cache consistency messages, solidifying hardware access paths. As an improved design, it makes hardware resources between different service isolation domains completely invisible at the physical link layer through hardware-level signal masking, outputting physical link status signals.

[0033] The OOCU receives service computing power request instructions. These instructions may include one or more parameters such as computing power type, video memory size, and bandwidth requirements. The OOCU searches the global physical hardware resource pool for available hardware resource blocks that meet the requirements, performs admission checks, and ensures that resources are sufficient and comply with isolation policies.

[0034] After verification, OOCU creates a dedicated hardware address mapping table. As an optional implementation, this mapping table maps service virtual hardware addresses to actual physical hardware addresses and sets access permission bits to only grant the minimum set of permissions required for computation.

[0035] After enabling the mapping table, a slice handle is returned to the service. When the service initiates its first hardware access, the domain identifier carried in the hardware unit verification request is checked against the record in the mapping table. If the verification passes, the hardware computing power slice is officially generated, and the service begins operation.

[0036] OOCU collects computing power slice data in real time through the performance counter (PMU) built into each hardware slice. The data that can be collected includes one or more of the following: utilization, power consumption, and queue depth, and is uploaded as a real-time load data stream through an out-of-band channel.

[0037] The OOCU internal scheduling algorithm analyzes load data to determine whether the utilization rate exceeds a preset threshold. The specific value of the threshold can be flexibly set according to the actual application scenario; for example, the expansion threshold can be set to 80%, and the reduction threshold can be set to 30%.

[0038] When resource quotas need to be adjusted, the OOCU performs atomic operations to update the hardware-level double-buffered address mapping table in the IOMMU. As a preferred double-buffering implementation mechanism, a new mapping table containing the adjusted resources is first built in the partition to be updated. After verification, the activation pointer is switched via an atomic instruction to make the new mapping table effective, and the increased or decreased hardware resource quota status is output. The entire process does not reset hardware devices or interrupt the business instruction flow, and the business completes the increase or decrease of computing power quotas without being aware of it.

[0039] The OOCU continuously monitors for hardware error signals. The types of errors that can be monitored include one or more of PCIe uncorrectable errors (UE) or ECC errors. When an error signal is detected, the OOCU immediately locates the service isolation domain where the fault occurs.

[0040] The OOCU controls the clock gating circuit or PCIe link disable signal to cut off the hardware bus connection or clock signal of the faulty service isolation domain. As a specific fault blocking method, physical isolation can be completed within microseconds, ensuring that the fault is limited to a minimum and avoiding system crashes caused by a single point of failure.

[0041] At the same time, the OOCU sends a reset signal to the faulty hardware block, migrates the service traffic to the backup slice according to the preset disaster recovery strategy, records the fault log, and outputs a service migration completion signal.

[0042] After receiving the slice termination command, OOCU first verifies the initiator's digital signature and permissions. One possible verification method is to use public key infrastructure to verify the command signature.

[0043] After successful verification, the OOCU locks the slice isolation domain, blocking new access requests and outputting an access blocking status. Subsequently, the OOCU sends a hardware-level zeroing instruction to all video memory and system memory areas occupied by the slice, overwriting the original business data with random data. As an improved security design, the data erasure operation is performed at the hardware level, without going through the operating system, ensuring that the data cannot be recovered, and outputting a data erasure completion signal.

[0044] Finally, OOCU removes the address mapping, marks the relevant hardware resource status as idle, records the archiving operation to the audit storage area, returns the resource to the global resource pool, and outputs the resource return status. Example

[0045] See Figure 2 , Figure 2 This is a technical block diagram of the present invention, showing the module structure of the heterogeneous computing power hardware-level isolation and dynamic slicing system based on an independent management and control unit. This embodiment provides a heterogeneous computing power hardware-level isolation and dynamic slicing system based on an independent management and control unit, including a hardware interface module, a physical isolation module, a dynamic scheduling module, and a fault-tolerant module.

[0046] Hardware interface module The hardware interface module includes the following units: An independent power supply module is used to prioritize powering on the node after it is connected to power, to build a PCIe NTB out-of-band management channel, and to establish a management path that is physically isolated from the service data bus. The hardware enumeration unit is used to scan the PCIe configuration space, enumerate the heterogeneous computing hardware of the full node, and identify the hardware specifications of CPU core clusters, GPU stream processors, NPU computing arrays, and FPGA acceleration units. The control locking unit is used to lock the hardware management registers and take over the IOMMU and DMA mapping permissions; The hardware interface module outputs a global physical hardware resource pool.

[0047] Physical isolation module The physical isolation module includes the following units: Domain partitioning unit is used to divide control domains and business isolation domains according to security policies, and to assign a unique domain identifier to each business isolation domain. The access control unit is used to configure access control lists in the IOMMU and PCIe switch, setting that only requests carrying specific domain identifiers are allowed to access the corresponding physical address range. The path fixation unit is used to shield unauthorized interrupts and cached messages and fix the hardware access path; The physical isolation module outputs hardware access policy rules and physical link status signals.

[0048] Dynamic scheduling module The dynamic scheduling module includes the following units: The load acquisition unit is used to collect real-time load data of computing power slices through hardware performance counters, including utilization, power consumption and queue depth. The decision generation unit is used to analyze load data, determine whether the utilization rate exceeds the threshold, and generate expansion or reduction decision instructions. The mapping update unit is used to atomically update the double-buffered address mapping table. After constructing a new mapping table using the double-buffering mechanism and completing the verification, the mapping table activation pointer is atomically switched to achieve quota adjustment without interruption. The dynamic scheduling module outputs the hardware resource quota status after the increase or decrease.

[0049] Fault-tolerant module The fault-tolerant module includes the following units: The anomaly monitoring unit is used to detect hardware error signals, including PCIe uncorrectable errors or ECC errors, and to locate the service isolation domain where the fault occurs. Physical blocking unit, used to control clock gating circuits or PCIe link disable signals, cut off bus connections or clock signals in fault domains; The migration recovery unit is used to send a reset signal to the faulty hardware block, trigger the service migration process to the standby slice, and record the fault log. The fault-tolerant module outputs a service migration completion signal.

[0050] Resource recycling module The resource recycling module includes the following units: The instruction verification unit is used to receive slice termination instructions, verify the initiator's digital signature and permissions, lock the slice isolation domain, and block new access requests. The data erasure unit is used to send hardware-level zeroing instructions to the video memory and memory areas occupied by the slice, and use random data to overwrite the original business data; The resource archiving unit is used to unmap addresses, mark hardware resources as idle, and record archiving operations to the audit storage area. The resource recycling module outputs the state of the resources returning to the global resource pool. Example

[0051] In another implementation, to further illustrate the technical advantages of the present invention, the comparative features of the out-of-band control unit described in this example and the traditional BMC are shown in the table below. As an improved design, the OOCU achieves complete hardware control over the IOMMU and PCIe switch, breaking through the functional limitations of the traditional BMC, which can only access monitoring registers. One possible architecture is that the OOCU establishes an independent out-of-band management channel through the PCIe NTB. This channel is physically isolated from the service data bus, ensuring that the real-time performance and reliability of management commands are unaffected by service load.

[0052] The above describes specific embodiments of the present invention. These embodiments can be combined with each other. For the same or similar concepts or processes, they may not be described again in some embodiments.

[0053] 1. It achieves hardware root-trust level physical isolation, solidifying access paths and isolation policies at the hardware bus level, completely eliminating the "noisy neighbor" effect, unauthorized access risks, and side-channel attack vulnerabilities of traditional software isolation solutions. The host operating system has no permission to modify any isolation rules, and even if the system is compromised, it cannot break through the physical boundary to access unauthorized resources. Simultaneously, it achieves near-zero computing power performance loss and almost no additional operating overhead, fully releasing the hardware's native computing power and increasing cluster resource utilization to more than twice that of traditional solutions.

[0054] 2. It achieves microsecond-level dynamic adjustment of computing power slicing without the business being aware of it. It can complete atomic updates of computing power quotas without interrupting business processes or resetting hardware devices, perfectly adapting to the elastic scheduling requirements of real-time fluctuations in business load. This completely breaks through the core limitation of traditional hardware isolation solutions where static configuration and adjustments inevitably interrupt business operations. Simultaneously, it enables unified management and control of heterogeneous computing power across vendors and architectures, breaking down vendor technology lock-ins and resource silos, and adapting to common scenarios of mixed deployment of various heterogeneous computing power.

[0055] 3. A highly reliable computing power management architecture independent of the host system has been implemented. The management unit operates entirely without relying on the host operating system and virtualization software. Even if the host system crashes, it can still independently execute isolation management, fault blocking, and service migration commands. It can disconnect hardware connections in fault domains at the microsecond level, avoiding systemic crashes caused by single points of failure. At the same time, it enables plug-and-play automated cluster expansion of computing power nodes without manual configuration or maintenance intervention, significantly reducing the deployment difficulty and maintenance costs of large-scale computing power clusters.

Claims

1. A method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on independent management and control units, characterized in that, Includes the following steps: S1. When the node is powered on, it starts the out-of-band management unit independently of the host processor, enumerates and takes over the control of heterogeneous computing hardware, and builds a global resource pool. S2. The out-of-band management unit configures an access control list at the hardware bus level, divides the management domain and the service isolation domain, and solidifies the hardware access path. S3. Receive the business computing power demand instruction, match idle hardware resources, modify the hardware address mapping table to generate hardware computing power slices; S4. Real-time acquisition of computing power slice load data, dynamic update of address mapping table, and uninterrupted adjustment of hardware resource quotas; S5. Monitor hardware anomaly signals, disconnect the hardware bus connection or clock signal of the faulty service isolation domain, and complete the service traffic migration. S6. Receive the slice termination instruction, trigger hardware-level memory clearing, remove address mapping, and reclaim resources to the global resource pool.

2. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The S1 step specifically includes: S1.1, Independent power domain is given priority for power-on, and an out-of-band control channel for PCIe non-transparent bridge (NTB) is constructed; S1.2 Scan the PCIe configuration space and enumerate all node heterogeneous computing hardware; S1.3 Lock the hardware management registers and take over the mapping permissions of the Input / Output Memory Management Unit (IOMMU) and Direct Memory Access (DMA).

3. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The S2 step specifically includes: S2.

1. Divide the control domain and business isolation domain according to the security policy, and assign a unique domain identifier to each business isolation domain; S2.2 Configure access control lists (ACLs) in the IOMMU and PCIe switch to allow only requests carrying specific domain identifiers to access the corresponding physical address range; S2.3, Mask unauthorized interrupt signals and cache consistency messages, and solidify hardware access paths.

4. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The S3 step specifically includes: S3.1 Receive the business computing power demand instruction, search for available hardware resource blocks that meet the conditions in the global physical hardware resource pool, and perform admission verification; S3.2 Create a dedicated hardware address mapping table to map the business virtual hardware address to the actual physical hardware address and set access permission bits; S3.

3. Enable the mapping table, return the slice handle to the business, and the hardware unit verifies the consistency between the domain identifier and the mapping table. After the verification is successful, the hardware computing power slice is officially generated.

5. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The S4 step specifically includes: S4.

1. Real-time acquisition of computing power slice data through hardware performance counter (PMU), and uploading utilization, power consumption and queue depth data through out-of-band channels; S4.2 The internal scheduling algorithm analyzes the load data, determines whether the utilization rate exceeds the threshold, and generates expansion or reduction decisions. S4.

3. Perform atomic operations to update the hardware-level double-buffered address mapping table in the IOMMU. After constructing a new mapping table using the double-buffering mechanism and completing the verification, atomically switch the mapping table activation pointer.

6. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The S5 step specifically includes: S5.1 Listen for hardware error signals, detect PCIe uncorrectable errors (UE) or error correction codes (ECC) errors, and locate the service isolation domain where the fault occurs; S5.2 Control clock gating circuit or PCIe link disable signal to cut off bus connection or clock signal in fault domain; S5.3 Send a reset signal to the faulty hardware block to trigger the service migration process to the backup slice and record the fault log.

7. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, Step S6 specifically includes: S6.1 Receive the slice termination command, verify the initiator's digital signature and permissions, lock the slice isolation domain, and block new access requests; S6.2 Send a hardware-level zeroing command to the video memory and memory area occupied by the slice, and overwrite the original business data with random data; S6.3 Remove address mapping, mark hardware resource status as idle, and archive operation record to audit storage area.

8. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The out-of-band management unit has an independent power domain, powers on before the host CPU, and locks hardware control before the system bus is initialized; the out-of-band management unit has full read and write control over the PCIe configuration space, IOMMU, and address mapping table, and directly intervenes in the hardware access control of the service data path.

9. The method for hardware-level isolation and dynamic slicing of heterogeneous computing power based on an independent management and control unit according to claim 1, characterized in that, The heterogeneous computing hardware includes one or more of the following: CPU core clusters, GPU stream processors, NPU computing arrays, and FPGA acceleration units.

10. A heterogeneous computing power hardware-level isolation and dynamic slicing system based on an independent control unit, used to implement the method described in any one of claims 1-9, characterized in that, include: The hardware interface module is used to prioritize power-on of independent power supplies to build PCIe NTB out-of-band management channels, scan the PCIe configuration space to enumerate heterogeneous computing hardware, lock hardware management registers and take over IOMMU and DMA mapping permissions, and output the global resource pool. The physical isolation module is used to divide the control domain and the business isolation domain according to the security policy, block unauthorized interruptions and cached messages, solidify the hardware access path, and output hardware access policy rules and physical link status signals. The dynamic scheduling module is used to collect computing power slice load data in real time through hardware performance counters, analyze the load data to generate expansion or reduction decision instructions, atomically update the double buffer address mapping table to adjust the quota without interruption, and output the hardware resource quota status after the increase or decrease. The fault tolerance module is used to detect hardware error signals, locate the fault domain, disconnect the hardware bus connection or clock signal of the fault service isolation domain, trigger the service migration process to the backup slice, and output a service migration completion signal. The resource recycling module is used to receive slice termination instructions, verify permissions, trigger hardware-level memory clearing, remove address mapping and archive operation records, and output the resource return to the global resource pool state.

Images