Virtual machine running control method and device, computer device and storage medium

Abstract

The present disclosure provides a virtual machine running control method and device, computer equipment and a storage medium, wherein the method comprises: obtaining non-uniform memory access (NUMA) node configuration information of a virtual machine; the NUMA node configuration information is determined according to a host NUMA topology relationship of a host running the virtual machine; the host NUMA topology relationship is used to indicate the distance between a physical central processing unit and a physical memory space in the host; using a virtual machine monitor, converting the NUMA node configuration information into target configuration information in a target format, and configuring the target configuration information as a target start parameter of a child operating system of the virtual machine; using the child operating system, creating each target virtual NUMA node corresponding to the virtual machine according to the target configuration information carried by the target start parameter. The present disclosure can accurately transfer the host NUMA topology relationship to the virtual machine without the help of ACPI.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a virtual machine operation control method, apparatus, computer equipment, and storage medium. Background Technology

[0002] To improve the performance of business software running in a virtual machine's guest operating system, the NUMA framework in the guest operating system can typically be optimized. The optimization effect increases significantly with the size of the virtual machine. A common approach to optimizing the NUMA framework is to pass the NUMA topology of the host machine to the virtual machine, enabling the virtual machine to optimize its own NUMA framework based on the host's NUMA topology.

[0003] Conventional optimization methods typically utilize Advanced Configuration Power Interface (ACPI) tables to transmit host NUMA topology. This includes configuring Static Resource Affinity Tables (SRAT) and System Locality Information Tables (SLIT). However, because ACPI is a complex subsystem with a large amount of code and complex information, using SRAT and SLIT based on ACPI configuration for topology transmission not only increases the difficulty of transmission but also increases the possibility of code intrusion, posing a significant security risk. Summary of the Invention

[0004] This disclosure provides at least one virtual machine operation control method, apparatus, computer device, and storage medium.

[0005] In a first aspect, embodiments of this disclosure provide a virtual machine operation control method, including:

[0006] Obtain NUMA node configuration information for the virtual machine; the NUMA node configuration information is determined based on the host NUMA topology corresponding to the host running the virtual machine; the host NUMA topology is used to indicate the distance between the physical central processing unit and the physical memory space in the host.

[0007] Using a virtual machine monitor, the NUMA node configuration information is converted into target configuration information with a target format, and the target configuration information is configured as the target boot parameters of the virtual machine's sub-operating system;

[0008] The sub-operating system uses the target configuration information carried by the target startup parameters to create each target virtual NUMA node corresponding to the virtual machine.

[0009] In one possible implementation, the sub-operating system creates each target virtual NUMA node corresponding to the virtual machine based on the target configuration information carried by the target boot parameters, including:

[0010] Using the node information conversion process in the sub-operating system, each target virtual NUMA node corresponding to the virtual machine is created based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units.

[0011] In one possible implementation, based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units, each target virtual NUMA node is created, including:

[0012] The target memory space corresponding to each virtual NUMA node identifier is added to the virtual memory manager corresponding to the virtual machine for management; and

[0013] Each virtual central processing unit in the list of virtual central processing units corresponding to each virtual NUMA node identifier is bound to the virtual NUMA node identifier to obtain the target virtual NUMA node corresponding to each virtual NUMA node identifier.

[0014] In one possible implementation, obtaining NUMA node configuration information for non-uniform memory access virtual machines includes:

[0015] Before starting the virtual machine monitor, determine the topology configuration interface developed for the virtual machine monitor, and configure the NUMA node configuration information using the topology configuration interface according to the host NUMA topology.

[0016] In response to starting the virtual machine monitor, the configured NUMA node configuration information is obtained.

[0017] In one possible implementation, a virtual machine monitor is used to convert the NUMA node configuration information into target configuration information with a target format, including:

[0018] Using the virtual machine monitor, the target memory space and target host NUMA node indicated by the NUMA node configuration information are determined; the target host NUMA node is one of multiple host NUMA nodes included in the host NUMA topology.

[0019] From the total memory space corresponding to the virtual machine, determine the physical address range that matches the target memory space;

[0020] The target configuration information is determined based on the physical address range and the NUMA node configuration information excluding the target memory space and the target host NUMA node.

[0021] In one possible implementation, determining the physical address range that matches the target memory space from the total memory space corresponding to the virtual machine includes:

[0022] Determine the device memory space allocated to each virtual device in the virtual machine;

[0023] Based on the total memory space and the device address range corresponding to the device memory space, determine the physical address range that matches the target memory space.

[0024] In one possible implementation, after determining the physical address range that matches the target memory space, the method further includes:

[0025] The target memory space corresponding to the physical address range is bound to the target host NUMA node, and each virtual CPU indicated by the NUMA node configuration information is bound to each physical CPU in the target host NUMA node in pairs.

[0026] Secondly, embodiments of this disclosure also provide a virtual machine operation control device, comprising:

[0027] The acquisition module is used to acquire non-uniform memory access NUMA node configuration information for virtual machines; the NUMA node configuration information is determined based on the host NUMA topology relationship corresponding to the host running the virtual machine; the host NUMA topology relationship is used to indicate the distance between the physical central processing unit and the physical memory space in the host.

[0028] The configuration module is used to convert the NUMA node configuration information into target configuration information with a target format using a virtual machine monitor, and configure the target configuration information as the target boot parameters of the virtual machine's sub-operating system;

