Configuration method of input / output memory management unit, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a configuration method of an input / output memory management unit, electronic equipment and a storage medium, and the configuration method of the input / output memory management unit comprises the following steps: responding to an access request of a virtual machine to a virtual input / output memory management unit; the access request exits from the virtual machine to a kernel mode of a first privilege level, and the virtual input / output memory management unit runs in the kernel mode of the first privilege level; the virtual input / output memory management unit reads configuration information from the memory of the virtual machine according to the access request, and generates a simulation configuration result according to the configuration information; and the virtual input / output memory management unit configures the input / output memory management unit according to the simulation configuration result. According to the scheme, the efficiency of configuring the input / output memory management unit can be improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a configuration method, electronic device, and storage medium for an input / output memory management unit. Background Art

[0002] In order to enable the virtual machine's passthrough device to read and write the virtual machine's memory through Direct Memory Access (DMA), it is necessary to configure a virtual Input-Output Memory Management Unit (IOMMU) for the virtual machine.

[0003] Currently, when configuring the IOMMU, the IOMMU is configured through a virtual input-output memory management unit (vIOMMU) running in user mode.

[0004] However, since vIOMMU is implemented in user mode, multiple switches between kernel mode and user mode and data copying are required during IOMMU configuration, resulting in low IOMMU configuration efficiency. Summary of the Invention

[0005] In view of this, embodiments of the present application provide a configuration method of an input / output memory management unit, an electronic device, and a storage medium to at least partially solve the above-mentioned problems.

[0006] According to a first aspect of an embodiment of the present application, a method for configuring an input / output memory management unit is provided, comprising: in response to an access request from a virtual machine to a virtual input / output memory management unit, the access request exits from the virtual machine to a kernel state of a first privilege level, wherein the virtual input / output memory management unit runs in a kernel state of the first privilege level; the virtual input / output memory management unit reads configuration information from the memory of the virtual machine according to the access request, and generates a simulation configuration result according to the configuration information; and the virtual input / output memory management unit configures the input / output memory management unit according to the simulation configuration result.

[0007] According to a second aspect of an embodiment of the present application, a configuration system for an input / output memory management unit is provided, comprising: a virtual machine, a virtual input / output memory management unit, and an input / output memory management unit, wherein the virtual input / output memory management unit runs in a kernel state at a first privilege level; the virtual machine is configured to output an access request to the virtual input / output memory management unit, so that the access request exits from the virtual machine to the kernel state at the first privilege level; the virtual input / output memory management unit is configured to read configuration information from the memory of the virtual machine according to the access request, generate a simulation configuration result according to the configuration information, and configure the input / output memory management unit according to the simulation configuration result.

[0008] According to the third aspect of the embodiment of the present application, an electronic device is provided, including: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform the operation corresponding to the method described in the first aspect above.

[0009] According to a fourth aspect of the embodiments of the present application, a computer storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described in the first aspect is implemented.

[0010] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, comprising computer instructions, wherein the computer instructions instruct a computing device to execute the method described in the first aspect above.

[0011] According to the above technical solution, the virtual machine issues an access request to the virtual input / output memory management unit and exits to the kernel state of the first privilege level. Since the virtual input / output memory management unit runs in the kernel state of the first privilege level, there is no need to switch back to the user state of the first privilege level to process the access request. Moreover, the virtual input / output memory management unit running in the kernel state of the first privilege level can read configuration information from the memory of the virtual machine multiple times according to the access request, so that the process of reading the configuration information does not need to switch between the kernel state of the first privilege level and the user state of the first privilege level and copy data multiple times. After obtaining the simulation configuration result, the virtual input / output memory management unit can directly set the simulation configuration result to the input / output memory management unit, and there is no need to switch between the user state of the first privilege level and the kernel state of the first privilege level and copy data. It can be seen that the virtual input / output memory management unit is implemented in the kernel state of the first privilege level. In the process of configuring the input / output memory management unit through the virtual input / output memory management unit, the number of switches between the user state of the first privilege level and the kernel state of the first privilege level and the data copying are reduced, which saves the time required for the configuration of the virtual input / output memory management unit, thereby improving the configuration efficiency of the virtual input / output memory management unit. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0013] Figure 1 is a schematic diagram of an exemplary system used in one embodiment of the present application;

[0014] Figure 2 This is a flowchart of a method for configuring an input / output memory management unit according to an embodiment of the present application;

[0015] Figure 3 It is a schematic diagram of a configuration system of an input / output memory management unit according to an embodiment of the present application;

[0016] Figure 4 is a schematic diagram of a configuration system of an input / output memory management unit according to another embodiment of the present application;

[0017] Figure 5 It is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] The present application is described below based on examples, but the present application is not limited to these examples. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without describing these details. To avoid obscuring the essence of the present application, well-known methods, processes, and procedures are not described in detail. In addition, the drawings are not necessarily drawn to scale.

[0019] First, some nouns or terms that appear in the process of describing the embodiments of the present application are subject to the following explanations.

[0020] Input-Output Memory Management Unit: The Input-Output Memory Management Unit (IOMMU) is used to connect the I / O bus and main memory. It can convert the input / output (I / O) virtual addresses in the device's DMA request into physical addresses.

[0021] Virtual Input-Output Memory Management Unit: A virtual input-output memory management unit (vIOMMU) is an IOMMU device virtualized by software in a virtualization scenario.

[0022] Kernel state: Kernel state is an operating state of the operating system. The CPU in kernel state can access any data, including peripheral devices such as network cards and hard disks. The CPU in kernel state can switch from one program to another and will not preempt the CPU. The state at privilege level 0 is generally called kernel state.

[0023] User state: User state is another operating state of the operating system. The CPU in user state can access restricted resources but cannot directly access hardware devices such as memory. It needs to fall into kernel state through system calls (syscall) to access these privileged resources.

