Configuration method for input-output memory management unit, electronic device, and storage medium

Abstract

Embodiments of the present disclosure provide a configuration method for an input-output memory management unit, an electronic device, and a storage medium. The configuration method for an input-output memory management unit comprises: in response to an access request of a virtual machine to the virtual input-output memory management unit, the access request causes an exit from the virtual machine to a kernel mode at a first privilege level, wherein the virtual input-output memory management unit operates in the kernel mode at the first privilege level; the virtual input-output memory management unit reads configuration information from a memory of the virtual machine on the basis of the access request, and generates a simulation configuration result on the basis of the configuration information; and the virtual input-output memory management unit configures an input-output memory management unit on the basis of the simulation configuration result. The solution improves the configuration efficiency for input-output memory management units.

Description

[0001] Configuring an Input-Output Memory Management Unit, Electronic Device, and Storage Medium This disclosure claims priority to Chinese Patent Application No. 202410269645.9, filed with the China Patent Office on March 8, 2024, entitled "Configuring an Input-Output Memory Management Unit, Electronic Device, and Storage Medium," the entire contents of which are incorporated herein by reference. Technical Field The present disclosure relates to the field of computer technology, and more particularly to a configuring method, electronic device, and storage medium for an input-output memory management unit. Background: To enable a virtual machine's passthrough device to read and write the virtual machine's memory via Direct Memory Access (DMA), a virtual input-output memory management unit (IOMMU) must be configured for the virtual machine. Currently, when configuring the IOMMU, the virtual input-output memory management unit (IOMMU) running in user mode is used to access the virtual machine's memory.