[0029] A creation module is used to create each target virtual NUMA node corresponding to the virtual machine using the sub-operating system based on the target configuration information carried by the target boot parameters.

[0030] Thirdly, an optional implementation of this disclosure also provides a computer device, a processor, and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the steps of the first aspect above, or any possible implementation of the first aspect, are performed.

[0031] Fourthly, an optional implementation of this disclosure also provides a computer-readable storage medium storing a computer program that, when run, performs the steps of the first aspect or any possible implementation of the first aspect.

[0032] For a description of the effects of the aforementioned virtual machine operation control device, computer equipment, and computer-readable storage medium, please refer to the description of the aforementioned virtual machine operation control method; it will not be repeated here.

[0033] The virtual machine operation control method, apparatus, computer device, and storage medium provided in this disclosure, after obtaining NUMA node configuration information, convert the node configuration information into target configuration information with a target format through a Virtual Machine Monitor (VMM). This conversion of NUMA node configuration information yields target configuration information that represents the host NUMA topology relationship to be transferred. By configuring the target configuration information in the target boot parameters of the sub-operating system, the target configuration information in the target boot parameters can be used to create various target virtual NUMA nodes in the virtual machine that match the transferred host NUMA topology relationship when the sub-operating system starts, thus completing the transfer and conversion of the host NUMA topology relationship to the virtual machine. The entire process of transferring and converting the host NUMA topology relationship does not require the use of ACPI-based configuration of ACPI tables, achieving a lightweight approach, reducing the difficulty of transfer, and effectively reducing the risk of code intrusion and improving the operational security of the virtual machine because it does not require large-scale ACPI-related code.

[0034] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0036] Figure 1 A flowchart of a virtual machine operation control method provided in an embodiment of this disclosure is shown;

[0037] Figure 2 This illustration shows a process for creating various target virtual NUMA nodes using a node information conversion process, as provided in an embodiment of this disclosure.

[0038] Figure 3a A schematic diagram illustrating the specific implementation process of a topology relationship transfer method in the prior art is shown.

[0039] Figure 3b This illustration shows a schematic diagram of a specific implementation process of a virtual machine operation control method provided in an embodiment of this disclosure;

[0040] Figure 4 A schematic diagram of a virtual machine operation control device provided in an embodiment of this disclosure is shown;

[0041] Figure 5 A schematic diagram of the structure of a computer device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown herein can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0043] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0044] In this article, "multiple or several" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0045] Research has found that to address security issues in Platform as a Service (PaaS), a secure container solution based on virtualization technology is typically employed. Secure containers utilize underlying hardware-assisted virtualization technology to isolate containers, ensuring that virtual machines within each container can run independently. Secure containers usually contain a Virtual Machine Controller (VMM) and a Guest OS. When there is a need to transfer host NUMA topology relationships to virtual machines, the VMM can use ACPI-configured SRAT and SLIT tables to transfer these relationships to the Guest OS. The Guest OS can then use its deployed ACPI subsystem to parse the SRAT and SLIT tables to obtain the transferred host NUMA topology relationships and use these relationships to create its own NUMA topology. However, VMMs can come in various types, such as the virtual operating system emulator QEMU, the cloud management program Cloud-Hypervisor, and the virtualization service Firecracker. Not all types of VMMs support transferring topology relationships using ACPI-configured tables, thus this method suffers from poor versatility. Furthermore, if topology relationship transfer is to be performed using tables configured with ACPI, the ACPI subsystem needs to be deployed in both the VMM and the Guest OS. However, since ACPI is a complex subsystem with a large amount of code and complex information, the method of transferring topology relationships using tables configured with ACPI will not only increase the difficulty of transfer and code complexity, but also increase the risk of code intrusion, affecting the operational security of the virtual machine.

[0046] Based on the above research, this disclosure provides a virtual machine operation control method, apparatus, computer device, and storage medium. After obtaining the configuration information for NUMA nodes, the VMM converts the node configuration information into target configuration information with a target format. This enables the conversion of NUMA node configuration information to obtain target configuration information that represents the host NUMA topology relationship to be transferred. By configuring the target configuration information in the target boot parameters of the sub-operating system, the target configuration information in the target boot parameters can be used when the sub-operating system starts to create various target virtual NUMA nodes in the virtual machine that match the transferred host NUMA topology relationship, completing the transfer and conversion of the host NUMA topology relationship to the virtual machine. The entire process of transferring and converting the host NUMA topology relationship does not require the use of ACPI-based configuration of ACPI tables, achieving a lightweight approach, reducing the difficulty of transfer, and effectively reducing the risk of code intrusion and improving the operational security of the virtual machine because it does not require large-scale ACPI-related code.

[0047] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventor's contribution to this disclosure.

[0048] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0049] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0050] It should be noted that the specific terms mentioned in the embodiments of this disclosure include:

[0051] NUMA: Non-Uniform Memory Access; NUMA topology is used to characterize the distance between the central processing unit and the physical memory space.

[0052] Cmdline: A kernel startup command-line parameter;

[0053] The lscpu command: A Linux command used to query information about the CPU architecture.

[0054] numactl – hardware command: In Linux, this command is used to check if NUMA is directly supported. It is supported if there are multiple NUMA nodes.