[0024] Root mode and non-root mode: Before virtualization, the system included user state and kernel state. In order to meet the needs of virtualization, two privilege levels, the first privilege level and the second privilege level, were added. For example, under the X86 architecture, the first privilege level is root mode (root mode) and the second privilege level is non-root mode (non-root mode). Non-root mode is also called guest mode. The first privilege level and the second privilege level both include kernel state and user state. The CPU's permissions in kernel state are higher than those in user state. The CPU's permissions at the first privilege level are greater than those at the second privilege level, and the permission set of the first privilege level is a subset of the permission set of the second privilege level. In an embodiment of the present application, vIOMMU, KVM, and the IOMMU driver all run in the kernel state at the first privilege level, and the VM and the VM's IOMMU driver run at the second privilege level.

[0025] Virtual Machine: A virtual machine (VM) is a complete computer system that is simulated by software and has complete hardware system functions and runs in a completely isolated environment.

[0026] Direct Memory Access: Direct Memory Access (DMA) is a feature provided by some computer bus architectures that enables data to be sent directly from an attached device (such as a disk drive) to the computer's mainboard memory.

[0027] Exemplary Systems

[0028] Figure 1 An exemplary system for a key generation method applicable to an embodiment of the present application is shown. Figure 1As shown, the system may include a cloud service terminal 102, a communication network 104 and at least one user device 106. Figure 1 The example is a plurality of user devices 106. It should be noted that the solution of the embodiment of the present application can be applied to both the cloud service end 102 and the user device 106.

[0029] The cloud server 102 can be any appropriate device for storing information, data, programs and / or any other suitable type of content, including but not limited to distributed storage system devices, server clusters, computing cloud server clusters, etc. In some embodiments, the cloud server 102 can perform any appropriate function. For example, in some embodiments, the cloud server 102 can be used to build a virtualized environment and configure vIOMMU for the VM, so that the VM supports the Process Address Space ID (PASID) feature, so that different processes of the VM can share a pass-through device, and then access the VM's memory in DMA mode through the IOMMU. As an optional example, in some embodiments, the cloud server 102 can implement vIOMMU in kernel mode, and the user mode program can configure the IOMMU through the vIOMMU implemented in kernel mode, avoiding frequent switching and data copying between the kernel mode at the first privilege level and the user mode at the first privilege level during the configuration of the IOMMU, so as to improve the performance of the vIOMMU simulation device.

[0030] The communication network 104 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network 104 can include any one or more of the following: the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), and / or any other suitable communication network. The user device 106 can be connected to the communication network 104 via one or more communication links (e.g., communication link 112), and the communication network 104 can be linked to the cloud service end 102 via one or more communication links (e.g., communication link 114). The communication link can be any communication link suitable for transmitting data between the cloud service end 102 and the user device 106, such as a network link, a dial-up link, a wireless link, a hard-wired link, any other suitable communication link, or any suitable combination of such links.

[0031] The user device 106 may include any one or more user devices suitable for interaction. In some embodiments, after receiving a request from the user device 106, the cloud service end 102 may construct a VM for use and operation by the user device 106 in a virtualized environment. In the process of constructing the VM, the vIOMMU of the VM is constructed in the kernel state of the first privilege level, and the IOMMU of the VM is configured through the constructed vIOMMU, so that the pass-through device of the VM can access the memory of the VM in a DMA manner through the configured IOMMU. Then, in the process of using the VM by the user device 106, after receiving an instruction from the user device 106, the VM can send a memory access instruction to its pass-through device, so that the pass-through device can directly access the memory of the VM through the IOMMU. The user device 106 may include any suitable type of device. For example, the user device 106 may include a mobile device, a tablet computer, a laptop computer, a desktop computer, a wearable computer, a vehicle system and / or any other suitable type of user device.

[0032] The embodiment of the present application mainly focuses on the process of configuring the IOMMU of the cloud server 102, and the process of IOMMU configuration will be described in detail later.

[0033] IOMMU configuration method

[0034] Based on the above system, an embodiment of the present application provides an IOMMU configuration method, and the IOMMU configuration method is described in detail below through multiple embodiments.

[0035] Figure 2 This is a flow chart of a configuration method of an IOMMU according to an embodiment of the present application. Figure 2 As shown, the IOMMU configuration method includes the following steps:

[0036] Step 201: In response to a VM's access request to the vIOMMU, the VM exits the access request to a kernel state at a first privilege level.

[0037] When a user-mode program builds a VM, it can create a vIOMMU for the VM. The vIOMMU runs in kernel mode at the first privilege level. The user-mode program can manage the vIOMMU through system calls (syscalls). The user-mode program can be QEMU.

[0038] After a VM is created, the VM can send an access request to its vIOMMU. For example, the VM can read or write the vIOMMU through the IOMMU driver (VM IOMMU driver) running in kernel state at the second privilege level. The access request will exit the VM to kernel state at the first privilege level.

[0039] Step 202: The vIOMMU reads configuration information from the memory of the VM according to the access request, and generates a simulation configuration result according to the configuration information.

[0040] After the access request exits to the first-privilege-level kernel state, the vIOMMU receives the access request. Since the vIOMMU runs in the first-privilege-level kernel state, it has permission to access the VM's memory without exiting from the first-privilege-level kernel state to the first-privilege-level user state. The vIOMMU can then read the configuration information from the VM's memory based on the access request. Before sending the access request, the VM writes the configuration information required to configure the IOMMU into its memory. The vIOMMU can then read the configuration information required to configure the IOMMU from the VM's memory based on the access request.