[0002] The Input-Output Memory Management Unit (VI OMMU) configures the I OMMU. However, because the VI OMMU is implemented in user mode, multiple switches between kernel mode and user mode and data copies are required during I OMMU configuration, resulting in low I OMMU configuration efficiency. In view of this, embodiments of the present disclosure provide an I / O memory management unit configuration method, electronic device, and storage medium to at least partially address the aforementioned issues. According to a first aspect of embodiments of the present disclosure, a method for configuring an I / O memory management unit is provided, comprising: responding to a virtual machine's access request to a virtual I / O memory management unit, exiting the virtual machine to kernel mode at a first privilege level, wherein the virtual I / O memory management unit operates in kernel mode at the first privilege level; reading configuration information from the virtual machine's memory based on the access request, and generating a simulated configuration result based on the configuration information; and configuring the I / O memory management unit based on the simulated configuration result. According to a second aspect of an embodiment of the present disclosure, a system for configuring 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 operates in 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, causing the access request to exit from the virtual machine to kernel state at the first privilege level; the virtual input / output memory management unit is configured to read configuration information from the virtual machine's memory in response to the access request, generate a simulated configuration result based on the configuration information, and configure the input / output memory management unit based on the simulated configuration result. According to a third aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is configured to store at least one executable instruction, wherein the executable instruction causes the processor to perform operations corresponding to the method described in the first aspect. According to a fourth aspect of an embodiment of the present disclosure, a computer storage medium is provided, storing a computer program, which, when executed by the processor, implements the method described in the first aspect. According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, including computer instructions, wherein the computer instructions instruct a computing device to execute the method described in the first aspect.As can be seen from the above technical solution, when 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 operates in the kernel state of the first privilege level, it does not need to switch back to the user state of the first privilege level to process the access request. Furthermore, the virtual input / output memory management unit operating 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. This eliminates the need for multiple switching between the kernel state of the first privilege level and the user state of the first privilege level and data copying during the configuration information reading process. After obtaining the simulated configuration result, the virtual input / output memory management unit can directly set the simulated configuration result to the input / output memory management unit, again eliminating the need for switching between the user state of the first privilege level and the kernel state of the first privilege level and data copying. Thus, by implementing a virtual I / O memory management unit in kernel mode at the first privilege level, the process of configuring the I / O memory management unit through the virtual I / O memory management unit reduces the number of switches between user mode at the first privilege level and kernel mode at the first privilege level, as well as data copying, thereby saving the time required for configuring the virtual I / O memory management unit and improving the configuration efficiency of the virtual I / O memory management unit. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following briefly introduces the figures required for use in the embodiments or the prior art description. Obviously, the figures described below are only some of the embodiments described in the embodiments of the present disclosure, and those skilled in the art can also obtain other figures based on these figures. FIG1 is a schematic diagram of an exemplary system used in one embodiment of the present disclosure; FIG2 is a flowchart of a configuration method for an I / O memory management unit in one embodiment of the present disclosure; FIG3 is a schematic diagram of a configuration system for an I / O memory management unit in one embodiment of the present disclosure; FIG4 is a schematic diagram of a configuration system for an I / O memory management unit in another embodiment of the present disclosure; and FIG5 is a schematic diagram of an electronic device in one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS The present disclosure is described below based on embodiments, but the present disclosure is not limited to these embodiments. In the detailed description of the present disclosure below, certain specific details are described in detail. Those skilled in the art will be able to fully understand the present disclosure without these details. To avoid obscuring the essence of the present disclosure, well-known methods, processes, and procedures are not described in detail. Furthermore, the drawings are not necessarily drawn to scale. First, some terms or terminology used in the description of the embodiments of the present disclosure are subject to the following explanations.Input-Output Memory Management Unit (IOMMU): The I / O Memory Management Unit (IOMMU) connects the I / O bus (I / O bus) to main memory and converts the I / O virtual addresses in device DMA requests into physical addresses. Virtual I / O Memory Management Unit (VIMMU): The virtual I / O Memory Management Unit (VIMMU) is a software-implemented I / O OMMU device in virtualized scenarios. Kernel state: Kernel state is an operating system's operating state. The CPU in kernel state can access any data, including peripheral devices such as network cards and hard drives. The CPU in kernel state can switch from one program to another without preemption. Generally, the state at privilege level 0 is called kernel state. User mode: User mode is another operating system state. The CPU in user mode can access restricted resources but cannot directly access hardware devices such as memory. Access to these privileged resources requires trapping to kernel mode through system calls. Root mode and non-root mode: Before virtualization, systems consisted of user mode and kernel mode. To meet the needs of virtualization, two privilege levels, the first and second, were added. For example, in the X86 architecture, the first privilege level is root mode, and the second privilege level is non-root mode. Non-root mode is also called guest mode. oBoth the first and second privilege levels include kernel mode and user mode. The CPU's privileges in kernel mode are higher than those in user mode. The CPU's privileges in the first privilege level are greater than those in the second privilege level. The privilege set of the first privilege level is a subset of the privilege set of the second privilege level. In the disclosed embodiment, the V1 OMMU, KVM, and I OMMU driver all run in kernel mode at the first privilege level, while the VM and its I OMMU driver run at the second privilege level. Virtual Machine (VM): A virtual machine (VM) is a complete computer system with complete hardware system functionality, simulated by software, running in a completely isolated environment. Direct Memory Access (DMA): 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. Exemplary System: Figure 1 illustrates an exemplary system suitable for the key generation method of the disclosed embodiment. As shown in FIG1 , the system may include a cloud service end 102, a communication network 104, and at least one user device 106. FIG1 illustrates multiple user devices 106. o It should be noted that the solution of the embodiment of the present disclosure can be applied to both the cloud server 102 and the user device 106. oThe cloud server 102 can be any suitable 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, and the like. In some embodiments, the cloud server 102 can perform any suitable function. For example, in some embodiments, the cloud server 102 can be used to build a virtualized environment and configure a virtual I OMMU for a VM, enabling the VM to support the Process Address Space ID (PAS ID) feature. This allows different processes in the VM to share a pass-through device and, in turn, access the VM's memory via the I OMMU using DMA. As an alternative example, in some embodiments, the cloud server 102 can implement the virtual I OMMU in kernel mode, and user-mode programs can configure the I OMMU using the virtual I OMMU implemented in kernel mode. This avoids frequent switching between kernel mode (at the first privilege level) and user mode (at the first privilege level) and data copying during I OMMU configuration, thereby improving the performance of the virtual I OMMU emulated device. 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 connected to the cloud service end 102 via one or more communication links (e.g., communication link 114). oThe communication link can be any communication link suitable for transmitting data between the cloud service 102 and the user device 106, such as a network link, a dial-up link, a wireless link, a hardwired link, any other suitable communication link, or any suitable combination of such links. The user device 106 can include any one or more user devices suitable for interaction. In some embodiments, upon receiving a request from the user device 106, the cloud service 102 can construct a VM in a virtualized environment for use and operation by the user device 106. During the VM construction process, the VM's VI OMMU is constructed in kernel state at the first privilege level, and the VM's I OMMU is configured using the constructed VI OMMU, so that the VM's passthrough device can access the VM's memory in a DMA manner through the configured I OMMU. Furthermore, during the user device 106's use of the VM, upon receiving instructions from the user device 106, the VM can send memory access instructions to its passthrough device, allowing the passthrough device to directly access the VM's memory through the I OMMU. User device 106 may include any suitable type of device. For example, 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. The present embodiment of the disclosure primarily focuses on the process of configuring the I OMMU on the cloud server 102. The I OMMU configuration process will be described in detail below.

[0003] Based on the above-mentioned system, an embodiment of the present disclosure provides an I OMMU configuration method. The I OMMU configuration method is described in detail below through multiple embodiments. Figure 2 is a flow chart of the I OMMU configuration method according to one embodiment of the present disclosure. As shown in Figure 2, the I OMMU configuration method includes the following steps: Step 201: In response to a VM's access request to the v1 OMMU, the VM exits the access request to kernel state at the first privilege level. When building a VM, a user-mode program can create a v1 OMMU for the VM. The v1 OMMU runs in kernel state at the first privilege level. The user-mode program can manage the v1 OMMU through system call functions. The user-mode program can be QEMU.