[0055] To facilitate understanding of this embodiment, a virtual machine operation control method disclosed in this disclosure will first be described in detail. The execution subject of the virtual machine operation control method provided in this disclosure is generally a terminal device or other processing device with certain computing capabilities. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, personal digital assistant device (PDA), handheld device, computer device, etc. In some possible implementations, the virtual machine operation control method can be implemented by the processor calling computer-readable instructions stored in the memory.

[0056] The virtual machine operation control method provided in this disclosure embodiment will be described below using the server as the execution subject as an example.

[0057] like Figure 1 The flowchart shown is a method for controlling the operation of a virtual machine according to an embodiment of this disclosure, which may include the following steps:

[0058] S101: Obtain NUMA node configuration information for non-uniform memory access for virtual machines; the NUMA node configuration information is determined based on the host NUMA topology relationship corresponding to the host running the virtual machine; the host NUMA topology relationship is used to indicate the distance between the physical central processing unit and the physical memory space in the host.

[0059] Here, the host can be a physical machine running a virtual machine. The host NUMA topology can include multiple host NUMA nodes. Each NUMA node can include at least one physical central processing unit (CPU) and at least one memory space. The physical CPU in each host NUMA node is closer to the physical memory space in that NUMA node than to the physical memory space in other NUMA nodes, resulting in faster read speeds.

[0060] NUMA node configuration information can be configured on the operation and maintenance side according to the host NUMA topology relationship. It is used to indicate the node information corresponding to the virtual NUMA node that needs to be added to the virtual machine. Specifically, it can include the newly added virtual NUMA node, the virtual central processing unit (hereinafter referred to as vcpu) allocated in the virtual NUMA node, the physical memory space occupied by the virtual NUMA node, and the host NUMA node corresponding to these memory spaces.

[0061] In practical implementation, a VMM deployed in a secure container can be used to obtain NUMA node configuration information for virtual machines. It should be noted that the VMM provided in this embodiment is a VMM developed using the Rust language, referred to as a Rust-VMM based VMM. This VMM, in addition to possessing all the functionalities of a traditional VMM, can also utilize its developed Application Programming Interface (API) to obtain NUMA node configuration information.

[0062] For example, the number of new virtual NUMA nodes and the node information for each virtual NUMA node can be determined on the operations and maintenance side based on the host NUMA topology. Then, the NUMA node configuration information can be configured according to the node configuration information format and sent to the rust-vmm-based VMM. In this way, the NUMA node configuration information can be obtained using the rust-vmm-based VMM.

[0063] In one embodiment, S101 can be implemented according to the following steps:

[0064] Before starting the virtual machine monitor, determine the topology configuration interface developed for the virtual machine monitor, and configure the NUMA node configuration information using the topology configuration interface according to the host NUMA topology.

[0065] In response to starting the virtual machine monitor, obtain the configured NUMA node configuration information.

[0066] Here, the topology configuration interface is an API pre-developed for rust-vmm based VMM. This API is specifically designed for configuring NUMA nodes and is only effective when called before rust-vmm based VMM starts.

[0067] Therefore, in practical implementation, when creating a virtual NUMA node topology in the virtual machine that matches the host NUMA topology, the topology configuration interface developed for the rust-vmm-based VMM can be obtained first. Then, this topology configuration interface can be called before the rust-vmm-based VMM starts. Based on the host NUMA topology, the number of newly added virtual NUMA nodes, and the node information of each virtual NUMA node, the NUMA node configuration information for the virtual machine is configured according to the information configuration format corresponding to the topology configuration interface. It should be noted that when calling the topology configuration interface, it can be used to configure the NUMA node configuration information for one newly added virtual NUMA node at a time. If multiple virtual NUMA nodes need to be added, the topology configuration interface needs to be called multiple times to configure the NUMA node configuration information for multiple virtual NUMA nodes.

[0068] The information configuration format for the interface configured according to the topology relationship can be as follows:

[0069] The newly added API (i.e., the topology configuration interface) indicates the addition of a virtual NUMA node. If a user needs to add multiple virtual NUMA nodes, this API needs to be called multiple times.

[0070] add_one_numa_node( / / Add a virtual NUMA node)

[0071] &mut self,

[0072] id: String, / / The identifier of the newly added virtual NUMA node in the Rust-VMM based VMM (i.e., the virtual NUMA node identifier), in string format.

[0073] size:u64, / / The target memory space occupied by the newly added virtual NUMA node (i.e., the target memory space), in 64-bit unsigned integer format.

[0074] host_numa_node:u32, / / The host NUMA node to which the memory space of the newly added virtual NUMA node needs to be bound, in 32-bit unsigned integer format.

[0075] cpu_list: String / / List of vcpus (i.e., virtual central processing units) allocated on newly added virtual NUMA nodes, in string format.

[0076] In practice, after calling the topology configuration interface, the NUMA node configuration information can be configured according to the above information configuration format based on the host NUMA topology.

[0077] Furthermore, after configuring the NUMA node configuration information, the rust-vmm-based VMM can be used to obtain the configuration information of each NUMA node through the topology configuration interface when starting the rust-vmm-based VMM. The startup timing of the rust-vmm-based VMM can be the timing of starting the virtual machine.

[0078] S102: Using the virtual machine monitor, convert the NUMA node configuration information into target configuration information with a target format, and configure the target configuration information as the target boot parameters of the virtual machine's sub-operating system.

