CPU isolation operation method based on isolation scheduling domain under NUMA architecture
By dividing the CPU core into isolated and normal scheduling domains under the NUMA architecture and scheduling processes based on trusted virtual machine tags, the compatibility and performance issues of CPU resource isolation under the NUMA architecture are solved, and fine-grained CPU isolation and memory access optimization are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-17
- Publication Date
- 2026-03-24
AI Technical Summary
Existing technologies struggle to achieve fine-grained CPU resource isolation under NUMA architectures and are incompatible with general x86 architectures, leading to increased cross-node memory access latency or resource contention.
By acquiring the NUMA topology and kernel configuration parameters, the CPU core is divided into isolated scheduling domains and normal scheduling domains. Trusted virtual machine tagged processes are identified and scheduled to the isolated scheduling domain. The kernel module writes the tag parameters, and combined with preset process migration and affinity conditions, fine-grained CPU isolation is achieved.
It improves the adaptability of isolation mechanisms to NUMA architecture characteristics, reduces cross-node latency, enhances resource allocation and memory access locality, and achieves fine-grained logical isolation.
Smart Images
Figure CN121722483A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of virtualization computing technology, specifically to a CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture. Background Technology
[0002] In virtualization scenarios such as cloud computing and multi-tenant deployments, it is necessary to isolate CPU (Central Processing Unit) resources for specific types of virtual machine processes (such as processes corresponding to trusted virtual machines, core business virtual machine processes, etc.) to prevent them from being overtaken by ordinary processes or damaged by cross-domain access. Among them, trusted virtual machines (T-VMs) are the core carriers of trusted computing systems in virtualization environments. Their corresponding processes need to pass the integrity verification of the root of trust and are mainly used to deploy tasks with high security requirements. This is one of the typical application scenarios for virtual machine tag processes.
[0003] A virtual machine process tag is a unique identifier used to accurately identify a target virtual machine process and can be flexibly defined according to the virtual machine application scenario. For example, in a trusted virtual machine scenario, it is a Trusted Virtual Machine Tag (TVMT), composed of a globally unique UUID (Universally Unique Identifier), a local Tid (Local Tag Identifier), and a hash (UUID||Tid) (UUID concatenated with Tid), totaling 32 bits. In other virtual machine scenarios, it can be a core business virtual machine process tag, a dedicated service virtual machine process tag, etc. This tag is generated and distributed by the cloud management center when the trusted virtual machine is created, and is passed down level by level through the virtualization management layer to the host kernel, ultimately embedded in the control block of the trusted virtual machine process, forming a strong "tag-process" binding relationship. Its core function is to provide a basis for the kernel scheduler and process migration logic. By reading the tag, the process type can be quickly distinguished, ensuring that the virtual machine tag process is accurately scheduled to the isolation resource pool. At the same time, it intercepts the illegal access of ordinary processes to isolation resources. It is a key technology carrier for realizing "dynamic diversion" and "runtime protection".
[0004] To further strengthen the security boundary of trusted virtual machines and prevent their CPU core resources from being occupied or damaged by ordinary virtual machines through cross-domain access, virtual machine CPU resource isolation has become a key technical requirement in trusted computing systems. Modern servers commonly employ NUMA (Non-Uniform Memory Access) architecture. In NUMA, memory is divided into multiple nodes, and further categorized as local or remote nodes based on CPU access speed. The memory of local nodes is directly managed by the local memory controller connected to the CPU, without needing to go through a shared bus, thus significantly reducing memory access latency. However, memory access from remote nodes may result in some latency. Therefore, higher demands are placed on the allocation and scheduling of CPU resources, requiring the adaptation to the locality of reference characteristics of the NUMA topology while ensuring isolation, and avoiding performance losses caused by cross-node resource scheduling.
[0005] Currently, the main implementation schemes for virtual machine CPU isolation include static CPU binding, virtualization layer quota limits, and namespace isolation. However, these schemes have significant shortcomings in practical applications: First, they lack fine-grained scheduling constraint mechanisms compatible with the general x86 architecture. Existing schemes either rely on dedicated hardware, resulting in poor compatibility, or only support coarse-grained isolation, unable to dynamically adjust the number and range of CPU cores in the isolation domain according to system configuration or tenant needs. Second, the isolation mechanism is not adapted to the memory access locality characteristic of NUMA architecture. Some schemes, in pursuit of isolation effects, distribute the CPU cores of virtual machines across different NUMA nodes, leading to increased cross-node memory access latency. Other schemes, in order to optimize performance, ignore isolation boundaries and mix virtual machines of different tenants on the same NUMA node, causing resource contention. Summary of the Invention
[0006] The purpose of this invention is to provide a CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture, so as to solve the technical problems existing in related technologies.
[0007] To achieve the above objectives, this invention provides a CPU isolation execution method based on an isolated scheduling domain under a NUMA architecture, comprising:
[0008] Obtain the NUMA topology and kernel configuration parameters, and divide the CPU core into an isolated scheduling domain and a normal scheduling domain based on the NUMA topology and kernel configuration parameters. The isolated scheduling domain is used to schedule and execute tagged processes, and the normal scheduling domain is used to schedule and execute normal processes and Linux operating system tasks.
[0009] In response to the request of the trusted virtual machine creation instruction, the trusted virtual machine tag parameter in the trusted virtual machine creation instruction is obtained. The trusted virtual machine tag parameter is passed to the kernel module of the Linux operating system through the virtualization management layer. The kernel module writes the trusted virtual machine tag parameter into the target process to obtain the target tag process, wherein the target process is generated during the creation of the trusted virtual machine.
[0010] Identify the target tag process. If the target tag process is a tag process that has been written with the trusted virtual machine tag parameters, schedule the target tag process to the isolation scheduling domain; otherwise, schedule the target tag process to the normal scheduling domain.
[0011] After scheduling is completed, the target label process is run according to the preset process migration conditions and preset process affinity conditions.
[0012] Optionally, the kernel configuration parameters include first kernel configuration parameters and second kernel configuration parameters, and the first kernel configuration parameters and the second kernel configuration parameters have different functional configurations. The step of dividing the CPU core into isolated scheduling domains according to the NUMA topology and kernel configuration parameters includes:
[0013] In response to configuring the first kernel configuration parameters in the Kconfig file for the Linux operating system, multiple isolation modes are displayed. In response to the selection operation of multiple isolation modes, the target isolation mode corresponding to the selection operation is determined.
[0014] The target kernel source code in the target isolation mode is determined by the Makefile file of the Linux operating system, wherein the target kernel source code is obtained by adding macro compilation constraints to the kernel source code;
[0015] The kernel starts up, reads the second kernel configuration parameters in the target isolation mode, and determines the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology.
[0016] Optionally, when the target isolation mode is NUMA node-level isolation mode, determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology includes:
[0017] The number corresponding to each node in the NUMA topology is determined, and the nodes corresponding to the numbers within the first preset number are identified as target nodes, wherein the preset number is determined according to the second kernel configuration parameters;
[0018] Write the identifiers of all CPU core sets corresponding to each node in the target node into the isolation mask to obtain the first identifier node;
[0019] Register the first identifier node in the isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
[0020] Optionally, when the target isolation mode is CPU-level isolation mode, determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and NUMA topology includes:
[0021] The number of isolated cores for each node in the NUMA topology is calculated based on the second kernel configuration parameters, and the core identifier corresponding to the number of isolated cores for each node is written into the isolation mask one by one to obtain the second identifier node.
[0022] Register the second identifier node corresponding to the second kernel configuration parameters into an isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
[0023] Optionally, the step of writing the trusted virtual machine label parameters into the target process through the kernel module to obtain the target label process includes:
[0024] The trusted virtual machine label parameters are written into the target process by combining macro compilation constraints in the kernel module with flexible arrays, thus obtaining the target label process.
[0025] Optionally, when the target tag process is a tag process that has already had trusted virtual machine tag parameters written, scheduling the target tag process to the isolation scheduling domain includes:
[0026] Obtain the CPU affinity mask for the isolated scheduling domain;
[0027] When the target label process is a trusted virtual machine label process, the CPU affinity mask of the isolation scheduling domain is assigned to the cpumask field of the target label process.
[0028] Optionally, when the target label process is a label process that has been written with trusted virtual machine label parameters, and after scheduling the target label process to an isolation scheduling domain, the method further includes:
[0029] Determine the first target CPU mask where the target labeled process is located after being scheduled to the isolation scheduling domain;
[0030] When the first target CPU mask does not match the set of scheduled CPU masks, the second target CPU mask with the lowest load is selected from the set of scheduled CPU masks according to the load balancing rules, and the second target CPU mask is assigned to the target label process.
[0031] Optionally, the preset process migration condition is:
[0032] When there is an isolation mask in the target isolation mask set that matches the first isolation mask, the target label process is migrated to any CPU core in the target scheduling domain. Here, the first isolation mask is the isolation mask of the CPU core where the target label process is located, the target isolation mask set is the isolation mask set of all CPU cores corresponding to all nodes in the target scheduling domain, and the target scheduling domain is the isolation scheduling domain or the normal scheduling domain that runs the target label process.
[0033] When all isolation masks in the target isolation mask set do not match the first isolation mask, the target CPU core is determined in the target scheduling domain, and the target label process is migrated to the target CPU core, wherein the NUMA node to which the target CPU core belongs is the same as the NUMA node to which the CPU core of the target label process belongs.
[0034] Optionally, the preset process affinity condition is:
[0035] The CPU affinity mask corresponding to the target tagged process is a subset of the CPU core set corresponding to the target scheduling domain, wherein the target scheduling domain is the isolated scheduling domain or the normal scheduling domain to which the target tagged process belongs.
[0036] The above technical solution divides the CPU core into isolated scheduling domains and normal scheduling domains within the NUMA topology of the Linux operating system, based on the NUMA topology and kernel configuration parameters. This ensures compatibility with general-purpose x86 hardware and allows for fine-grained logical isolation without relying on hardware-specific isolation instructions. During the creation of a trusted virtual machine (TVM), TVM tag parameters are written to the target process to obtain the target tagged process. The target tagged process is then identified again; if it is a TVM tagged process, it is scheduled to the isolated scheduling domain; otherwise, it is scheduled to the normal scheduling domain. After scheduling, the target tagged process is run according to preset process migration and affinity conditions. This improves the adaptability of the isolation mechanism to the characteristics of the NUMA architecture, thereby enhancing the matching degree between resource allocation and memory access locality.
[0037] Other features and advantages of the present invention will be described in detail in the following detailed description section. Attached Figure Description
[0038] Figure 1 This is a schematic diagram illustrating a CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture according to an exemplary embodiment of the present invention.
[0039] Figure 2 This is a schematic diagram illustrating the CPU isolation operation of a trusted virtual machine according to an exemplary embodiment of the present invention.
[0040] Figure 3 This is a flowchart illustrating the trusted virtual machine tag issuance process according to an exemplary embodiment of the present invention.
[0041] Figure 4 This is a schematic diagram illustrating memory node isolation resources in a NUMA architecture according to an exemplary embodiment of the present invention. Detailed Implementation
[0042] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, so as to provide a better understanding of the concept of the present invention, the technical problem solved, the technical features constituting the technical solution, and the technical effects brought about.
[0043] like Figure 1 As shown, Figure 1 This is a schematic diagram illustrating a CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture according to an exemplary embodiment of the present invention. (Refer to...) Figure 1 The method includes;
[0044] S101: Obtain the NUMA topology and kernel configuration parameters, and divide the CPU core into an isolated scheduling domain and a normal scheduling domain according to the NUMA topology and kernel configuration parameters. The isolated scheduling domain is used to schedule and execute tagged processes, and the normal scheduling domain is used to schedule and execute normal processes and Linux operating system tasks.
[0045] S102: In response to the request of the trusted virtual machine creation instruction, obtain the trusted virtual machine tag parameter in the trusted virtual machine creation instruction, pass the trusted virtual machine tag parameter through the virtualization management layer to the kernel module of the Linux operating system, and write the trusted virtual machine tag parameter into the target process through the kernel module to obtain the target tag process, wherein the target process is generated during the creation of the trusted virtual machine;
[0046] S103: Identify the target tag process. If the target tag process is a tag process that has been written with the trusted virtual machine tag parameters, schedule the target tag process to the isolation scheduling domain; otherwise, schedule the target tag process to the normal scheduling domain.
[0047] S104: After scheduling is completed, the target label process is run according to the preset process migration conditions and preset process affinity conditions.
[0048] The above technical solution divides the CPU core into isolated scheduling domains and normal scheduling domains based on the NUMA topology and kernel configuration parameters. This ensures compatibility with general-purpose x86 hardware and allows for fine-grained logical isolation without relying on hardware-specific isolation instructions. During the creation of a trusted virtual machine (TVM), TVM tag parameters are written to the target process to obtain the target tagged process. The target tagged process is then identified again; if it is a TVM tagged process, it is scheduled to the isolated scheduling domain; otherwise, it is scheduled to the normal scheduling domain. After scheduling, the target tagged process is run according to preset process migration and affinity conditions. This improves the adaptability of the isolation mechanism to the characteristics of the NUMA architecture, thereby enhancing the matching degree between resource allocation and memory access locality.
[0049] To enable those skilled in the art to better understand the CPU isolation operation method based on the isolation scheduling domain under the NUMA architecture provided by this invention, the above steps are illustrated in detail below.
[0050] For example, NUMA topology can refer to the processor memory organization method at the hardware level in a multi-core server scenario. The Linux operating system can identify, adapt to, and optimize this hardware topology through the NUMA management mechanism at the kernel level. Kernel configuration parameters can be parameters related to NUMA topology management and process isolation scheduling. For example, kernel configuration parameters can be CONFIG_IEE, DEFNUMS_NODES, and DEFNUMS_CPUS parameters. Among them, CONFIG_IEE can be a non-general kernel configuration parameter, DEFNUMS_NODES can be the default number of nodes in the NUMA topology, and DEFNUMS_CPUS can be the default number of CPU cores. Then, in this embodiment of the invention, the CPU cores can be divided into isolated scheduling domains and ordinary scheduling domains according to the NUMA topology and kernel configuration parameters. The allocated isolated scheduling domains are used for the execution of tagged processes, while the ordinary scheduling domains are used for scheduling and executing processes or Linux operating system tasks. Thus, it is possible to achieve fine-grained logical isolation without the need for hardware-level dedicated isolation instructions, while still being compatible with general x86 hardware.
[0051] In some possible embodiments, the kernel configuration parameters include a first kernel configuration parameter and a second kernel configuration parameter, wherein the first kernel configuration parameter and the second kernel configuration parameter have different functional configurations. The step of dividing the CPU core into isolated scheduling domains based on the NUMA topology and the kernel configuration parameters includes:
[0052] In response to configuring the first kernel configuration parameters in the Kconfig file for the Linux operating system, multiple isolation modes are displayed. In response to the selection operation of multiple isolation modes, the target isolation mode corresponding to the selection operation is determined.
[0053] The target kernel source code in the target isolation mode is determined by the Makefile file of the Linux operating system, wherein the target kernel source code is obtained by adding macro compilation constraints to the kernel source code;
[0054] The kernel starts up, reads the second kernel configuration parameters in the target isolation mode, and determines the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology.
[0055] It should be understood that, such as Figure 2 As shown in this embodiment of the invention, the first kernel configuration parameter can be CONFIG_IEE. A new isolated execution environment configuration item, CONFIG_IEE, is added to the Kconfig file as the master switch for isolation functionality. Multiple isolation mode options can then be displayed on the corresponding screen. For example, the multiple isolation modes set can be NUMA node-level isolation mode and CPU-level isolation mode. This embodiment of the invention does not specifically limit the specific isolation modes. The subsequent configuration of the two isolation modes only takes effect when CONFIG_IEE is enabled, and the two isolation modes are mutually exclusive. Afterwards, the user can select the corresponding isolation mode on the screen to put the system into the target isolation mode.
[0056] The target kernel source code provides the specific logic for implementing the isolation functionality by selecting and compiling corresponding source code modules according to the Kconfig file. The target kernel source code in the target isolation mode can then be determined using the Linux operating system's Makefile, dynamically compiling the corresponding isolation function modules. When isolation is not enabled, redundant compilation items are not introduced to ensure system compatibility. These isolation function modules can be scheduling domain initialization or CPU mask management modules; this embodiment of the invention does not specifically limit their nature. The target kernel source code is obtained by adding macro compilation constraints to the kernel source code. Afterward, the kernel boots, reads the second kernel configuration parameters in the target isolation mode, and determines the isolated scheduling domain in the CPU core based on these parameters and the NUMA topology.
[0057] In one possible manner, when the target isolation mode is NUMA node-level isolation mode, the step of determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology includes:
[0058] The number corresponding to each node in the NUMA topology is determined, and the nodes corresponding to the numbers within the first preset number are identified as target nodes, wherein the preset number is determined according to the second kernel configuration parameters;
[0059] Write the identifiers of all CPU core sets corresponding to each node in the target node into the isolation mask to obtain the first identifier node;
[0060] Register the first identifier node in the isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
[0061] It should be understood that NUMA node-level isolation mode can be used by systems that support NUMA architecture. When the target isolation mode is NUMA node-level isolation mode, the second kernel configuration parameter can be DEFNUMS_NODES. When determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameter and the NUMA topology, the first DEFNUMS_NODES nodes can be selected. The set of CPU cores corresponding to the node can be obtained through numa_node_cpus_ptr() to construct the isolation scheduling domain. At the same time, the nodes corresponding to DEFNUMS_NODES are traversed, and all CPU core identifiers within the node are written into the isolation mask (isolated_cpus) to obtain the first identifier node. The first identifier node is then registered in the isolation scheduling domain to obtain the isolation scheduling domain in the CPU core. The remaining nodes are assigned to the normal scheduling domain. This ensures that the system executes scheduling according to the isolation policy, prevents resource cross-use, and improves system security and isolation.
[0062] In one possible manner, when the target isolation mode is CPU-level isolation mode, determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology includes:
[0063] The number of isolated cores for each node in the NUMA topology is calculated based on the second kernel configuration parameters, and the core identifier corresponding to the number of isolated cores for each node is written into the isolation mask one by one to obtain the second identifier node.
[0064] Register the second identifier node corresponding to the second kernel configuration parameters into an isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
[0065] It should be understood that CPU-level isolation mode can be used for systems without NUMA architecture (UMA) or requiring fine-grained isolation. When the target isolation mode is CPU-level isolation mode, the second kernel configuration parameter can be DEFNUMS_CPUS. Within each node of the NUMA topology, the first (DEFNUMS_CPUS / total number of nodes) cores are selected and allocated to the isolation scheduling domain, achieving resource separation between trusted virtual machine processes and other tasks. Simultaneously, the number of cores requiring isolation for each node is calculated according to DEFNUMS_CPUS, and the core identifier is written into the isolation mask one by one to obtain the second identifier node. The second identifier node corresponding to the second kernel configuration parameter is registered in the isolation scheduling domain to obtain the isolation scheduling domain in the CPU cores. The remaining CPU core set is allocated to the normal scheduling domain, thereby ensuring that the system executes scheduling according to the isolation policy, preventing resource cross-use, and improving system security and isolation.
[0066] The partitioned isolated scheduling domains and ordinary scheduling domains can then be verified, as follows.
[0067] Determine the verification dimensions: Based on the divided isolated scheduling domain and normal scheduling domain, perform verification on the attribution relationship between CPU cores and NUMA topology in the isolated scheduling domain and the range of CPU core sets in the isolated scheduling domain and normal scheduling domain;
[0068] Perform attribution verification: Call the system topology query interface to obtain the actual NUMA node affiliation of all CPU cores in the isolated scheduling domain, and compare it with the NUMA node range determined in the partitioning scheme;
[0069] Perform set range verification: compare the CPU core sets of the isolated scheduling domain and the normal scheduling domain to check if there is any overlap; at the same time, check the reference relationship between domains to confirm that the CPU cores of the isolated scheduling domain have been excluded from the task scheduling logic of the normal scheduling domain.
[0070] Execute abnormal adjustment: If the attribution relationship verification does not match, or there is an overlap in the set range, or the ordinary scheduling domain does not exclude the core of the isolated scheduling domain, then backtrack to the above-described isolated scheduling domain and ordinary scheduling domain, re-select CPU cores, prioritize the addition of CPU cores that are consistent with the NUMA nodes of the partitioning scheme, remove CPU cores that exceed the preset range or cause the set to overlap, and repeat the above steps until the verification passes, thus obtaining the isolated scheduling domain and ordinary scheduling domain.
[0071] The above technical solution is compatible with general x86 hardware, does not rely on hardware-level dedicated isolation instructions, achieves dynamic configuration of scheduling domains by modifying the kernel source code, supports flexible division of CPU core range, and realizes fine-grained logical isolation.
[0072] For example, the trusted virtual machine creation command is issued through a cloud platform management system, which can be a cloud platform based on Linux kernel version 5.4 (compatible with x86 and ARMv8 architectures) and OpenStack Train version. During the trusted virtual machine creation process, the trusted virtual machine tag parameters are passed level by level through the virtualization management layer to the Linux operating system kernel module. Specifically, such as... Figure 3 As shown, vCPUs are virtual CPUs, and memory slots are memory slots. The virtualization management layer includes the Nova layer (Nova Service Layer), the LibVirt layer (LibVirt Abstraction Layer), and the Qemu layer (Qemu Virtualization Engine Layer). Trusted virtual machine parameters pass through the Nova layer, LibVirt layer, and Qemu layer sequentially to reach the KVM module (Kernel-based Virtual Machine) in the Linux operating system kernel. The IOCTL (tid) system (Input / Output Control) schedules the trusted virtual machine parameters from the Qemu layer to the KVM module. Then, the KVM module can write the trusted virtual machine tag parameters into the target process, obtaining the target tagged process. The target tagged process is unique character data embedded in the process control block.
[0073] In one possible manner, the step of writing the trusted virtual machine label parameters into the target process via a kernel module to obtain the target label process includes:
[0074] The trusted virtual machine label parameters are written into the target process by combining macro compilation constraints in the kernel module with flexible arrays, thus obtaining the target label process.
[0075] It should be understood that the actual writing process may include the following steps: In the kernel process control block, a placeholder array of length 0 is defined at the end of the structure using a combination of macro compilation constraints and flexible arrays. Through dynamic memory allocation, the trusted virtual machine tag parameters are written into the target process, resulting in the target tag process. This process dynamically allocates memory for the corresponding field only when the isolated execution environment is enabled; ordinary processes shield the read / write operations of this field. Since ordinary processes do not allocate this space, no additional memory overhead is incurred. This reduces system resource consumption while ensuring tag access security and field isolation.
[0076] During the virtual machine creation command issuance process, the trusted virtual machine label parameters are passed level by level from the cloud platform virtualization management layer to the kernel module, written into the label field of the target process, and establishing a strong binding relationship between the label and the process lifecycle. Specifically, as follows... Figure 4 As shown, when the cloud platform management system issues a trusted virtual machine creation command, the command carries a trusted virtual machine tag parameter. The specific steps are as follows, where VM refers to a virtual machine.
[0077] The trusted virtual machine (TVMT) tag parameters are passed step-by-step through the virtualization management layer to the operating system kernel module of the compute node. The transmission path includes the OpenStack compute component Nova, the virtualization management framework LibVirt, and the underlying virtualization tool QEMU. QEMU, acting as a user-space agent, interacts with the KVM module in kernel space via the IOCTL system call to pass the TVMT parameters to the kernel layer. In the KVM module's entry function, the system parses and verifies the passed-in TVMT tag parameters, dynamically expands the process control block during process creation, and writes the TVMT tag field into it. The operating system uses type checking and permission verification mechanisms to ensure that only the trusted virtual machine creation process carries a valid tag identifier, providing a basis for subsequent CPU isolation scheduling.
[0078] In the specific execution process, the system receives a trusted virtual machine creation instruction from user space, parses the trusted virtual machine tag parameter carried in the instruction, passes the trusted virtual machine tag parameter to the kernel process creation interface, and writes it into the process control block field during process initialization; and establishes a binding relationship between the tag field and the target process for subsequent scheduling policy identification.
[0079] For example, after process creation, a target-labeled process is generated. This target-labeled process can then be identified again to determine if it carries a label, and its region can be allocated accordingly. If the target-labeled process is one that has had its trusted virtual machine label parameters written to it, it is scheduled to the isolated scheduling domain; otherwise, it is scheduled to the normal scheduling domain. The isolated scheduling domain can be a dedicated CPU resource partition allocated to high-security, high-priority processes in a Linux operating system; the normal scheduling domain can be a shared CPU resource partition allocated to general, low-priority processes in a Linux operating system.
[0080] In possible ways, when the target tag process is a tag process that has been written with trusted virtual machine tag parameters, the target tag process is scheduled to the isolation scheduling domain, including:
[0081] Obtain the CPU affinity mask for the isolated scheduling domain;
[0082] When the target label process is a trusted virtual machine label process, the CPU affinity mask of the isolation scheduling domain is assigned to the cpumask field of the target label process.
[0083] It should be understood that the CPU affinity mask serves as a core rule carrier in the Linux operating system for defining the "CPU core range that a process / thread can run on". When the target labeled process is a trusted virtual machine labeled process, the CPU affinity mask of the isolation scheduling domain can be obtained. By assigning the CPU affinity mask to the cpumask field of the target labeled process, the target labeled process can be assigned to the isolation scheduling domain.
[0084] When the target label is a normal process, the target label process is assigned to the normal scheduling domain by assigning the normal scheduling domain mask to the target label process. Through this process, the trusted virtual machine process is confined to an isolated CPU set during the creation phase, thus avoiding the mixed scheduling of different types of processes on physical cores from the source.
[0085] In one possible manner, when the target label process is a label process that has been written with trusted virtual machine label parameters, and after scheduling the target label process to an isolation scheduling domain, the method further includes:
[0086] Determine the first target CPU mask where the target labeled process is located after being scheduled to the isolation scheduling domain;
[0087] When the first target CPU mask does not match the set of scheduled CPU masks, the second target CPU mask with the lowest load is selected from the set of scheduled CPU masks according to the load balancing rules, and the second target CPU mask is assigned to the target label process.
[0088] It should be understood that before the target labeled process is added to the scheduling queue, the system adds judgment logic to the scheduling function to check whether the CPU selected by the target labeled process is in the scheduling CPU mask set. If the CPU number matches, the target labeled process is directly enqueued; if it does not match, the second target CPU mask with the lowest current load is selected from the scheduling CPU mask set for execution according to the load balancing strategy. This mechanism ensures that trusted virtual machine processes always run in the isolated scheduling domain, while ordinary processes run in the ordinary scheduling domain, without interfering with each other.
[0089] The above method adapts to NUMA architecture topology, prioritizes scheduling within the same scheduling domain on the same node, balances isolation boundaries and memory access performance, and reduces cross-node latency loss.
[0090] For example, after the target label process is scheduled, the target label process can be run according to the preset process migration conditions and preset process affinity conditions.
[0091] The preset process migration condition can be as follows: when there is an isolation mask in the target isolation mask set that matches the first isolation mask, the target labeled process is migrated to any CPU core in the target scheduling domain. Here, the first isolation mask is the isolation mask of the CPU core where the target labeled process resides, the target isolation mask set is the set of isolation masks for all CPU cores corresponding to all nodes in the target scheduling domain, and the target scheduling domain is either the isolation scheduling domain running the target labeled process or a normal scheduling domain. When none of the isolation masks in the target isolation mask set match the first isolation mask, a target CPU core is determined in the target scheduling domain, and the target labeled process is migrated to the target CPU core. Here, the NUMA node to which the target CPU core belongs is the same as the NUMA node to which the CPU core of the target labeled process belongs.
[0092] The preset process affinity condition can be: the CPU affinity mask corresponding to the target tag process is a subset of the CPU core set corresponding to the target scheduling domain, wherein the target scheduling domain is the isolated scheduling domain or the normal scheduling domain to which the target tag process belongs.
[0093] Specifically, during the execution of the target tagged process, preset process migration conditions and preset process affinity conditions are added. When the system triggers process migration, it can run according to the preset process migration conditions. During execution, when the target scheduling domain is an isolated scheduling domain, it first obtains the first isolation mask of the CPU where the target tagged process resides and the target isolation mask set corresponding to the isolated scheduling domain in the system. If the first isolation mask belongs to the target isolation mask set, migration is allowed; otherwise, a target CPU is reselected from the CPU set of the isolated scheduling domain, prioritizing the target CPU core that is in the same NUMA memory node as the CPU core of the target tagged process to reduce the performance impact of cross-node access. Through this logic, it is ensured that the trusted virtual machine process only migrates within the isolated scheduling domain, preventing it from being mistakenly scheduled to the ordinary scheduling domain.
[0094] The specific implementation process is as follows: Retrieve the process control block of the target tagged process, extract the identifier of its target scheduling domain, and match the CPU core set corresponding to that target scheduling domain identifier as a candidate CPU set. The isolation mask in the candidate CPU set is the target isolation mask set. Obtain the NUMA node number to which the CPU core running the target tagged process belongs; traverse the candidate CPU set, filter out target CPU cores whose NUMA node number matches the CPU core number running the target tagged process, forming a sub-candidate set, prioritizing CPU resources on the same node; if the sub-candidate set is not empty, select the target CPU from this set according to load balancing rules; if the sub-candidate set is empty, directly select the CPU with the lowest load from the candidate CPU set as the target CPU.
[0095] The process migration process also includes preset process affinity conditions to enhance the CPU mask validity judgment mechanism. When setting process CPU affinity, the Linux operating system determines the allowed CPU set range based on the process type. When the target scheduling domain is an isolated scheduling domain and the process is detected as a trusted virtual machine label process, its corresponding CPU affinity mask must be a subset of the isolated scheduling domain CPU set; if the mask contains CPUs from the normal scheduling domain, the system returns an error code indicating that the operating system does not allow it. For ordinary processes and system processes, their affinity masks can only be a subset of the normal scheduling domain CPU set and must not contain CPUs from the isolated scheduling domain. Simultaneously, the TVMT field is hidden to prevent user-space programs from illegally tampering with the label, strengthening the isolation boundary.
[0096] The overall implementation process is as follows: The host machine loads the kernel and scheduler module with the isolated execution environment enabled. It detects and obtains the system's NUMA topology through the kernel's `numa_node_cpus_ptr()` interface, providing basic information for subsequent CPU domain partitioning. Based on the NUMA nodes and kernel configuration parameters, the CPU cores are divided into isolated scheduling domains for trusted virtual machines and ordinary scheduling domains for ordinary virtual machines. An isolated scheduling domain data structure is created according to the partitioning scheme, registered to the scheduling framework, and the set of cores within the domain is fixed using a CPU mask. When a virtual machine is created, the kernel assigns a trusted label field to the process and completes the binding operation between the label and the process. When a process is woken up or scheduled, the scheduler reads the information of the target labeled process, schedules the trusted virtual machine labeled process to the isolated scheduling domain, and schedules the ordinary process to the ordinary scheduling domain. Preset process migration conditions and preset process affinity conditions are embedded in the process migration and CPU affinity logic to ensure that trusted virtual machine processes only run within the isolated scheduling domain, and to verify CPU mask modifications to prevent unauthorized scheduling between domains.
[0097] The above technical solution is compatible with general-purpose x86 hardware, does not rely on hardware-level dedicated isolation instructions, and achieves dynamic configuration of scheduling domains by modifying the kernel source code. It supports flexible division of CPU core ranges and achieves fine-grained logical isolation. It adapts to NUMA architecture topologies, prioritizes scheduling within the same scheduling domain on the same node, balances isolation boundaries and memory access performance, and reduces cross-node latency. Load balancing migration, NUMA-optimized migration, and affinity settings provide triple protection to intercept dynamic kernel operations and illegal configuration modifications. It strengthens logical isolation boundaries for computing scenarios, ensuring that tagged virtual machines have dedicated CPU resources and form a scheduling domain-level secure isolation from ordinary virtual machines.
[0098] Besides the application scenario of using a trusted virtual machine as a tagged virtual machine process in this embodiment, the present invention can also be adapted to other virtualization scenarios. For example, for core business virtual machine processes, a core business virtual machine tag (such as 32-bit character data containing business identifier and priority) can be generated through the cloud management center, passed to the kernel through the same virtualization management layer, and bound to the process control block. According to the scheduling domain division, process binding and protection logic of this embodiment, the CPU isolation operation of the core business virtual machine process can be realized. As another example, for dedicated service virtual machine processes (such as database virtual machines and encryption service virtual machines), the tag format (such as a combination field containing service type and security level) can be customized. Its tag issuance, process binding and runtime protection mechanism are consistent with this embodiment. Only the tag verification rules (such as service type legality verification and security level adaptation verification) need to be adjusted according to the scenario requirements.
[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A CPU isolation execution method based on isolated scheduling domains under a NUMA architecture, characterized in that, include: Obtain the NUMA topology and kernel configuration parameters, and divide the CPU core into an isolated scheduling domain and a normal scheduling domain based on the NUMA topology and kernel configuration parameters. The isolated scheduling domain is used to schedule and execute tagged processes, and the normal scheduling domain is used to schedule and execute normal processes and Linux operating system tasks. In response to the request of the trusted virtual machine creation instruction, the trusted virtual machine tag parameter in the trusted virtual machine creation instruction is obtained. The trusted virtual machine tag parameter is passed to the kernel module of the Linux operating system through the virtualization management layer. The kernel module writes the trusted virtual machine tag parameter into the target process to obtain the target tag process, wherein the target process is generated during the creation of the trusted virtual machine. Identify the target tag process. If the target tag process is a tag process that has been written with the trusted virtual machine tag parameters, schedule the target tag process to the isolation scheduling domain; otherwise, schedule the target tag process to the normal scheduling domain. After scheduling is completed, the target label process is run according to the preset process migration conditions and preset process affinity conditions.
2. The CPU isolation operation method based on isolated scheduling domain under NUMA architecture according to claim 1, characterized in that, The kernel configuration parameters include a first kernel configuration parameter and a second kernel configuration parameter, and the first kernel configuration parameter and the second kernel configuration parameter have different functional configurations. The step of dividing the CPU core into isolated scheduling domains based on the NUMA topology and kernel configuration parameters includes: In response to configuring the first kernel configuration parameters in the Kconfig file for the Linux operating system, multiple isolation modes are displayed. In response to the selection operation of multiple isolation modes, the target isolation mode corresponding to the selection operation is determined. The target kernel source code in the target isolation mode is determined by the Makefile file of the Linux operating system, wherein the target kernel source code is obtained by adding macro compilation constraints to the kernel source code; The kernel starts up, reads the second kernel configuration parameters in the target isolation mode, and determines the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology.
3. The CPU isolation operation method based on isolated scheduling domain under NUMA architecture according to claim 2, characterized in that, When the target isolation mode is NUMA node-level isolation mode, the step of determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and the NUMA topology includes: The number corresponding to each node in the NUMA topology is determined, and the nodes corresponding to the numbers within the first preset number are identified as target nodes, wherein the preset number is determined according to the second kernel configuration parameters; Write the identifiers of all CPU core sets corresponding to each node in the target node into the isolation mask to obtain the first identifier node; Register the first identifier node in the isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
4. The CPU isolation operation method based on isolated scheduling domain under NUMA architecture according to claim 2, characterized in that, When the target isolation mode is CPU-level isolation mode, determining the isolation scheduling domain in the CPU core based on the second kernel configuration parameters and NUMA topology includes: The number of isolated cores for each node in the NUMA topology is calculated based on the second kernel configuration parameters, and the core identifier corresponding to the number of isolated cores for each node is written into the isolation mask one by one to obtain the second identifier node. Register the second identifier node corresponding to the second kernel configuration parameters into an isolation scheduling domain to obtain the isolation scheduling domain in the CPU core.
5. A CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture according to claim 1, characterized in that, The step of writing the trusted virtual machine label parameters into the target process through the kernel module to obtain the target label process includes: The trusted virtual machine label parameters are written into the target process by combining macro compilation constraints in the kernel module with flexible arrays, thus obtaining the target label process.
6. The CPU isolation operation method based on isolated scheduling domain under NUMA architecture according to claim 1, characterized in that, When the target tag process is a tag process that has already had its trusted virtual machine tag parameters written, scheduling the target tag process to the isolation scheduling domain includes: Obtain the CPU affinity mask for the isolated scheduling domain; When the target label process is a trusted virtual machine label process, the CPU affinity mask of the isolation scheduling domain is assigned to the cpumask field of the target label process.
7. A CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture according to claim 1, characterized in that, When the target label process is a label process that has been written with trusted virtual machine label parameters, and after scheduling the target label process to an isolation scheduling domain, the method further includes: Determine the first target CPU mask where the target labeled process is located after being scheduled to the isolation scheduling domain; When the first target CPU mask does not match the set of scheduled CPU masks, the second target CPU mask with the lowest load is selected from the set of scheduled CPU masks according to the load balancing rules, and the second target CPU mask is assigned to the target label process.
8. A CPU isolation execution method based on an isolated scheduling domain under a NUMA architecture according to any one of claims 1-7, characterized in that, The preset process migration conditions are: When there is an isolation mask in the target isolation mask set that matches the first isolation mask, the target label process is migrated to any CPU core in the target scheduling domain. Here, the first isolation mask is the isolation mask of the CPU core where the target label process is located, the target isolation mask set is the isolation mask set of all CPU cores corresponding to all nodes in the target scheduling domain, and the target scheduling domain is the isolation scheduling domain or the normal scheduling domain that runs the target label process. When all isolation masks in the target isolation mask set do not match the first isolation mask, the target CPU core is determined in the target scheduling domain, and the target label process is migrated to the target CPU core, wherein the NUMA node to which the target CPU core belongs is the same as the NUMA node to which the CPU core of the target label process belongs.
9. A CPU isolation operation method based on an isolated scheduling domain under a NUMA architecture according to claim 8, characterized in that, The preset process affinity condition is: The CPU affinity mask corresponding to the target tagged process is a subset of the CPU core set corresponding to the target scheduling domain, wherein the target scheduling domain is the isolated scheduling domain or the normal scheduling domain to which the target tagged process belongs.