[0041] When the vIOMMU reads configuration information from the VM's memory based on an access request, it can access the VM's memory multiple times. After reading some configuration information from the VM's memory, the vIOMMU can generate some simulated configuration results based on this information. It can also use this information to determine what other configuration information is needed and then read the required configuration information from the VM's memory. By repeatedly accessing the VM's memory, the vIOMMU generates all the simulated configuration results required to configure the IOMMU.

[0042] The VM cannot directly configure the IOMMU hardware. Therefore, the user-mode program builds vIOMMU and simulates the IOMMU hardware through vIOMMU. The VM simulates the IOMMU configuration process through vIOMMU, and then vIOMMU sets the simulated configuration results to the IOMMU hardware to indirectly configure the IOMMU hardware.

[0043] Step 203: vIOMMU configures the IOMMU according to the simulation configuration result.

[0044] vIOMMU simulates the process of configuring the IOMMU hardware. It processes the read configuration information to obtain the simulated configuration result, and then sets the simulated configuration result to the IOMMU hardware to implement the configuration of the IOMMU.

[0045] During the simulation configuration process, vIOMMU can call the Application Programming Interface (API) provided by the IOMMU driver (kernel IOMMU driver) running in the kernel state of the first privilege level, set the simulation configuration result into the IOMMU, and complete the simulation.

[0046] During the configuration simulation, the vIOMMU reads configuration information from the VM's memory multiple times and processes the configuration information read one or more times to generate partial simulation configuration results. After obtaining the partial simulation configuration results, the vIOMMU can call the API of the IOMMU driver running in kernel mode at the first privilege level to set these simulation configuration results to the IOMMU. The vIOMMU can call the API of the IOMMU driver running in kernel mode at the first privilege level multiple times to set all simulation configuration results to the IOMMU, completing the IOMMU configuration.

[0047] In an embodiment of the present application, after the VM issues an access request to the vIOMMU, the access request exits from the virtual machine to the kernel state of the first privilege level. Since the vIOMMU runs in the kernel state of the first privilege level, there is no need to switch back to the user state of the first privilege level to process the access request. Moreover, the vIOMMU running in the kernel state of the first privilege level can read the configuration information from the memory of the VM multiple times according to the access request, so that the process of reading the configuration information does not need to switch and copy data multiple times between the kernel state of the first privilege level and the user state of the first privilege level. After obtaining the simulation configuration result, the vIOMMU can directly set the simulation configuration result to the IOMMU, and there is also no need to switch and copy data between the user state of the first privilege level and the kernel state of the first privilege level. It can be seen that the vIOMMU is implemented in the kernel state of the first privilege level. In the process of configuring the IOMMU through the vIOMMU, the number of switches and data copies between the user state of the first privilege level and the kernel state of the first privilege level are reduced, and the time required for the IOMMU configuration is saved, thereby improving the configuration efficiency of the IOMMU.

[0048] In a possible implementation, the VM runs at a second privilege level, and a permission set of the second privilege level is a subset of a permission set of the first privilege level.

[0049] VMs are built by user-mode programs, which run in user mode (privilege level 1), so VMs run at privilege level 2. For example, VMs can be built using the user-mode program QEMU. This user-mode program can build multiple VMs and allocate different software and hardware resources to different VMs, such as assigning different passthrough devices to different VMs. Taking the x86 architecture as an example, VMs run in non-root mode, while the host runs in root mode. Root mode includes root user mode and root kernel mode. QEMU runs in root user mode, and vIOMMU runs in root kernel mode. A vIOMMU access request from the VM first exits from non-root mode to root kernel mode. If vIOMMU is running in root user mode, the access request must continue to exit to QEMU running in root user mode. If vIOMMU is running in root kernel mode, the access request does not need to exit to root user mode.

[0050] In an embodiment of the present application, the VM runs at the second privilege level and cannot directly configure the IOMMU. The VM configures the IOMMU through the vIOMMU running in the kernel state of the first privilege level. The vIOMMU can directly access the memory of the VM to obtain configuration information without switching back to the user state of the first privilege level. During the IOMMU configuration process, there is no need to switch and copy data multiple times between the kernel state and the user state of the first privilege level, which saves the time for switching between the kernel state and the user state of the first privilege level, and the time for copying data between the kernel state and the user state of the first privilege level, thereby improving the efficiency of the IOMMU configuration.

[0051] In one possible implementation, a virtual machine kernel module runs in a kernel state at the first privilege level. The virtual machine kernel module may be a kernel-based virtual machine (KVM). In response to a VM access request to the vIOMMU, when the VM exits to the kernel state at the first privilege level, the access request may be passed to the virtual machine kernel module, so that the virtual machine kernel module can obtain the access request and send the access request to the vIOMMU.

[0052] After the access request exits to the virtual machine kernel module, the virtual machine kernel module cannot process the access request. The virtual machine kernel module will forward the access request to the vIOMMU running in the kernel state of the first privilege level, and the vIOMMU will process the access request.

[0053] In an embodiment of the present application, the virtual machine kernel module can provide a virtualization core architecture and processor specifications, and the user state of the first privilege level and the kernel state of the first privilege level are switched through the virtual machine kernel module. After the access request exits to the virtual machine kernel module, the virtual machine kernel module cannot process the access request, and the virtual machine kernel module transfers the access request to the vIOMMU for processing. Since the virtual machine kernel module and the vIOMMU are both running in the kernel state of the first privilege level, the virtual machine kernel module can directly transfer the access request to the vIOMMU in the kernel state of the first privilege level without switching between the kernel state of the first privilege level and the user state of the first privilege level and copying data, thereby improving the performance of the vIOMMU and improving the efficiency of configuring the IOMMU.