[0004] After a VM is created, it can send an access request to its vIOMMU. For example, the VM can read or write to the vIOMMU through an IOMMU driver (VM IOMMU driver) running in kernel state at the second privilege level. This access request will cause the VM to exit kernel state at the first privilege level. In step 202, the vIOMMU reads configuration information from the VM's memory in response to the access request and generates a simulated configuration result based on the configuration information. After the access request exits kernel state at the first privilege level, the vIOMMU receives the access request. Since the vIOMMU runs in kernel state at the first privilege level, it has permission to access the VM's memory without having to exit kernel state to user state at the first privilege level. The vIOMMU can then read the configuration information from the VM's memory in response to 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 in response to the access request. When OMMU 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, it can generate a portion of the simulated configuration based on this configuration information. It can also determine what other configuration information is needed based on this configuration information, and then read the configured information from the VM's memory again. By reading the VM's memory multiple times, it can generate all the simulated configuration structures required to configure the IOMMU.

[0005] The VM cannot directly configure the IOMMU hardware, so the user-mode program constructs a vIOMMU and simulates the IOMMU hardware through the vIOMMU. The VM simulates the IOMMU configuration process through the vIOMMU, and the vIOMMU then sets the simulated configuration results to the IOMMU hardware, indirectly configuring the IOMMU hardware. Step 203: The vIOMMU configures the IOMMU based on the simulated configuration results. The vIOMMU simulates the IOMMU hardware configuration process, processes the read configuration information, obtains the simulated configuration results, and then sets the simulated configuration results to the IOMMU hardware to complete the IOMMU configuration. During the simulated configuration process, the vIOMMU can call the Application Programming Interface (API) provided by the IOMMU driver (kernel II OMMU driver) running at the first privilege level in kernel mode to set the simulated configuration results to the IOMMU, completing the simulation. During the configuration simulation process, the vl OMMU 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. v After obtaining the partial simulation configuration results, the v IOMMU can call the API of the IOMMU driver running in kernel mode at the first privilege level to set these partial simulation configuration results to the IOMMU. ov The IOMMU 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. In the disclosed embodiment, after a VM issues an access request to a v1OMMU, the access request exits the virtual machine to the kernel state at the first privilege level. Since the v1OMMU runs in the kernel state at the first privilege level, there is no need to switch back to the user state at the first privilege level to process the access request. Furthermore, the v1OMMU running in the kernel state at the first privilege level can read configuration information from the VM's memory multiple times based on the access request. This eliminates the need for multiple switches between the kernel state at the first privilege level and the user state at the first privilege level, and data copies, during the configuration information reading process. After obtaining a simulated configuration result, the v1OMMU can directly set the simulated configuration result to the IOMMU, again eliminating the need for multiple switches between the user state at the first privilege level and the kernel state at the first privilege level and data copies.As can be seen, implementing the vIOMMU in kernel state at the first privilege level reduces the number of switches and data copies between user state at the first privilege level and kernel state at the first privilege level during IOMMU configuration, thus saving the time required for IOMMU configuration and improving IOMMU configuration efficiency. In one possible implementation, the VM runs at the second privilege level, and the permission set of the second privilege level is a subset of the permission set of the first privilege level.