[0079] Here, the Virtual Machine Monitor (VMM) is the Rust-VMM-based VMM mentioned above, which can handle all functions of virtual machines within a secure container, with its core function being ensuring the secure operation of the virtual machine. The target format can be a pre-defined information format that the Guest Operating System (Guest OS) within the virtual machine can recognize and understand. Based on this information format, the Guest OS can obtain NUMA node configuration information. For example, the target format could be "numa = numa_node_id, physical_start_addr@size, cpu_list_bind_to_the_node", where "numa = numa_node_id" represents the identifier of the newly added virtual NUMA node in the Rust-VMM-based VMM, "physical_start_addr@size" represents the physical memory space occupied by the newly added virtual NUMA node, and "cpu_list_bind_to_the_node" represents the list of vCPUs allocated on the newly added virtual NUMA node.

[0080] The target configuration information is the NUMA node configuration information in a target format. The target startup parameter can be a cmdline parameter, used to pass the target configuration information to the Guest OS.

[0081] In practice, after obtaining the NUMA node configuration information, a rust-vmm-based VMM can be used to convert the NUMA node configuration information according to the target format to obtain the target configuration information. Then, the target configuration information can be injected into the Guest OS's command line to obtain the target boot parameters.

[0082] For example, the target configuration information could be: "numa=0, 0x0@0xd0000000@0x100000000@0x330000000, 0-3numa=1, 0x430000000@0x400000000, 4-7". This target configuration information indicates that the NUMA topology information passed to the Guest OS of the virtual machine includes two newly added virtual NUMA nodes.

[0083] The first NUMA node contains vcpu0 to vcpu3 (vcpu0, vcpu1, vcpu2, and vcpu3), and this NUMA node contains two physical memory space corresponding to two physical address ranges: range 1 is (0x0) to ((0x0)+0xd0000000), and range 2 is (0x100000000) to (0x100000000+0x330000000).

[0084] The second NUMA node contains vcpu4 to vcpu7 (vcpu4, vcpu5, vcpu6 and vcpu7), and this NUMA node contains a physical address range corresponding to a physical memory space: the range is (0x430000000) to (0x430000000+0x400000000).

[0085] In one embodiment, the step of "converting NUMA node configuration information into target configuration information with a target format" in S102 can be implemented according to the following steps:

[0086] Step 1: Use the virtual machine monitor to determine the target memory space and target host NUMA node indicated by the NUMA node configuration information; the target host NUMA node is one of the multiple host NUMA nodes included in the host NUMA topology.

[0087] Here, the target memory space refers to the size of the physical memory space occupied by the newly added virtual NUMA node as indicated in the NUMA node configuration information, which can be determined based on the size information in the NUMA node configuration information. The target host NUMA node can be any one of the multiple host NUMA nodes included in the host NUMA topology, or it can be the host NUMA node to which the memory space of the newly added virtual NUMA node needs to be bound.

[0088] In practice, a rust-vmm based VMM can be used to determine the target memory space based on the size information in the NUMA node configuration information; at the same time, the target host NUMA node can be determined based on the host_numa_node information in the NUMA node configuration information.

[0089] Step 2: Determine the physical address range that matches the target memory space from the total memory space corresponding to the virtual machine.

[0090] Here, the physical address range is used to indicate the start and end addresses of the target memory space.

[0091] In practice, memory spaces with the size of the target memory space can be selected from the total memory space corresponding to the virtual machine. Based on the start and end addresses of the memory space, the physical address range that matches the target memory space can be determined.

[0092] In one embodiment, step two above can also be implemented according to the following steps:

[0093] Determine the device memory space allocated to each virtual device in the virtual machine; determine the physical address range that matches the target memory space based on the total memory space and the device address range corresponding to the device memory space.

[0094] Here, a virtual device can refer to a device running within a virtual machine, such as a virtual peripheral. The device address range is the range of physical addresses corresponding to the device's memory space.

[0095] In practice, the device memory space allocated to each virtual device can be determined from the total memory space corresponding to the virtual machine. Optionally, if the total memory space includes device memory space allocated to peripherals and other devices of the host, it can also be determined at the same time.

[0096] After determining the device address range corresponding to the memory space of each device, the physical address range to be adjusted, which contains the space size indicated by the target memory space, can be determined from the physical memory range corresponding to the total memory space. Then, the memory space corresponding to the device address range is removed from the physical address range to be adjusted, resulting in the physical address range corresponding to the target device space.

[0097] Alternatively, you can first remove the device address range from the physical memory range corresponding to the total memory space, and then determine the physical address range with the space size indicated by the target memory space from the remaining physical memory range, and use this physical address range as the physical address range corresponding to the target memory space.

[0098] In this way, by eliminating the device address range corresponding to the device memory space, the memory space occupied by devices such as peripherals can be skipped, thus achieving memory space reshaping.

[0099] Step 3: Determine the target configuration information based on the physical address range, NUMA node configuration information excluding the target memory space and the target host NUMA node.

[0100] Here, the NUMA node configuration information, excluding the target memory space and the target host NUMA node, can at least include virtual NUMA node identifiers and a list of virtual central processing units.

[0101] In practice, the NUMA node configuration information, excluding the target memory space and the target host NUMA node, can be converted into target configuration information according to the target format.