[0054] In one possible implementation, a VM can be constructed by a user-mode program running in user mode at the first privilege level, such as by constructing the VM using QEMU. After the user-mode program constructs the VM, a vIOMMU running in kernel mode at the first privilege level can be created using a create command, and the device address segment managed by the vIOMMU can be registered on the I / O bus of the virtual machine kernel module. After the access request exits to the virtual machine kernel module, the virtual machine kernel module determines that the device capable of processing the access request is the vIOMMU based on the device address to be accessed by the access request and the device address segment registered on the I / O bus, and then transfers the access request to the vIOMMU for management.

[0055] The user-mode program can receive parameters input by the user and generate a creation command carrying these parameters. After executing the creation command, the user-mode program can call the corresponding function in the virtual machine kernel module through the system, and then create the vIOMMU through the called function.

[0056] The vIOMMU running in kernel mode at the first privilege level can simulate and implement the functions of each register according to the definition in the IOMMU specification. When creating a vIOMMU, a system device can be registered (for example, the registration name is kernel_viommu), so that the user-mode program can obtain a device handle by opening the corresponding directory (for example, / dev / kernel_iommu). Subsequent user-mode programs can manage the vIOMMU through this handle and ioctl. Among them, ioctl (input / output control) is a system call dedicated to device input and output operations. The call passes in a request code related to the device, and the function of the system utility depends on the request code.

[0057] vIOMMU can provide multiple types of commands, such as create commands, initialization commands, serialization commands, state restoration commands, reset commands, and release commands, to facilitate management by user-mode programs. The create command is used to create vIOMMU in root-mode kernel mode. The initialization command is used to initialize vIOMMU, including initializing the values ​​of each register of vIOMMU. The serialization command is used to serialize the vIOMMU device state and send the vIOMMU state data to the user-mode program. The state restoration command is used to send the vIOMMU state data to the vIOMMU, and the vIOMMU can restore the state based on the state data. The reset command is used to reset the vIOMMU, including resetting the values ​​of each register of vIOMMU. The release command is used to release various resources managed by vIOMMU.

[0058] When creating a VM, you can open a vIOMMU in kernel mode at the first privilege level using open(" / dev / kernel_viommu") and create and initialize the vIOMMU using the create and initialize commands. By building information in the vIOMMU's Advanced Configuration and Power Interface (ACPI) table, the VM kernel can discover and use the vIOMMU.

[0059] In an example, the user-mode program is QEMU, and the virtual machine kernel module is KVM. After QEMU creates the vIOMMU through a creation command, the vIOMMU running in the kernel mode at the first privilege level can register the device address segment it manages on the KVM I / O BUS. When the VM accesses the vIOMMU, KVM will find a device on the KVM I / O BUS that can handle the access. At this time, it can find the vIOMMU and then transfer the access request to the vIOMMU for processing.

[0060] In an embodiment of the present application, since the vIOMMU runs in the kernel state of the first privilege level, the vIOMMU can register the device address segment it manages to the I / O bus of the virtual machine kernel module. When the access request exits to the virtual machine kernel module, the virtual machine kernel module can find the vIOMMU that can process the access request from the I / O bus, and then send the access request to the vIOMMU for processing. Therefore, when configuring the IOMMU, it is ensured that the access request can be transmitted to the vIOMMU quickly and reliably, thereby ensuring the efficiency and reliability of the IOMMU configuration.

[0061] In one possible implementation, a user-mode program may register the device address segment managed by vIOMMU with the I / O bus of the virtual machine kernel module. The device address of the device managed by vIOMMU is located within the device address segment managed by vIOMMU. vIOMMU may manage one or more hardware and software devices. The embodiment of the present application does not limit the number and type of devices managed by vIOMMU.

[0062] After the VM kernel module receives an access request, it parses the request to determine the device address to be accessed. After obtaining the device address, the VM kernel module compares it with the address segment registered on its I / O bus. If the device address falls within the device address segment managed by the vIOMMU, the vIOMMU is identified as the device to handle the access request and the request is sent to the vIOMMU for processing.

[0063] For some other access requests, if the device address to be accessed by the access request is not within the device address segment managed by vIOMMU, it means that vIOMMU cannot process the access request. The virtual machine kernel module will process the access request on its own or send the access request to other modules outside vIOMMU for processing.

[0064] In an embodiment of the present application, the virtual kernel module compares the device address to be accessed by the access request with the device address segment managed by the vIOMMU. If the device address to be accessed by the access request is within the device address segment managed by the vIOMMU, it means that the access request can be processed by the vIOMMU, and then the access request is sent to the vIOMMU for processing, ensuring that the access request can be accurately sent to the vIOMMU so that the access request can be processed by the vIOMMU, thereby ensuring that the IOMMU configuration process can proceed smoothly.

[0065] In one possible implementation, when creating the vIOMMU, the device address segment managed by the vIOMMU is registered on the I / O bus. Correspondingly, when the user-state program shuts down the VM, the user-state program can unregister the device address segment managed by the vIOMMU from the I / O bus, then release various resources managed by the vIOMMU and shut down the vIOMMU.

[0066] After a user-mode program shuts down a VM, the vIOMMU corresponding to the VM must be shut down to release the resources managed by the vIOMMU. When the vIOMMU is created, the device address segments managed by the vIOMMU are registered with the I / O bus of the VM kernel module. Before shutting down the vIOMMU, the device address segments managed by the vIOMMU must be unregistered from the I / O bus of the VM kernel module. Finally, shut down the vIOMMU.

[0067] After receiving the instruction to shut down the VM, the user-mode program can call the release function provided by the virtual machine kernel module (such as KVM) through the system to unregister the device address segment managed by vIOMMU from the I / O bus of the virtual machine kernel module, and shut down the vIOMMU through the system call of the shutdown function provided by the virtual machine kernel module.