[0006] A VM is built by a user-mode program, which runs in user mode (privilege level 1), so the VM runs at privilege level 2. For example, a VM 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, a 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 the v1OMMU runs in root kernel mode. A VM that requests a v1OMMU access will first exit from non-root mode to root kernel mode. If the v1OMMU is running in root user mode, the access request must continue to exit to QEMU running in root user mode. If the v1OMMU is running in root kernel mode, the access request does not need to exit to root user mode. In the disclosed embodiment, a VM running at the second privilege level cannot directly configure the IOMMU. Instead, the VM configures the IOMMU via the virtual IOMMU running in kernel state at the first privilege level. The virtual IOMMU can directly access the VM's memory to obtain configuration information without switching back to user state at the first privilege level. During the IOMMU configuration process, multiple switches between kernel state at the first privilege level and user state and data copies are not required. This saves time switching between kernel state at the first privilege level and user state, as well as time copying data between kernel state at the first privilege level and user state, thereby improving IOMMU configuration efficiency. In one possible implementation, a virtual machine kernel module runs in kernel state at the first privilege level. The virtual machine kernel module may be a kernel-based virtual machine (KVM). When the VM exits to the kernel state at the first privilege level in response to the access request to the v1OMMU, the access request may be exited 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 v1OMMU. 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 v1OMMU running in the kernel state at the first privilege level, and the v1OMMU will process the access request.In the disclosed embodiments, a virtual machine kernel module can provide a virtualization core architecture and processor specifications. User state at the first privilege level and kernel state at the first privilege level are switched via the virtual machine kernel module. After an access request exits the virtual machine kernel module, the virtual machine kernel module cannot process the access request. The virtual machine kernel module then forwards the access request to the virtual IOMMU for processing. Because both the virtual machine kernel module and the virtual IOMMU operate in kernel state at the first privilege level, the virtual machine kernel module can directly forward the access request to the virtual IOMMU in kernel state at the first privilege level, eliminating the need to switch between kernel state and user state at the first privilege level and copy data. This improves the performance of the virtual IOMMU and the efficiency of configuring the IOMMU. In one possible implementation, a VM can be constructed by a user state program operating in user state at the first privilege level, such as by using QEMU. After the user state program constructs the VM, a create command can be used to create the virtual IOMMU operating in kernel state at the first privilege level and register the device address segment managed by the virtual IOMMU with 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 and the device address segment registered on the I / O bus. The access request is then transferred to the vIOMMU for management. A user-mode program can receive parameters input by the user and generate a create command carrying these parameters. After executing this create command, the user-mode program can call the corresponding function in the virtual machine kernel module through the system, thereby creating the vIOMMU through the called function. The vIOMMU running in kernel mode at the first privilege level can simulate and implement the functions of various registers according to the IOMMU specification. When creating the vIOMMU, a system device can be registered (for example, with the name kernel_iommu). This allows the user-mode program to obtain a device handle by opening the corresponding directory (for example, / dev / kernel_iommu). The user-mode program can then manage the vIOMMU using this handle and ioctl. Among them, i oct I (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.The v1OMMU provides various commands, including create, initialize, serialize, restore, reset, and release, to facilitate management by user-mode programs. The create command is used to create the v1OMMU in root-mode kernel mode. The initialization command is used to initialize the v1OMMU, including initializing the values ​​of its various registers. The serialize command is used to serialize the v1OMMU device state and send the v1OMMU state data to user-mode programs. The restore command is used to send the v1OMMU state data to the v1OMMU, allowing the v1OMMU to restore its state based on the state data. The reset command is used to reset the v1OMMU, including resetting the values ​​of its various registers. The release command is used to release various resources managed by the v1OMMU. When creating a VM, a kernel-mode v1OMMU at the first privilege level can be opened using the open (" / dev / kernel_v1ommu") command. The v1OMMU can then be created and initialized using the create and initialization commands. By building information into the v1OMMU's Advanced Configuration and Power Management Interface (AGPI) table, the VM kernel can discover and use the v1OMMU. In one example, the user-mode program is QEMU, and the virtual machine kernel module is KVM. After QEMU creates the v1OMMU using a create command, the v1OMMU, running in kernel mode at the first privilege level, can register the device address segment it manages on the KVM I / O bus. When a VM accesses the v1OMMU, KVM locates a device on the KVM I / O bus capable of handling the access, finds the v1OMMU, and then forwards the access request to the v1OMMU for processing. In the disclosed embodiment, since the vIOMMU operates in a kernel state at the first privilege level, the vIOMMU can register the device address segment it manages with the I / O bus of the virtual machine kernel module. When an access request exits to the virtual machine kernel module, the virtual machine kernel module can find a vIOMMU on the I / O bus that can handle the access request and then send the access request to the vIOMMU for processing. This ensures that the access request can be quickly and reliably transmitted to the vIOMMU when configuring the IOMMU, thereby ensuring the efficiency and reliability of IOMMU configuration.In one possible implementation, a user-mode program can register the device address segment managed by the v1OMMU with the I / O bus of the virtual machine kernel module. The device address of the device managed by the v1OMMU is within the device address segment managed by the v1OMMU. The v1OMMU can manage one or more hardware and software devices. The disclosed embodiments do not limit the number and type of devices managed by the v1OMMU. After receiving an access request, the virtual machine kernel module parses the access request to determine the device address to be accessed. After obtaining the device address to be accessed by the access request, the virtual machine kernel module can compare the device address to 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 the v1OMMU, it indicates that the access request can be processed by the v1OMMU. The v1OMMU is then determined as the device to process the access request and the access request is sent to the v1OMMU for processing. For certain other access requests, if the device address to be accessed by the access request is not within the device address segment managed by the v1OMMU, it indicates that the v1OMMU cannot process the access request. The virtual machine kernel module will then process the access request itself or send the access request to another module outside the v1OMMU for processing. In the disclosed embodiment, the virtual kernel module compares the device address to be accessed by the access request with the device address segment managed by the v1OMMU. If the device address to be accessed by the access request is within the device address segment managed by the v1OMMU, it indicates that the access request can be processed by the v1OMMU. The virtual kernel module then sends the access request to the v1OMMU for processing. This ensures that the access request can be accurately sent to the v1OMMU for processing by the v1OMMU, thereby ensuring that the IOMMU configuration process can proceed smoothly. In one possible implementation, when a v1OMMU is created, the device address segment managed by the v1OMMU is registered on the I / O bus. Correspondingly, when a user-mode program shuts down a VM, the user-mode program may deregister the device address segment managed by the v1OMMU from the I / O bus, release various resources managed by the v1OMMU, and shut down the v1OMMU. After the user-mode program shuts down the VM, the v1OMMU corresponding to the VM needs to be shut down to release the resources managed by the v1OMMU.When the v1OMMU is created, the device address segments managed by the v1OMMU are registered with the I / O bus of the virtual machine kernel module. Before shutting down the v1OMMU, the device address segments managed by the v1OMMU must be deregistered from the I / O bus of the virtual machine kernel module, and then the v1OMMU is shut down. After receiving a VM shutdown instruction, the user-mode program can use the system to call a release function provided by the virtual machine kernel module (such as KVM) to deregister the device address segments managed by the v1OMMU from the I / O bus of the virtual machine kernel module, and then use the system to call a shutdown function provided by the virtual machine kernel module to shut down the v1OMMU. In the disclosed embodiment, before shutting down the v1OMMU, the device address segments managed by the v1OMMU are deregistered from the I / O bus of the virtual machine kernel module, and then the v1OMMU is shut down through a system call. This prevents the device address segments managed by the v1OMMU from remaining on the I / O bus of the virtual machine kernel module after it is shut down, which could affect the efficiency of the virtual machine kernel module in searching for and processing other accessed devices. This also reduces the resource usage of the virtual machine kernel module. In one possible implementation, a VM can be hot migrated or hot upgraded while it is running. Hot migration, also known as live migration, is a mechanism that migrates data / hosts from a source to a destination without interrupting service. "No interruption" here means that service remains continuously available to users, while in reality, there is a brief downtime window during the hot migration process. A hot upgrade involves adding, modifying, or deleting relevant functional modules to achieve functional or performance upgrades without stopping the program or service. During a hot migration or hot upgrade of a VM, a user-mode program can obtain state information of the VM and v1 OMMU on the source side. Based on this state information, the VM and v1 OMMU can be restored on the destination side, migrating the VM and v1 OMMU from the source to the destination. Hot migration of a VM involves migrating the VM from one host machine to another. In this case, the host machine where the VM resides before the migration is the source, and the host machine where the VM resides after the migration is the destination. Hot upgrading a VM means upgrading the VM on the same host. Specifically, it involves migrating the VM from one process to another on the same host. In this case, the source and destination are the same host. That is, the hot upgrade can be considered a local hot migration.A user-mode program can save the state of a VM and a v1 OMMU. Saving the state of a VM can obtain VM state information, and saving the state of a v1 OMMU can obtain v1 OMMU state information. When hot migrating or hot upgrading a VM, a user-mode program running on the source side can send the source state information of the VM and v1 OMMU to a user-mode program running on the destination side. The user-mode program on the destination side can create a VM and a v1 OMMU on the destination side based on the source state information of the VM and v1 OMMU, and set the state of the created VM and v1 OMMU based on the state information. This ensures that the VM created on the destination side has the same state as the VM running on the source side, and that the v1 OMMU created on the destination side has the same state as the v1 OMMU running on the source side. During the VM state save phase, the user-mode program can use serialization commands to save the state of the source-side v1OMMU. During the VM state restore phase, the user-mode program can use state restore commands to restore the state of the v1OMMU on the destination-side. This allows for simultaneous hot migration or hot upgrade of the v1OMMU while completing VM hot migration or hot upgrade. In the disclosed embodiment, when hot migrating or hot upgrading a VM, the v1OMMU state is saved simultaneously with saving the VM state on the source-side, and is restored simultaneously with restoring the VM state on the destination-side. This allows the v1OMMU to be hot migrated or hot upgraded synchronously with the VM, ensuring that the v1OMMU can still be used normally after the VM hot migration or hot upgrade. For example, IOMMU configuration information can be updated through the v1OMMU without recreating the v1OMMU, thereby improving the performance of the v1OMMU and the VM. In one possible implementation, while the v1OMMU is configuring the IOMMU based on the simulated configuration results, the v1OMMU can call functions of other functional modules in the kernel, such as Virtual Function Input / Output (VFIO) and a first-privilege-level kernel-mode IOMMU driver. When using the functions of these functional modules, the v1OMMU calls the corresponding functions to implement the functions, and then sets the simulated configuration results to the IOMMU, completing the IOMMU configuration.In the disclosed embodiment, when the VI OMMU configures the IOMMU based on the simulation configuration result, if the VI OMMU needs to use functions of other modules in the kernel, since the VI OMMU runs in the root kernel state, the VI OMMU can use the corresponding functions by calling functions. This eliminates the need to switch between the root kernel state and the root user state, copy data, or perform system calls, thereby improving the configuration efficiency of the IOMMU.