[0102] The reason why the target host NUMA node can be removed when the target configuration information is obtained is that after determining the physical address range matching the target memory space and the target host NUMA node, the target memory space can be bound. Specifically, after determining the physical address range matching the target memory space, the following steps can be performed:

[0103] The target memory space corresponding to the physical address range is bound to the target host NUMA node, and each virtual CPU indicated by the NUMA node configuration information is bound to each physical CPU in the target host NUMA node in pairs.

[0104] In practical implementation, a Rust-VMM-based VMM can be used to bind the target memory space indicated by the physical address range to the target host NUMA node, achieving NUMA binding between the virtual machine's memory space and the host's memory space. Simultaneously, each vCPU in the vCPU list indicated by the NUMA node configuration information can be paired with each physical CPU included in the target host NUMA node. Here, when binding a vCPU to a physical CPU, one vCPU can be bound to any physical CPU, achieving pairwise binding. Different vCPUs are bound to different physical CPUs. When the number of vCPUs is less than the number of physical CPUs, each vCPU will be bound to a physical CPU, but some physical CPUs may not have any bound vCPUs. This allows for the binding of the virtual machine's vCPUs and the host's physical CPUs, ensuring that the virtual machine's vCPUs and memory space reside on the same target host NUMA node.

[0105] S103: Using the sub-operating system to create each target virtual NUMA node corresponding to the virtual machine based on the target configuration information carried by the target boot parameters.

[0106] Here, the distance relationship between each vcpu in the target virtual NUMA node and the target memory space is consistent with the distance relationship between the physical central processing unit and the physical memory space indicated by the host NUMA topology.

[0107] In practice, during startup, the Guest OS can obtain the target boot parameters passed by the Rust-VMM-based VMM from the command line and determine the target configuration information based on these parameters. Then, the Guest OS can create various target virtual NUMA nodes in the virtual machine according to the NUMA topology indicated by the target configuration information. These target virtual NUMA nodes are the virtual NUMA nodes that need to be added to the virtual machine as indicated by the NUMA node configuration information.

[0108] For example, a virtual NUMA node with a virtual NUMA node identifier carried by the target configuration information can be created first, and then each vcpu and target memory space indicated by the target configuration information can be added to the virtual NUMA node to obtain the target virtual NUMA node.

[0109] After creating each target virtual NUMA node in the virtual machine, it can be concluded that the same NUMA topology as the host has been created in the virtual machine, thus achieving the adjustment of the virtual machine's NUMA structure. Subsequently, when the virtual machine is running services, the vCPU and target memory space can be accessed based on the adjusted NUMA structure, thereby achieving operational control of the virtual machine.

[0110] In one embodiment, the above-described S103 can be implemented according to the following steps:

[0111] Using the node information conversion process in the sub-operating system, based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units, each target virtual NUMA node is created.

[0112] Here, the node information conversion process is a pre-developed process used to map the NUMA topology indicated by the target configuration information to the NUMA subsystem corresponding to the Guest OS, without going through the ACPI subsystem. The target memory space can be the memory space corresponding to the physical address range determined above.

[0113] In practical implementation, after obtaining the target configuration information transmitted by the Rust-VMM-based VMM from the cmdline, the node information conversion process can be used to parse the target configuration information to obtain the number of virtual NUMA nodes indicated by the target configuration information, as well as the virtual NUMA node identifier corresponding to each virtual NUMA node, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual CPUs. Then, for each virtual NUMA node identifier, a target virtual NUMA node with that identifier can be created based on the target memory space and virtual CPU list corresponding to that identifier.

[0114] In one embodiment, the creation of the target virtual node can be achieved by utilizing a node information conversion process and following these steps:

[0115] The target memory space corresponding to each virtual NUMA node identifier is added to the virtual memory manager corresponding to the virtual machine for management; and each virtual CPU in the virtual CPU list corresponding to each virtual NUMA node identifier is bound to the virtual NUMA node identifier to obtain the target virtual NUMA node corresponding to each virtual NUMA node identifier.

[0116] In practice, for each virtual NUMA node transmitted from cmdline, the node information conversion process can be used to call the Guest OS's memory management interface to add the target memory space corresponding to the virtual NUMA node identifier of the virtual NUMA node to the virtual memory manager of the virtual machine, thereby realizing the management of the target memory space.

[0117] For example, the memory management interface could be the "Add Non-Uniform Memory Access Block" (numa_add_memblk) interface in the Guest OS. When calling this interface, the virtual NUMA node identifier and the start and end addresses of the target memory space can be set to add the target memory space to the virtual memory manager. For instance, the instruction to call the memory management interface could be "numa_add_memblk(numa_node_index, numa_node_start_addr, numa_node_end_addr)", where numa_node_index is the virtual NUMA node identifier, numa_node_start_addr is the start address of the target memory space, and numa_node_end_addr is the end address of the target memory space.

[0118] Regardless of how many virtual NUMA nodes are contained in the target configuration information, the memory space management of the newly added virtual NUMA nodes can be achieved by using the node information conversion process and calling the Guest OS's memory management interface.

[0119] Furthermore, after adding the memory space corresponding to each virtual NUMA node to the virtual memory manager, the node information conversion process can be used to call the Guest OS's processor management interface to bind each virtual CPU in the virtual CPU list corresponding to each virtual NUMA node identifier to the virtual NUMA node identifier, thereby achieving the binding of virtual NUMA nodes and vCPUs to obtain each target virtual NUMA node.