[0068] In an embodiment of the present application, before shutting down the vIOMMU, the device address segment managed by the vIOMMU is deregistered from the I / O bus of the virtual machine kernel module, and then the vIOMMU is shut down through a system call to avoid the device address segment managed by the vIOMMU remaining on the I / O bus of the virtual machine kernel module after shutting down the vIOMMU, which affects the search efficiency of the virtual machine kernel module when searching for and processing other accessed devices, and at the same time reduces the resource usage of the virtual machine kernel module.

[0069] In one possible implementation, a VM can be hot migrated or hot upgraded while it's running. Hot migration, also known as live migration, is a mechanism for migrating data or hosts from a source to a destination without interrupting business services. "Non-interruption" here means that services remain continuously available to users, while in reality, there is a brief downtime window during the hot migration process. Hot upgrades involve adding, modifying, or deleting related modules without stopping the program or service to achieve functional or performance upgrades.

[0070] When hot migrating or hot upgrading a VM, the user-mode program can obtain the status information of the VM and vIOMMU on the source side, and then restore the status of the VM and vIOMMU on the destination side based on the status information, thereby migrating the VM and vIOMMU from the source side to the destination side.

[0071] Live migration of a VM involves migrating the VM from one host to another. The host where the VM resided before the migration is the source, and the host where the VM resides after the migration is the destination. Hot upgrading a VM involves upgrading the VM on the same host. Specifically, migrating the VM from one process to another on the same host. In this case, the source and destination are the same host, so a hot upgrade can be considered a local hot migration.

[0072] User-mode programs can save the states of VM and vIOMMU. Saving the state of VM can obtain the state information of VM. Saving the state of vIOMMU can obtain the state information of vIOMMU.

[0073] When hot migrating or hot upgrading a VM, the user-state program running on the source side can send the status information of the VM and vIOMMU on the source side to the user-state program running on the destination side. The user-state program on the destination side can create a VM and vIOMMU on the destination side based on the status information of the VM and vIOMMU on the source side, and set the status of the created VM and vIOMMU based on the status information, so that the VM created on the destination side has the same status as the VM running on the source side, and the vIOMMU created on the destination side has the same status as the vIOMMU running on the source side.

[0074] During the VM state save phase, the user-mode program can use serialization commands to save the state of the source-side vIOMMU, and during the VM state recovery phase, restore the state of the vIOMMU on the destination side through state recovery commands, thereby simultaneously achieving hot migration or hot upgrade of the vIOMMU while completing VM hot migration or hot upgrade.

[0075] In an embodiment of the present application, when hot migrating or hot upgrading a VM, the state of the vIOMMU is saved synchronously when the state of the VM is saved on the source side, and the state of the vIOMMU is restored synchronously when the state of the VM is restored on the destination side, so that the vIOMMU can be hot migrated or hot upgraded synchronously with the VM, ensuring that the vIOMMU can still be used normally after the VM hot migration or hot upgrade, such as updating the configuration information of the IOMMU through the vIOMMU, etc., without recreating the vIOMMU, thereby improving the performance of the vIOMMU and the VM.

[0076] In one possible implementation, while vIOMMU is configuring the IOMMU based on the simulated configuration results, vIOMMU can call functions of functional modules outside of the kernel, such as Virtual Function IO (VFIO) and a privilege-level-one kernel-mode IOMMU driver. When using the functions of these functional modules, vIOMMU invokes the corresponding functions, then sets the simulated configuration results to the IOMMU, completing the IOMMU configuration.

[0077] In an embodiment of the present application, when vIOMMU configures the IOMMU according to the simulation configuration result, if the vIOMMU needs to use the functions of other modules in the kernel, since the vIOMMU runs in the root mode kernel state, the vIOMMU can use the corresponding functions by calling functions. There is no need to switch and copy data between the root mode kernel state and the root mode user state, and there is no need to perform a system call (syscall), thereby improving the configuration efficiency of the IOMMU.

[0078] IOMMU configuration system

[0079] Figure 3 Schematic diagram of an IOMMU configuration system according to an embodiment of the present application. Figure 3 As shown, the IOMMU configuration system 300 includes: VM 301 , vIOMMU 302 and IOMMU 303 , and vIOMMU 302 runs in a kernel state of the first privilege level.

[0080] VM301 can output an access request to vIOMMU302, causing the access request to exit from VM301 to the kernel state of the first privilege level. After the access request exits to the kernel state of the first privilege level, vIOMMU302 running in the kernel state of the first privilege level can read configuration information from the memory of VM301 according to the access request, generate a simulation configuration result based on the configuration information, and configure IOMMU303 based on the simulation configuration result. After configuring IOMMU303, the pass-through device of VM301 can access the memory of VM301 through IOMMU303 in a DMA manner.

[0081] In an embodiment of the present application, after the access request, the kernel state of the first privilege level is exited. Since vIOMMU302 runs in the kernel state of the first privilege level, there is no need to switch back to the user state of the first privilege level to process the access request. Moreover, vIOMMU302 running in the kernel state of the first privilege level can read the configuration information from the memory of VM301 multiple times according to the access request, so that the process of reading the configuration information does not need to switch and copy data multiple times between the kernel state of the first privilege level and the user state of the first privilege level. After obtaining the simulation configuration result, vIOMMU302 can directly set the simulation configuration result to IOMMU303, and there is no need to switch and copy data between the user state of the first privilege level and the kernel state of the first privilege level. It can be seen from this that vIOMMU302 is implemented in the kernel state of the first privilege level. In the process of configuring IOMMU303 through vIOMMU302, the number of switches and data copies between the user state of the first privilege level and the kernel state of the first privilege level are reduced, and the time required for the configuration of IOMMU303 is saved, thereby improving the configuration efficiency of IOMMU303.