[0007] FIG3 is a schematic diagram of an IOMMU configuration system according to an embodiment of the present disclosure. As shown in FIG3 , the IOMMU configuration system 300 includes: VM 301, vIOMMU 302, and IOMMU 303. vIOMMU 302 runs in kernel state at the first privilege level.

[0008] VM301 can output an access request to vIOMMU302, causing VM301 to exit to kernel state at the first privilege level. After the access request exits to kernel state at the first privilege level, vIOMMU302, running in kernel state at the first privilege level, can read configuration information from VM301's memory based on the access request, generate a simulated configuration result based on the configuration information, and configure IOMMU303 based on the simulated configuration result. After IOMMU303 is configured, VM301's passthrough devices can access VM301's memory via IOMMU303 using DMA. In the disclosed embodiment, after an access request is made, the vIOMMU 302 exits to the kernel state at the first privilege level. Since the vIOMMU 302 runs in the kernel state at the first privilege level, it is not necessary to switch back to the user state at the first privilege level to process the access request. Furthermore, the vIOMMU 302 running in the kernel state at the first privilege level can read configuration information from the memory of VM 301 multiple times according to the access request. This eliminates the need for multiple switching between the kernel state at the first privilege level and the user state at the first privilege level and data copying during the configuration information reading process. After obtaining the simulated configuration result, the vIOMMU 302 can directly set the simulated configuration result to the IOMMU 303, again eliminating the need for switching between the user state at the first privilege level and the kernel state at the first privilege level and data copying. As can be seen, by implementing VIOMMU 302 in kernel state at the first privilege level, the number of switches and data copies between user state at the first privilege level and kernel state at the first privilege level are reduced during configuration of IOMMU 303 through VIOMMU 302, thereby saving the time required for IOMMU 303 configuration and improving IOMMU 303 configuration efficiency. In one possible implementation, VM 301 runs at the second privilege level, and the permission set of the second privilege level is a subset of the permission set of the first privilege level.