[0120] For example, the processor management interface can be the `set_apicid_to_node` interface in the Guest OS. When calling this interface, the virtual NUMA node identifier and the virtual CPU identifier can be set, thus binding the virtual CPU to the target virtual NUMA node corresponding to the virtual NUMA node identifier. Each call to the processor management interface binds one virtual CPU. Therefore, if the list of virtual CPUs corresponding to the virtual NUMA node identifier includes multiple virtual CPUs, the processor management interface can be called multiple times to bind multiple virtual CPUs to the same target virtual NUMA node corresponding to the same virtual NUMA node identifier. For example, the instruction to call the processor management interface can be "set_apicid_to_node(cpu_index, numa_node_index)", where `cpu_index` is the identifier of the virtual CPU in the virtual CPU list, and `numa_node_index` is the virtual NUMA node identifier.

[0121] By calling the two interfaces mentioned above, the host NUMA topology relationship passed by the rust-vmm-based VMM can be connected to the kernel non-uniform memory access subsystem (i.e., Kernel NUMA System) through the node information conversion process, and the various target virtual NUMA nodes created in the virtual machine can be obtained.

[0122] like Figure 2 The diagram illustrates a process for creating various target virtual NUMA nodes using a node information conversion process, as provided in this embodiment of the disclosure. For each virtual NUMA node transmitted from the command line, the node information conversion process (i.e., ...) can be used first. Figure 2The NUMA Info translator calls the `numa_add_memblk` interface to add the target memory space corresponding to each virtual NUMA node identifier to the virtual memory manager of the virtual machine for management; and uses the `set_apicid_to_node` interface to bind the virtual CPU to the target virtual NUMA node corresponding to the virtual NUMA node identifier. In this way, the host NUMA topology can be mapped to the kernel NUMA subsystem, obtaining the various target virtual NUMA nodes created in the virtual machine.

[0123] To demonstrate the difference between the virtual machine operation control method provided in this disclosure and the topology relationship transfer method in the prior art, the following will be used... Figure 3a and Figure 3b To present it visually. Among them, Figure 3a This is a schematic diagram illustrating the specific implementation process of the existing topology relationship transfer method. Figure 3b This is a schematic diagram illustrating the specific implementation process of a virtual machine operation control method provided in this embodiment of the disclosure.

[0124] exist Figure 3a In this context, "Hardware" refers to the host's hardware, and "Host OS kernel" refers to the kernel of the main operating system. The main operating system is the operating system corresponding to the host. The VMM set up in the secure container is either the virtual operating system emulator QEMU or the cloud management program Cloud-Hypervisor. After obtaining the host NUMA topology relationship to be transferred, the VMM can perform step "a, Preparation," which specifically involves configuring ACPI tables related to the host NUMA topology relationship, such as SRAT and SLIT tables, through ACPI configuration. Then, it performs step "b, Acquisition," which involves the Guest OS acquiring the ACPI table and transferring it to the virtual machine's kernel ACPI subsystem (i.e., the virtual machine's kernel ACPI subsystem). Figure 3a The Kernel ACPI Subsystem must be enabled. Then, step "c. Transfer" can be performed using the Kernel ACPI Subsystem. This step involves parsing the ACPI tables (e.g., SRAT and SLIT tables) to obtain the host NUMA topology, and then transferring the NUMA topology to the virtual machine's kernel non-uniform memory access subsystem (i.e., the Kernel NUMA System), thereby creating virtual NUMA nodes within the virtual machine.

[0125] And in Figure 3b In this context, "Hardware" refers to the host's hardware, and "Host OS kernel" refers to the kernel of the main operating system, which is the operating system corresponding to the host. The VMM set up in the secure container is a Rust-VMM based VMM. Then, the NUMA node configuration information can be configured using the topology configuration interface. After obtaining the NUMA node configuration information, the Rust-VMM based VMM can execute step "1. Preparation," which converts the NUMA node configuration information into target configuration information with the target format and injects the target configuration information into the command line to obtain the target boot parameters. After the virtual machine's guest operating system starts, it can execute step "2. Acquisition," which retrieves the target configuration information carried by the target boot parameters from the command line and sends the target configuration information to the node information translation process (NUMA Info translator). Then, the NUMA Info translator can execute step "3. Transmission," which transmits the NUMA topology information indicated by the target configuration information to the virtual machine's kernel non-uniform memory access subsystem (i.e., Kernel NUMA System), thereby creating various target virtual NUMA nodes within the virtual machine. Based on the above process, the host NUMA topology can be transferred to the virtual machine using cmdline without relying on ACPI.

[0126] based on Figure 3a and Figure 3bAs can be seen, the topology relationship transfer process in existing technologies differs from that in the virtual machine runtime control method provided in this disclosure. The VMM used is different: one uses QEMU or Cloud-Hypervisor, while the other uses a self-developed Rust-VMM-based VMM. The VMMs used are completely different. During the transfer process, one requires the use of a Kernel ACPI Subsystem and ACPI tables (e.g., SRAT and SLIT tables), while the other uses a cmdline and NUMA Info translator, employing entirely different methods. Since the cmdline and NUMA Info translator are lighter than the Kernel ACPI Subsystem and ACPI tables, the virtual machine runtime control method provided in this disclosure not only achieves lightweighting and reduces transfer difficulty, but also effectively reduces the risk of code intrusion and improves virtual machine runtime security because it eliminates the need for large-scale ACPI-related code.

[0127] To further demonstrate the topology transfer effect of the virtual machine operation control method provided in this disclosure, certain instructions in the Linux operating system can be used to query the host's memory, physical CPU, and NUMA nodes. Furthermore, after the virtual machine operation control method provided in this disclosure completes the topology transfer, the corresponding NUMA topology of the virtual machine can be transferred. For example, using the `lscpu` instruction, the host's memory and physical CPU information queried is as follows:

[0128]

[0129]

[0130]

[0131]

[0132] Thus, based on the NUMA node information of the host obtained by querying and the virtual NUMA node information of the virtual machine after the topology relationship is transferred, it can be seen that after the virtual machine operation control method provided in the disclosed embodiment completes the topology relationship transfer, the virtual NUMA topology relationship can be matched with the host NUMA topology relationship. This also shows that the virtual machine operation control method provided in the disclosed embodiment can accurately transfer the host NUMA topology relationship to the virtual machine.

[0133] Thus, based on the above embodiments, the entire process of transmitting and converting the host NUMA topology does not require the use of ACPI-based configuration of ACPI tables, achieving the goal of lightweighting and reducing the difficulty of transmission. Furthermore, since it does not require the use of large-scale ACPI-related code, it can effectively reduce the risk of code intrusion and improve the operational security of the virtual machine.

[0134] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0135] Based on the same inventive concept, this disclosure also provides a virtual machine operation control device corresponding to the virtual machine operation control method. Since the principle of the device in this disclosure for solving the problem is similar to the virtual machine operation control method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0136] like Figure 4 The diagram shown is a schematic representation of a virtual machine operation control device provided in an embodiment of this disclosure, comprising:

[0137] The acquisition module 401 is used to acquire non-uniform memory access NUMA node configuration information for virtual machines; the NUMA node configuration information is determined based on the host NUMA topology corresponding to the host running the virtual machine; the host NUMA topology is used to indicate the distance between the physical central processing unit and the physical memory space in the host.

[0138] Configuration module 402 is used to convert the NUMA node configuration information into target configuration information with a target format using a virtual machine monitor, and configure the target configuration information as the target boot parameters of the virtual machine's sub-operating system;

[0139] The creation module 403 is used to create each target virtual NUMA node corresponding to the virtual machine using the sub-operating system based on the target configuration information carried by the target boot parameters.

[0140] In one possible implementation, the creation module 403, when creating each target virtual NUMA node corresponding to the virtual machine using the sub-operating system based on the target configuration information carried by the target boot parameters, is used to:

[0141] Using the node information conversion process in the sub-operating system, each target virtual NUMA node corresponding to the virtual machine is created based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units.

[0142] In one possible implementation, the creation module 403, when creating each target virtual NUMA node corresponding to the virtual machine based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units, is used to:

[0143] The target memory space corresponding to each virtual NUMA node identifier is added to the virtual memory manager corresponding to the virtual machine for management; and

[0144] Each virtual central processing unit in the list of virtual central processing units corresponding to each virtual NUMA node identifier is bound to the virtual NUMA node identifier to obtain the target virtual NUMA node corresponding to each virtual NUMA node identifier.

[0145] In one possible implementation, the acquisition module 401, when acquiring NUMA node configuration information for a virtual machine, is used to:

[0146] Before starting the virtual machine monitor, determine the topology configuration interface developed for the virtual machine monitor, and configure the NUMA node configuration information using the topology configuration interface according to the host NUMA topology.

[0147] In response to starting the virtual machine monitor, the configured NUMA node configuration information is obtained.

[0148] In one possible implementation, the configuration module 402, when using the virtual machine monitor to convert the NUMA node configuration information into target configuration information with a target format, is used to:

[0149] Using the virtual machine monitor, the target memory space and target host NUMA node indicated by the NUMA node configuration information are determined; the target host NUMA node is one of multiple host NUMA nodes included in the host NUMA topology.

[0150] From the total memory space corresponding to the virtual machine, determine the physical address range that matches the target memory space;

[0151] The target configuration information is determined based on the physical address range and the NUMA node configuration information excluding the target memory space and the target host NUMA node.

[0152] In one possible implementation, the configuration module 402, when determining the physical address range matching the target memory space from the total memory space corresponding to the virtual machine, is used to:

[0153] Determine the device memory space allocated to each virtual device in the virtual machine;

[0154] Based on the total memory space and the device address range corresponding to the device memory space, determine the physical address range that matches the target memory space.

[0155] In one possible implementation, the device further includes:

[0156] The binding module 404, after determining the physical address range that matches the target memory space, is used for...

[0157] The target memory space corresponding to the physical address range is bound to the target host NUMA node, and each virtual CPU indicated by the NUMA node configuration information is bound to each physical CPU in the target host NUMA node in pairs.

[0158] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0159] Based on the same technical concept, embodiments of this application also provide a computer device. (Refer to...) Figure 5 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application, comprising:

[0160] The system comprises a processor 501, a memory 502, and a bus 503. The memory 502 stores machine-readable instructions executable by the processor 501. The processor 501 executes these machine-readable instructions, and when executed, performs the following steps: S101: Obtaining NUMA node configuration information for the virtual machine; the NUMA node configuration information is determined based on the host NUMA topology of the host running the virtual machine; the host NUMA topology indicates the distance between the physical central processing unit and the physical memory space in the host; S102: Using the virtual machine monitor, converting the NUMA node configuration information into target configuration information with a target format, and configuring the target configuration information as the target startup parameters of the virtual machine's sub-operating system; and S103: Using the sub-operating system, creating each target virtual NUMA node corresponding to the virtual machine based on the target configuration information carried by the target startup parameters.

[0161] The aforementioned memory 502 includes a main memory 5021 and an external memory 5022. The main memory 5021, also known as internal memory, is used to temporarily store the computational data in the processor 501, as well as the data exchanged with external memory such as a hard disk 5022. The processor 501 exchanges data with the external memory 5022 through the main memory 5021. When the computer device is running, the processor 501 and the memory 502 communicate through the bus 503, so that the processor 501 executes the execution instructions mentioned in the above method embodiments.

[0162] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the virtual machine execution control method described in the above-described method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0163] The computer program product of the virtual machine operation control method provided in this disclosure includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the virtual machine operation control method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0164] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0165] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0166] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0167] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0168] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0169] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0170] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A virtual machine operation control method, characterized in that, include: Obtain configuration information for NUMA nodes with non-uniform memory access for virtual machines; The NUMA node configuration information is determined based on the host NUMA topology relationship corresponding to the host running the virtual machine; The host NUMA topology is used to indicate the distance between the physical central processing unit and the physical memory space in the host; Using a virtual machine monitor, the NUMA node configuration information is converted into target configuration information with a target format, and the target configuration information is injected into the kernel boot command line to obtain the target boot parameters of the virtual machine's sub-operating system; The sub-operating system of the virtual machine obtains the target configuration information carried by the target boot parameters from the kernel boot command line, and sends the target configuration information to the node information conversion process. Using the node information conversion process, according to the virtual NUMA node identifier, the target memory space corresponding to each virtual NUMA node identifier and the list of virtual central processing units carried by the target configuration information, each target virtual NUMA node is created.

2. The method according to claim 1, characterized in that, Based on the virtual NUMA node identifier carried in the target configuration information, the target memory space corresponding to each virtual NUMA node identifier, and the list of virtual central processing units, create each target virtual NUMA node corresponding to the virtual machine, including: The target memory space corresponding to each virtual NUMA node identifier is added to the virtual memory manager corresponding to the virtual machine for management; and Each virtual central processing unit in the list of virtual central processing units corresponding to each virtual NUMA node identifier is bound to the virtual NUMA node identifier to obtain the target virtual NUMA node corresponding to each virtual NUMA node identifier.

3. The method according to claim 1, characterized in that, Obtain configuration information for non-uniform memory access NUMA nodes for virtual machines, including: Before starting the virtual machine monitor, determine the topology configuration interface developed for the virtual machine monitor, and configure the NUMA node configuration information using the topology configuration interface according to the host NUMA topology. In response to starting the virtual machine monitor, the configured NUMA node configuration information is obtained.

4. The method according to claim 1, characterized in that, Using a virtual machine monitor, the NUMA node configuration information is converted into target configuration information with a target format, including: Using the virtual machine monitor, the target memory space and target host NUMA node indicated by the NUMA node configuration information are determined; the target host NUMA node is one of multiple host NUMA nodes included in the host NUMA topology. From the total memory space corresponding to the virtual machine, determine the physical address range that matches the target memory space; The target configuration information is determined based on the physical address range and the NUMA node configuration information excluding the target memory space and the target host NUMA node.

5. The method according to claim 4, characterized in that, From the total memory space corresponding to the virtual machine, determine the physical address range that matches the target memory space, including: Determine the device memory space allocated to each virtual device in the virtual machine; Based on the total memory space and the device address range corresponding to the device memory space, determine the physical address range that matches the target memory space.

6. The method according to claim 4, characterized in that, After determining the physical address range that matches the target memory space, the process also includes: The target memory space corresponding to the physical address range is bound to the target host NUMA node, and each virtual CPU indicated by the NUMA node configuration information is bound to each physical CPU in the target host NUMA node in pairs.

7. A virtual machine operation control device, characterized in that, include: The acquisition module is used to obtain configuration information for NUMA nodes that provide non-uniform memory access to virtual machines. The NUMA node configuration information is determined based on the host NUMA topology corresponding to the host running the virtual machine; the host NUMA topology is used to indicate the distance between the physical central processing unit and the physical memory space in the host. The configuration module is used to convert the NUMA node configuration information into target configuration information with a target format using the virtual machine monitor, and inject the target configuration information into the kernel boot command line to obtain the target boot parameters of the virtual machine's sub-operating system; A creation module is used to obtain the target configuration information carried by the target boot parameters from the kernel boot command line of the virtual machine, and send the target configuration information to the node information conversion process. The node information conversion process uses the virtual NUMA node identifier, the target memory space corresponding to each virtual NUMA node identifier and the list of virtual central processing units carried by the target configuration information to create each target virtual NUMA node corresponding to the virtual machine.

8. A computer device, characterized in that, include: The processor and the memory, wherein the memory stores machine-readable instructions executable by the processor, the processor is used to execute the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the processor performs the steps of the virtual machine operation control method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a computer device, causes the computer device to perform the steps of the virtual machine operation control method as described in any one of claims 1 to 6.

Images