[0082] In a possible implementation, VM 301 runs at a second privilege level, and the permission set of the second privilege level is a subset of the permission set of the first privilege level.

[0083] VM301 is built using a user-mode program, which runs in user mode at the first privilege level. Therefore, VM301 runs at the second privilege level. For example, VM301 can be built using the user-mode program QEMU. This user-mode program can build multiple VMs and allocate different software and hardware resources to different VMs, such as assigning different passthrough devices to different VMs. Taking the x86 architecture as an example, the VM runs in non-root mode, while the host runs in root mode. Root mode includes root user mode and root kernel mode. QEMU runs in root user mode, and vIOMMU runs in root kernel mode. A vIOMMU access request from the VM first exits from non-root mode to root kernel mode. If vIOMMU is running in root user mode, the access request must continue to exit to QEMU running in root user mode. If vIOMMU is running in root kernel mode, the access request does not need to exit to root user mode.

[0084] In an embodiment of the present application, VM301 runs at the second privilege level and cannot directly configure IOMMU303. VM301 configures IOMMU303 through vIOMMU302 running in the kernel state of the first privilege level. vIOMMU302 can directly access the memory of VM301 to obtain configuration information without switching back to the user state of the first privilege level. During the IOMMU303 configuration process, there is no need to switch and copy data multiple times between the kernel state and the user state of the first privilege level, which saves the time for switching between the kernel state and the user state of the first privilege level, and the time for copying data between the kernel state and the user state of the first privilege level, thereby improving the efficiency of IOMMU303 configuration.

[0085] In a possible implementation, the IOMMU configuration system may further include a virtual machine kernel module and a user-mode program, wherein the virtual machine kernel module runs in a kernel mode of the first privilege level, and the user-mode program runs in a user mode of the first privilege level.

[0086] The user-mode program can create vIOMMU302 using a create command and register the device address segment managed by vIOMMU302 with the I / O bus of the virtual machine kernel module. The virtual machine kernel module can obtain the access request output by VM301, and based on the device address to be accessed by the access request and the device address segment registered on the I / O bus, determine that the device that handles the access request is vIOMMU302, and send the access request to vIOMMU302.

[0087] In an embodiment of the present application, the virtual kernel module compares the device address to be accessed by the access request with the device address segment managed by vIOMMU302. If the device address to be accessed by the access request is within the device address segment managed by vIOMMU302, it means that the access request can be processed by vIOMMU302, and then the access request is sent to vIOMMU302 for processing, ensuring that the access request can be accurately sent to vIOMMU302 so that vIOMMU302 can process the access request, thereby ensuring that the IOMMU303 configuration process can proceed smoothly.

[0088] Figure 4 FIG. 1 is a schematic diagram showing a configuration system of an IOMMU according to another embodiment of the present application. Figure 4 As shown, IOMMU configuration system 300 includes VM 301, vIOMMU 302, and IOMMU 303, as well as a virtual machine kernel module 304 and a kernel-mode IOMMU driver 305. Virtual machine kernel module 304 may be KVM. VM 301 includes an IOMMU driver 3011 running in kernel mode at the first privilege level. VM 301 can initiate access requests to vIOMMU 302 through IOMMU driver 3011. VM 301 is built using the user-mode program QEMU.

[0089] The following combination Figure 4 , the process of configuring IOMMU303 is described. The process of configuring IOMMU303 can be implemented according to the following steps:

[0090] S1. In response to the access request from VM301 to vIOMMU302, the access request exits from VM301 to the kernel state of the first privilege level.

[0091] VM301 can issue an access request to vIOMMU302 through IOMMU driver 3011, and the access request is used to configure IOMMU303. After VM301 issues the access request, the access request will exit from VM301 to the kernel state of the first privilege level. After exiting from VM301 to the kernel state of the first privilege level, the access request will be obtained by the virtual machine kernel module 304 running in the kernel state of the first privilege level.

[0092] After VM301 issues the access request, when the hardware executes the read instruction and / or write instruction according to the access request, the access request will be exited from the hardware to the kernel state of the first privilege level.

[0093] S2. The virtual machine kernel module 304 sends an access request to the vIOMMU 302.

[0094] After receiving the access request, the virtual machine kernel module 304 will transfer the access request to the vIOMMU302 running in the kernel state of the first privilege level because the virtual machine kernel module 304 cannot process the access request, so that the vIOMMU302 can process the access request.

[0095] After receiving the access request, the virtual machine kernel module 304 can parse the access request to determine the device address to be accessed by the access request, and then compare the device address to be accessed by the access request with the address segment registered on its I / O bus. If the device address to be accessed by the access request is within the device address segment managed by vIOMMU302, vIOMMU302 is determined as the device to handle the access request, and the access request is sent to vIOMMU302.

[0096] When constructing VM301, the user-mode program QEMU creates a vIOMMU302 running in kernel mode at the first privilege level, and registers the device address segment managed by vIOMMU302 on the I / O bus of the virtual machine kernel module 304.

[0097] Since the vIOMMU 302 runs in the kernel state of the first privilege level, the process of switching back to the user state of the first privilege level and copying data to the user state of the first privilege level is avoided.

[0098] S3. vIOMMU 302 reads configuration information from the memory of VM 301 according to the access request, and generates a simulation configuration result according to the configuration information.

[0099] After receiving the access request, vIOMMU302 can access VM301's memory multiple times to read configuration information for configuring IOMMU303 from VM301's memory. After reading some configuration information from VM301's memory, vIOMMU302 can generate a portion of simulated configuration results based on this configuration information. It can also determine what other configuration information is needed based on the configuration information it has read, and then read the required configuration information from VM301's memory. By reading VM301's memory multiple times, it can generate all the simulated configuration results required to configure IOMMU303.