[0009] VM301 is built by 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 different passthrough devices. Taking the x86 architecture as an example, a 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 the v1OMMU runs in root kernel mode. When a VM requests a v1OMMU access, it first exits from non-root mode to root kernel mode. If the v1OMMU runs in root user mode, the access request must continue to exit to QEMU running in root user mode. If the v1OMMU runs in root kernel mode, the access request does not need to exit to root user mode. In the disclosed embodiment, VM 301 runs at the second privilege level and cannot directly configure IOMMU 303. VM 301 configures IOMMU 303 through VIOMMU 302 running in kernel state at the first privilege level. VIOMMU 302 can directly access VM 301's memory to obtain configuration information without switching back to user state at the first privilege level. During IOMMU 303 configuration, multiple switching between kernel state and user state at the first privilege level and data copying are unnecessary. This saves time switching between kernel state and user state at the first privilege level and data copying between kernel state and user state at the first privilege level, thereby improving IOMMU 303 configuration efficiency. In one possible implementation, the IOMMU configuration system may further include a virtual machine kernel module and a user state program. The virtual machine kernel module runs in kernel state at the first privilege level, and the user state program runs in user state at the first privilege level. The user-mode program can create a VIOMMU 302 using a create command and register the device address segment managed by the VIOMMU 302 with the I / O bus of the virtual machine kernel module. The virtual machine kernel module can obtain the access request output by VM 301, and based on the device address to be accessed in the access request and the device address segment registered on the I / O bus, determine that the device that handles the access request is the vIOMMU 302, and send the access request to the vIOMMU 302. oIn an embodiment of the present disclosure, the virtual kernel module compares the device address of the access request with the device address segment managed by the vIOMMU 302. If the device address of the access request falls within the device address segment managed by the vIOMMU 302, the access request can be processed by the vIOMMU 302. The virtual kernel module then sends the access request to the vIOMMU 302 for processing. This ensures that the access request is accurately sent to the vIOMMU 302 for processing, thereby ensuring that the IOMMU 303 configuration process proceeds smoothly. FIG4 shows a schematic diagram of an IOMMU configuration system according to another embodiment of the present disclosure. As shown in FIG4, the IOMMU configuration system 300 includes, in addition to the VM 301, the vIOMMU 302, and the IOMMU 303, a virtual machine kernel module 304 and a kernel-mode IOMMU driver 305. The virtual machine kernel module 304 may be a KVM. VM 301 includes an IOMMU driver 3011 running in kernel mode at the first privilege level. VM 301 can initiate access requests to IOMMU 302 through IOMMU driver 3011. VM 301 is built using the user-mode program QEMU. The process of configuring IOMMU 303 is described below with reference to FIG. The process of configuring IOMMU 303 can be implemented as follows:

[0010] 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.

[0011] VM 301 can issue an access request to vIOMMU 302 through IOMMU driver 3011. This access request is used to configure IOMMU 303. After VM 301 issues the access request, VM 301 exits to kernel state at the first privilege level. After exiting to kernel state at the first privilege level, the access request is received by virtual machine kernel module 304 running in kernel state at the first privilege level.

[0012] 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.

[0013] 52. The virtual machine kernel module 304 sends the access request to the vl0MMU 302 oAfter receiving the access request, the virtual machine kernel module 304, unable to process it, forwards the request to the VIOMMU 302 running in kernel mode at the first privilege level for processing. The virtual machine kernel module 304 parses the request to determine the device address to be accessed. The module then compares the device address to the address segment registered on its I / O bus. If the device address falls within the device address segment managed by the VIOMMU 302, the VIOMMU 302 is identified as the device to handle the access request, and the request is then sent to the VIOMMU 302. o When building VM 301, the user-mode program QEMU creates a VIOMMU 302 running in kernel mode at the first privilege level and registers the device address segments managed by VIOMMU 302 with the I / O bus of the virtual machine kernel module 304. Because VIOMMU 302 runs in kernel mode at the first privilege level, the process of switching back to user mode at the first privilege level and copying data to user mode at the first privilege level is avoided.

[0014] 53. IOMMU 302 reads configuration information from VM 301's memory in response to the access request and generates a simulated configuration result based on the configuration information. After receiving the access request, IOMMU 302 may access VM 301's memory multiple times to read configuration information used to configure IOMMU 303. After reading some configuration information from VM 301's memory, IOMMU 302 may generate a portion of the simulated configuration result based on this configuration information. IOMMU 302 may also determine what additional configuration information is needed based on the read configuration information and then read the required configuration information from VM 301's memory. By repeatedly reading from VM 301's memory, IOMMU 302 generates all the simulated configuration results required to configure IOMMU 303.

[0015] VIOMMU 302 needs to access VM 301's memory multiple times based on access requests to read configuration information from VM 301's memory. Because 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.

[0016] 54. VI0MMU302 configures IOMMU303 according to the simulation configuration result.

[0017] After obtaining the simulated configuration result for IOMMU 303, vIOMMU 302 can directly call the API provided by IOMMU driver 305 running in kernel state at the first privilege level. After being called by vIOMMU 302, the API of IOMMU driver 305 will issue a configuration instruction to write the simulated configuration result to the host machine's memory, allowing IOMMU 303 to operate according to the simulated configuration result written to the host machine's memory, completing the configuration of IOMMU 303. Because vIOMMU 302 runs in kernel state at the first privilege level, vIOMMU 302 can directly call the API provided by IOMMU driver 305 to set the simulated configuration result to IOMMU 303, without switching between user state at the first privilege level and kernel state at the first privilege level and without copying data. In the embodiment of the present disclosure, VIOMMU 302 operates in kernel mode at the first privilege level. During the configuration of IOMMU 303 by VIOMMU 302, a large number of switches between user mode at the first privilege level and kernel mode at the first privilege level and data copies are avoided, thereby improving the configuration efficiency of IOMMU 303 and optimizing the performance of VIOMMU 302. It should be noted that the interactions between the various components of the aforementioned IOMMU configuration system are based on the same concept as the aforementioned IOMMU configuration method embodiment. For details and beneficial effects, please refer to the description of the aforementioned IOMMU configuration method embodiment and will not be repeated here. FIG5 is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. The specific implementation of the electronic device is not limited in the present embodiment. As shown in FIG5 , the electronic device may include a processor 502, a communication interface 504, a memory 506, and a communication bus 508. The processor 502, communication interface 504, and memory 506 communicate with each other via a communication bus 508. The communication interface 504 is used to communicate with other electronic devices or servers. The processor 502 is configured to execute a program 510, which may specifically execute the relevant steps of any of the aforementioned IOMMU configuration method embodiments. Specifically, the program 510 may include program code, which may include computer operating instructions.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 disclosure. 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.