[0100] vIOMMU 302 needs to access VM 301's memory multiple times based on access requests to read configuration information from VM 301's memory. Since vIOMMU 302 runs in kernel state at the first privilege level, it can directly access VM 301's memory without using read / write system calls. This avoids the need for multiple switching between user state at the first privilege level and kernel state at the first privilege level and data copying in this step.

[0101] S4. vIOMMU 302 configures IOMMU 303 according to the simulation configuration result.

[0102] After obtaining the simulation configuration result of IOMMU303, vIOMMU302 can directly call the API provided by the IOMMU driver 305 running in the kernel state of the first privilege level. After the API of the IOMMU driver 305 is called by vIOMMU302, it will issue a configuration instruction to write the simulation configuration result to the host machine's memory, so that IOMMU303 can run according to the simulation configuration result written to the host machine's memory, completing the configuration of IOMMU303.

[0103] Since vIOMMU302 runs in the kernel state of the first privilege level, vIOMMU302 can directly call the API provided by the IOMMU driver 305 to set the simulation configuration result to IOMMU303 without switching between the user state of the first privilege level and the kernel state of the first privilege level and copying data.

[0104] In an embodiment of the present application, vIOMMU302 runs in the kernel state of the first privilege level. In the process of configuring IOMMU303 through vIOMMU302, a large number of switches and data copies between the user state of the first privilege level and the kernel state of the first privilege level are avoided, thereby improving the configuration efficiency of IOMMU303 and optimizing the performance of vIOMMU302.

[0105] It should be noted that the interactions between the various components of the above-mentioned IOMMU configuration system are based on the same concept as the above-mentioned IOMMU configuration method embodiment. The specific contents and beneficial effects can be found in the description of the above-mentioned IOMMU configuration method embodiment, and will not be repeated here.

[0106] electronic devices

[0107] Figure 5 This is a schematic block diagram of an electronic device provided in an embodiment of the present application. The specific embodiments of the present application do not limit the specific implementation of the electronic device. Figure 5 As shown, the electronic device may include: a processor 502, a communications interface 504, a memory 506, and a communication bus 508.

[0108] The processor 502 , the communication interface 504 , and the memory 506 communicate with each other via a communication bus 508 .

[0109] The communication interface 504 is used to communicate with other electronic devices or servers.

[0110] The processor 502 is configured to execute the program 510, and specifically may execute the relevant steps in any of the aforementioned IOMMU configuration method embodiments.

[0111] Specifically, the program 510 may include program codes, which include computer operation instructions.

[0112] The processor 502 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs, or may be processors of different types, such as one or more CPUs and one or more ASICs.

[0113] RISC-V is an open-source instruction set architecture based on the principles of the Reduced Instruction Set (RISC). It can be applied to various fields, including microcontrollers and FPGA chips. Specifically, it has applications in areas such as IoT security, industrial control, mobile phones, and personal computers. Designed with small size, high speed, and low power consumption in mind, it is particularly suitable for modern computing devices such as warehouse-scale cloud computers, high-end mobile phones, and tiny embedded systems. With the rise of the artificial intelligence (AI) Internet of Things (AIoT), the RISC-V instruction set architecture has also received increasing attention and support, and is expected to become the next generation of widely used CPU architecture.

[0114] The computer operation instructions in the embodiments of the present application may be computer operation instructions based on the RISC-V instruction set architecture. Correspondingly, the processor 502 may be designed based on the RISC-V instruction set. Specifically, the processor chip in the electronic device provided in the embodiments of the present application may be a chip designed using the RISC-V instruction set. The chip may execute executable code based on the configured instructions, thereby implementing the IOMMU configuration method in the above-mentioned embodiments.

[0115] The memory 506 is used to store the program 510. The memory 506 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0116] The program 510 may be specifically configured to enable the processor 502 to execute the IOMMU configuration method in any of the aforementioned embodiments.

[0117] The specific implementation of each step in program 510 can refer to the corresponding description of the corresponding steps and units in any of the aforementioned IOMMU configuration method embodiments, and will not be repeated here. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here.

[0118] Through the electronic device of the embodiment of the present application, after the VM issues an access request to the vIOMMU, the access request exits from the VM to the kernel state of the first privilege level. Since the vIOMMU runs in the kernel state of the first privilege level, there is no need to switch back to the user state of the first privilege level to process the access request. Moreover, the vIOMMU running in the kernel state of the first privilege level can read the configuration information from the memory of the VM multiple times according to the access request, so that the process of reading the configuration information does not need to switch and copy data between the kernel state of the first privilege level and the user state of the first privilege level multiple times. After obtaining the simulation configuration result, the vIOMMU can directly set the simulation configuration result to the IOMMU, and there is also no need to switch and copy data between the user state of the first privilege level and the kernel state of the first privilege level. It can be seen from this that vIOMMU is implemented in the kernel state of the first privilege level. In the process of configuring the IOMMU through the vIOMMU, the number of switches and data copies between the user state of the first privilege level and the kernel state of the first privilege level are reduced, saving the time required for the configuration of IOMMU303, thereby improving the configuration efficiency of IOMMU303.

[0119] Computer storage media

[0120] This application also provides a computer-readable storage medium storing instructions for causing a machine to execute the IOMMU configuration method as described herein. Specifically, a system or device equipped with a storage medium can be provided, on which software program code implementing the functions of any of the above-described embodiments is stored, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0121] In this case, the program code read from the storage medium itself can realize the function of any one of the above embodiments, so the program code and the storage medium storing the program code constitute part of this application.

[0122] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code can be downloaded from a server computer via a communication network.

[0123] Computer program product

[0124] An embodiment of the present application also provides a computer program product, including computer instructions, which instruct a computing device to perform any corresponding operation in the above-mentioned multiple method embodiments.