[0018] RISC-V is an open-source instruction set architecture based on the Reduced Instruction Set Architecture (RISC) principle. It can be applied to various fields, including single-chip microcomputers and FPGA chips, specifically 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 artificial intelligence (AI) in the Internet of Things (IoT), the RISC-V instruction set architecture has received increasing attention and support, and is expected to become the next generation of widely used CPU architecture. The computer operating instructions in the embodiments of the present disclosure can be computer operating instructions based on the RISC-V instruction set architecture. Accordingly, the processor 502 can be designed based on the RISC-V instruction set. Specifically, the processor chip in the electronic device provided in the embodiments of the present disclosure can be a chip designed using the RISC-V instruction set. This chip can execute executable code based on the configured instructions, thereby implementing the IOMMU configuration method described in the above-mentioned embodiments. Memory 506, used to store program 510 oMemory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device. Program 510 may be specifically configured to cause processor 502 to execute the IOMMU configuration method described in any of the aforementioned embodiments. The specific implementation of each step in program 510 can be found in the 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 ease and brevity of description, the specific operating processes of the devices and modules described above can refer to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here. With the electronic device according to the embodiment of the present disclosure, after a VM issues an access request to the v1 OMMU, the access request exits from the VM to the kernel state of the first privilege level. Since the v1 OMMU operates 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. Furthermore, the v1 OMMU operating in the kernel state of the first privilege level can read configuration information from the VM's memory multiple times in response to the access request. This eliminates the need for multiple switching between the kernel state of the first privilege level and the user state of the first privilege level and data copying during the configuration information reading process. After obtaining a simulated configuration result, the v1 OMMU can directly set the simulated configuration result to the v1 OMMU, again eliminating the need for multiple switching between the user state of the first privilege level and the kernel state of the first privilege level and data copying. As can be seen, by implementing the v1 OMMU in kernel mode at the first privilege level, the number of switches and data copies between user mode at the first privilege level and kernel mode at the first privilege level during configuration of the I OMMU via the v1 OMMU is reduced, saving the time required for I OMMU 303 configuration and thereby improving I OMMU 303 configuration efficiency. Computer Storage Medium: The present disclosure also provides a computer-readable storage medium storing instructions for causing a machine to execute the I OMMU configuration method described herein. Specifically, a system or device equipped with a storage medium may be provided, wherein the storage medium stores software program code that implements the functions of any of the above-described embodiments, and the computer (or CPU or MPU) of the system or device may read and execute the program code stored in the storage medium. In this case, the program code read from the storage medium itself can implement the functions of any of the above-described embodiments. Therefore, the program code and the storage medium storing the program code constitute part of the present disclosure.Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs, and DVD+RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code can be downloaded from a server computer via a communication network. Computer Program Product: The present disclosure also provides a computer program product comprising computer instructions that instruct a computing device to perform any corresponding operation in the aforementioned method embodiments. It should be noted that, depending on implementation needs, the various components / steps described in the present disclosure embodiments may be split into more components / steps, or two or more components / steps or partial operations of components / steps may be combined into new components / steps to achieve the objectives of the present disclosure embodiments. The methods described above according to the embodiments of the present disclosure can be implemented in hardware or firmware, or as software or computer code that can be stored on a recording medium (such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code originally stored on a remote recording medium or non-transitory machine-readable medium downloaded over a network and then stored on a local recording medium. Thus, the methods described herein can be processed by such software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It will be understood that a computer, processor, 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. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods described herein are implemented. Furthermore, when a general-purpose computer accesses the code for implementing the methods described herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods described herein. It should be noted that all 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 for model training, data used for analysis, stored data, and displayed data, etc.) involved in the embodiments of this disclosure are authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. It should be understood that the various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referenced separately. 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 the description is relatively brief. For relevant details, refer to the descriptions of the other embodiments. It should be understood that the above descriptions are specific embodiments of this specification. 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 figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are possible or may be advantageous. It should be understood that the singular description or single illustration of an element herein does not limit the number of such elements to one. Furthermore, modules or elements described or illustrated herein as separate may be combined into a single module or element, and modules or elements described or illustrated herein as a single element may be separated into multiple modules or elements. It should also be understood that the terms and expressions used herein are for descriptive purposes only and should not limit one or more embodiments of this specification to these terms and expressions. The use of these terms and expressions does not exclude any equivalent features illustrated and described (or portions thereof). It should be recognized that various modifications are also encompassed by the scope of the claims. Other modifications, variations, and substitutions are possible. Accordingly, the claims should be deemed to cover all such equivalents. The above descriptions are merely specific embodiments of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any modifications or substitutions that can be readily conceived by a person skilled in the art within the technical scope of this disclosure are encompassed by the scope of protection of this disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

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 to a kernel state at a first privilege level, wherein the virtual input / output memory management unit operates in the kernel state at the first privilege level; the virtual input / output memory management unit reads configuration information from a memory of the virtual machine based on the access request, and generates a simulated configuration result based on the configuration information; and the virtual input / output memory management unit configures the input / output memory management unit based on the simulated 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 determining that the device to process 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, determining the virtual input / output memory management unit 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 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 to set 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 requesting to exit from the virtual machine to the kernel state of 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 / output memory management unit through a creation command, and register 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 is configured to obtain the access request output by the virtual machine, determine that the device that processes the access request is the virtual input / output memory management unit based on the device address to be accessed by the access request and the device address segment registered on the input / output bus, 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, where the executable instruction enables the processor to execute an operation corresponding to any one of the methods of 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, wherein the computer instructions instruct a computing device to execute the method according to any one of claims 1 to 8.

Images