[0125] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0126] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or can be implemented as software or computer code that can be stored in a recording medium (such as CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or can be implemented as computer code that is originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded via a network and will be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a special-purpose processor or programmable or special-purpose hardware (such as ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown here, the execution of the code converts the general-purpose computer into a special-purpose computer for executing the method shown here.

[0127] It should be noted that the user-related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to sample data used to train the model, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of the present disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0128] It should be understood that the various embodiments in this specification are described in a progressive manner. References to the same or similar parts of each embodiment can be made to the other embodiments. The embodiments focus on the differences from other embodiments. In particular, the method embodiments are generally similar to the methods described in the device and system embodiments, so their description is relatively simple. For relevant details, references to the descriptions of other embodiments can be made.

[0129] It should be understood that the foregoing description of this specification is based on specific embodiments. Other embodiments are within the scope of the claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0130] It should be understood that an element described herein in the singular or shown in the drawings as only one does not limit the number of the element to one. In addition, modules or elements described or shown herein as separate may be combined into a single module or element, and modules or elements described or shown herein as single may be split into multiple modules or elements.

[0131] It should also be understood that the terms and expressions used herein are for descriptive purposes only, and the one or more embodiments of this specification should not be limited to these terms and expressions. The use of these terms and expressions does not mean to exclude any equivalent features of the illustrations and descriptions (or portions thereof), and it should be recognized that various modifications that may exist should also be included in the scope of the claims. Other modifications, variations, and substitutions may also exist. Accordingly, the claims should be deemed to cover all such equivalents.

Claims

1. A method for configuring an input / output memory management unit, comprising: In response to a virtual machine's access request to a virtual input / output memory management unit, the virtual machine exits the access request to a kernel state at a first privilege level, wherein the virtual input / output memory management unit runs in the kernel state at the first privilege level; The virtual input / output memory management unit reads configuration information from the memory of the virtual machine according to the access request, and generates a simulation configuration result according to the configuration information; The virtual input / output memory management unit configures the input / output memory management unit according to the simulation configuration result.

2. The method according to claim 1, wherein The virtual machine runs at a second privilege level, and a permission set of the second privilege level is a subset of the permission set of the first privilege level.

3. The method according to claim 1, further comprising: After the access request exits from the virtual machine to the kernel state of the first privilege level, the virtual machine kernel module running in the kernel state of the first privilege level obtains the access request; The virtual machine kernel module sends the access request to the virtual input and output memory management unit.

4. The method according to claim 3, further comprising: A user state program running in a user state at the first privilege level creates the virtual input / output memory management unit through a creation command, and registers the device address segment managed by the virtual input / output memory management unit to the input / output bus of the virtual machine kernel module; The virtual machine kernel module sends the access request to the virtual input / output memory management unit, including: the virtual machine kernel module determines, based on the device address to be accessed by the access request and the device address segment, that the device that processes the access request is the virtual input / output memory management unit, and sends the access request to the virtual input / output memory management unit.

5. The method according to claim 4, wherein The step of determining that the device for processing the access request is the virtual input / output memory management unit includes: After verifying that the device address to be accessed by the access request is located in the device address segment registered by the virtual input / output memory management unit on the input / output bus, the virtual input / output memory management unit is determined as the device to process the access request.

6. The method according to claim 4, further comprising: Before the user state program shuts down the virtual machine, the user state program deregisters the device address segment managed by the virtual input / output memory management unit from the input / output bus, releases the resources managed by the virtual input / output memory management unit, and shuts down the virtual input / output memory management unit.

7. The method according to claim 4, further comprising: When hot migrating or hot upgrading the virtual machine, the user state program obtains the state information of the virtual machine and the virtual input / output memory management unit at the source end, and restores the state of the virtual machine and the virtual input / output memory management unit at the destination end according to the state information.

8. The method according to any one of claims 1 to 7, wherein: The virtual input / output memory management unit configures the input / output memory management unit according to the simulation configuration result, including: The virtual input / output memory management unit calls the driver of the input / output memory management unit in the kernel and sets the simulation configuration result to the input / output memory management unit.

9. A configuration system for an input / output memory management unit, comprising: A virtual machine, a virtual input / output memory management unit and an input / output memory management unit, wherein the virtual input / output memory management unit runs in a kernel state at a first privilege level; The virtual machine is configured to output an access request to the virtual input / output memory management unit, so that the access request exits from the virtual machine to a kernel state at the first privilege level; The virtual input / output memory management unit is configured to read configuration information from the memory of the virtual machine according to the access request, generate a simulation configuration result according to the configuration information, and configure the input / output memory management unit according to the simulation configuration result.

10. The system according to claim 9, wherein: The virtual machine runs at a second privilege level, and a permission set of the second privilege level is a subset of the permission set of the first privilege level.

11. The system according to claim 9, further comprising: A virtual machine kernel module and a user-mode program, wherein the virtual machine kernel module runs in the kernel mode of the first privilege level, and the user-mode program runs in the user mode of the first privilege level; The user state program is used to create the virtual input and output memory management unit through a creation command, and register the device address segment managed by the virtual input and output memory management unit to the input and output bus of the virtual machine kernel module; The virtual machine kernel module is configured to obtain the access request output by the virtual machine, and determine, based on the device address to be accessed by the access request and the device address segment registered on the input / output bus, that the device processing the access request is the virtual input / output memory management unit, and send the access request to the virtual input / output memory management unit.

12. An electronic device comprising: Processor, memory, communication interface and communication bus, the processor, memory and communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform an operation corresponding to any one of the methods according to claims 1-8.

13. A computer storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

14. A computer program product comprising computer instructions, the computer instructions instructing a computing device to execute the method according to any one of claims 1 to 8.

Images