System and method for managing memory address mapping relationship in virtualization scenario

Abstract

Provided in one or more embodiments of the present disclosure are a system and method for managing a memory address mapping relationship in a virtualization scenario. The system comprises: a first virtual input / output memory management unit component, which is assembled on an input / output physical device connected to a host machine, and is used for maintaining a first-level mapping relationship between a guest input / output virtual address allocated to a target virtual machine hosted by the host machine and a guest physical address allocated to the target virtual machine, and performing address translation on the basis of the first-level mapping relationship; and a second virtual input / output memory management unit component, which is assembled on the host machine, and is used for maintaining a second-level mapping relationship between the guest physical address allocated to the target virtual machine and a corresponding host physical address, and performing address translation on the basis of the second-level mapping relationship.

Description

Systems and methods for managing memory address mapping relationships in virtualization scenarios Technical Field

[0001] This disclosure relates to one or more embodiments in the field of virtualization, and more particularly to a system and method for managing memory address mapping relationships in a virtualization scenario. Background Technology

[0002] In the current virtualization scenario, the virtual machines (VMs) hosted on the host machine (or physical machine) typically provide DMA (Direct Memory Access) functionality for peripheral devices such as network cards and disk controllers.

[0003] In virtualization scenarios, the Host Physical Address (HPA) of the I / O physical devices installed on the host machine is typically mapped to the Guest Physical Address (GPA) and assigned to the corresponding virtual machine. This allows the virtual I / O devices within the virtual machine to access the device via the corresponding Guest I / O Virtual Address (gIOVA). Therefore, before performing a DMA operation, the gIOVA needs to be converted to an HPA; that is, the gIOVA to be accessed is first converted to a GPA, and then the GPA is converted to the corresponding HPA for DMA operation. This address translation is typically implemented using IOMMU (Input-Output Memory Management Unit) technology.

[0004] In related technologies, in addition to the IOMMU integrated into the CPU (Central Processing Unit) platform, virtual machine management software such as Hypervisor often needs to create a Virtual IOMMU (Virtual Input / Output Memory Management Unit, or vIOMMU) in the virtualization environment through software simulation. The IOMMU and vIOMMU work together to complete the address translation between the virtual machine and the physical hardware. Specifically, the vIOMMU first converts gIOVA to GPA, and then the IOMMU converts GPA to HPA.

[0005] However, virtual machines typically need to adaptively simulate the vIOMMU based on the host machine's hardware characteristics to ensure compatibility with the IOMMU installed on the host. Therefore, the vIOMMU in a virtual machine is highly correlated with the host machine's hardware and its characteristics. This means that virtual machines hosted on hosts with different hardware characteristics require separate vIOMMUs for each host, resulting in poor compatibility and versatility. Furthermore, the vIOMMU in related technologies is entirely simulated in software (such as the aforementioned Hypervisor). Therefore, modifications and updates to page tables that record memory address mappings require write interception by the Hypervisor. This write interception necessitates high-overhead mode switching by the virtual machine, severely limiting system performance. Clearly, the vIOMMU solutions in related technologies suffer from poor compatibility and low performance, requiring urgent improvement. Summary of the Invention

[0006] In view of the above, one or more embodiments of this disclosure provide the following technical solutions.

[0007] According to a first aspect of one or more embodiments of this disclosure, a system for managing memory address mapping relationships in a virtualization scenario is proposed. The system includes: a first virtual input / output memory management unit component, which is mounted on an input / output physical device connected to a host machine, for maintaining a primary mapping relationship between virtual machine input / output virtual addresses allocated to a target virtual machine hosted on the host machine and virtual machine physical addresses allocated to the target virtual machine, and performing address translation based on the primary mapping relationship; and a second virtual input / output memory management unit component, which is mounted on the host machine, for maintaining a secondary mapping relationship between virtual machine physical addresses allocated to the target virtual machine and corresponding host machine physical addresses, and performing address translation based on the secondary mapping relationship.

[0008] According to a second aspect of one or more embodiments of this disclosure, a method for updating memory address mapping relationships in a virtualization scenario is proposed. The method is applied to a first virtual input / output memory management unit (VIP / MUM) component mounted on an input / output physical device connected to a host machine. The first VIP / MUM / MUM component maintains a primary mapping relationship between virtual machine input / output virtual addresses allocated to a target virtual machine hosted on the host machine and virtual machine physical addresses allocated to the target virtual machine. The target virtual machine is configured with a VIP / MUM / MUM driver for the first VIP / MUM / MUM component. The method includes: receiving an address update request initiated by the target virtual machine regarding the primary mapping relationship through the VIP / MUM / MUM driver; and updating the primary mapping relationship in response to the address update request.

[0009] According to a third aspect of one or more embodiments of this disclosure, a method for implementing memory address translation in a virtualization scenario is proposed. The method is applied to a first virtual input / output memory management unit (VIMMU) component mounted on an input / output physical device connected to a host machine. The first VIMMU maintains a primary mapping relationship between virtual machine input / output virtual addresses allocated to a target virtual machine hosted on the host machine and virtual machine physical addresses allocated to the target virtual machine. The host machine is also equipped with a second VIMMU component, which maintains a secondary mapping relationship between virtual machine physical addresses allocated to the target virtual machine and corresponding host machine physical addresses. The method includes: responding to a first address translation request from the virtual machine; obtaining the target virtual machine input / output virtual address contained in the first address translation request; and determining the target virtual machine physical address corresponding to the target virtual machine input / output virtual address based on the primary mapping relationship; and initiating a second address translation request containing the target virtual machine physical address to the second VIMMU component, so that the second VIMMU component determines the target host machine physical address corresponding to the target virtual machine physical address based on the secondary mapping relationship.

[0010] According to a fourth aspect of one or more embodiments of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in the first aspect by executing the executable instructions.

[0011] According to a fifth aspect of one or more embodiments of the present disclosure, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0012] According to a sixth aspect of one or more embodiments of the present disclosure, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0013] As can be seen from the above embodiments, this disclosure proposes a novel hardware-based IOMMU, and presents a system constructed with this IOMMU, a method for updating the memory address mapping relationship implemented by this IOMMU, and a method for memory address translation. Specifically, in addition to the second IOMMU component (i.e., the traditional hardware-based IOMMU) installed on the host machine itself, a first IOMMU component (also a hardware-based IOMMU) is installed on the I / O physical device connected to the host machine. The mapping relationship is updated and the memory address is translated through the mapping relationship maintained by the two IOMMU components and their mutual cooperation.

[0014] Specifically, the system includes a first IOMMU component and a second IOMMU component. The first IOMMU component performs address translation based on its maintained first-level mapping relationship between gIOVA and GPA, and the second IOMMU component performs address translation based on its maintained second-level mapping relationship between GPA and HPA. In the memory address mapping relationship update method, the first IOMMU component can directly receive an address update request initiated by the IOMMU driver in the virtual machine and update its maintained first-level mapping relationship in response to the request. In the memory address translation method, in response to a first address translation request from the virtual machine, the first IOMMU component determines the target GPA corresponding to the target gIOVA based on its maintained first-level mapping relationship (i.e., converts the target gIOVA to the target GPA), and then initiates a second address translation request containing the target GPA to the second IOMMU, so that the latter can determine the target HPA corresponding to the target GPA based on its maintained second-level mapping relationship (i.e., converts the target GPA to the target HPA).

[0015] Understandably, the above-disclosed solution directly abandons the software implementation approach of "simulating vIOMMU by virtual machine management software such as Hypervisor according to the hardware characteristics of the CPU platform." Instead, the hardware installed on the host machine and its connected I / O physical devices (i.e., the first IOMMU component installed on the I / O physical device and the second IOMMU component installed on the host machine) directly maintains the first-level mapping relationship between gIOVA and GPA and the second-level mapping relationship between GPA and HPA. The two then cooperate to update the mapping relationship and perform memory address translation. Thus, this solution abandons the "software-simulated virtual IOMMU (vIOMMU)" and implements a "hardware IOMMU," that is, a hardware-based dIOMMU. On the one hand, given that current CPU platforms typically have hardware computing units such as CPU, CIPU, and DPU, this solution does not need to consider the underlying hardware differences of CPU platforms from different manufacturers, generations, or even versions, nor does it need to be specifically adapted to different CPU platforms, significantly improving the compatibility and versatility of the IOMMU across CPU platforms. On the other hand, the process of updating the memory address mapping relationship and converting the memory address can be completed with the cooperation of hardware (i.e., the first and second IOMMU components), without the need for the virtual machine and its management software to perform high-overhead mode switching. Therefore, the efficiency of IOMMU mapping relationship update and memory address conversion is greatly improved, thereby significantly improving IOMMU performance. Attached Figure Description

[0016] Figure 1 is an architecture diagram of a system built based on software simulation vIOMMU in related technologies.

[0017] Figure 2 is an architecture diagram of a system for managing memory address mapping relationships in a virtualization scenario, provided by an exemplary embodiment.

[0018] Figure 3 is an architecture diagram of a system built based on a hardware-implemented dIOMMU, provided by an exemplary embodiment.

[0019] Figure 4 is a flowchart of a method for updating memory address mapping relationships in a virtualization scenario, provided by an exemplary embodiment.

[0020] Figure 5 is a flowchart of a method for implementing memory address translation in a virtualization scenario, provided by an exemplary embodiment.

[0021] Figure 6 is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0022] Figure 7 is a block diagram of an apparatus for updating memory address mappings in a virtualization scenario, provided by an exemplary embodiment.

[0023] Figure 8 is a block diagram of an apparatus for implementing memory address translation in a virtualization scenario, provided by an exemplary embodiment. Detailed Implementation

[0024] In current virtualization scenarios, virtual machines hosted on a host machine typically provide DMA functionality for peripheral devices such as network interface cards (NICs) and disk controllers. Before performing a DMA operation, gIOVA needs to be converted to HPA. This involves first converting the gIOVA accessed by the virtual machine's input / output devices (i.e., I / O virtual devices) to GPA, and then converting the GPA to the corresponding HPA. This allows the I / O virtual devices to directly access the HPA in the host machine's memory, thus enabling the DMA operation. This address translation is usually implemented using IOMMU technology.

[0025] In related technologies, in addition to the IOMMU integrated into the CPU platform, virtual machine management software such as Hypervisor often needs to create a vIOMMU in the virtualization environment through software simulation. The IOMMU and vIOMMU work together to complete the address translation between the virtual machine and the physical hardware. That is, the vIOMMU first converts gIOVA to GPA, and then the IOMMU converts GPA to HPA.

[0026] In this disclosure, gIOVA refers to a virtual address available to the virtual machine (i.e., that can be allocated to its I / O virtual devices by the virtual machine). This virtual address is used by the virtual machine's operating system and is used by functional components within the virtual machine to access the virtual machine's memory and hardware resources. GPA, as described in this disclosure, is the physical memory address actually accessed by the virtual machine's operating system. It should be noted that this address is the physical memory address seen from the perspective of the virtual machine's operating system; it is actually mapped from physical resources managed by the virtualization layer (such as the aforementioned Hypervisor software), and is not a physical memory address that actually exists. HPA, as described in this disclosure, is the physical address of the host machine's actual physical hardware, i.e., the host machine's physical memory address. In a virtualization environment, physical memory addresses are uniformly managed by the virtualization layer and mapped to various virtual machines hosted on the host machine as needed.

[0027] As shown in Figure 1, the host machine hosts a virtual machine and is equipped with a hardware-based IOMMU. The hypervisor, which manages the virtual machine, creates a vIOMMU within the virtual machine using software emulation. The hypervisor maintains a first-level page table within the virtual machine that records the first-level mapping between the gIOVAs available to the virtual machine (i.e., those that can be allocated to its I / O virtual devices) and the GPAs allocated to the virtual machine (i.e., gIOVA->GPA). The hardware-based IOMMU maintains a second-level page table that records the second-level mapping between the GPAs allocated to the virtual machine and the corresponding HPAs (i.e., GPA->HPA). Additionally, the virtual machine is configured with a vIOMMU driver, which allows the virtual machine to control the vIOMMU.

[0028] The memory address mapping relationship can be updated through the control chain shown in Figure 1, that is, updating the first-level mapping relationship and / or the second-level mapping relationship mentioned above. When updating the first-level page table, the update request containing the mapping change content generated by the vIOMMU driver is intercepted by the Hypervisor. If the update request is used to indicate updating the first-level mapping relationship, the Hypervisor will instruct the vIOMMU to update the first-level mapping relationship recorded in the first-level page table; if the update request is used to indicate updating the second-level mapping relationship, the Hypervisor will control the hardware-based IOMMU to update the second-level mapping relationship recorded in the second-level page table.

[0029] The data chain shown in Figure 1 allows for the conversion of memory addresses related to DMA operations, specifically converting gIOVA to GPA and then GPA to HPA. Specifically, the device driver in the virtual machine can initiate a first address translation request, containing the target gIOVA (i.e., the gIOVA to be translated), to the hardware-based IOMMU via the DMA controller in the host machine. In response, the IOMMU first accesses the first-level page table to query the target GPA corresponding to the target gIOVA, then accesses the second-level page table to query the target HPA corresponding to the target GPA, and finally generates and initiates a DMA instruction containing the target HPA to instruct the virtual machine's I / O devices to perform a DMA operation at that address.

[0030] The inventors discovered that the aforementioned related technologies typically suffer from poor compatibility and low performance. On one hand, virtual machines need to adaptively simulate the vIOMMU based on the host machine's hardware characteristics to ensure that the vIOMMU can work with the hardware-based IOMMU installed on the host machine. Therefore, the vIOMMU in the virtual machine is highly correlated with the host machine's hardware devices and their characteristics. This means that virtual machines hosted on hosts with different hardware characteristics require different types of vIOMMUs to be created for different hosts, resulting in incompatibility and a lack of generality between vIOMMUs. Especially in cloud computing scenarios, cloud vendors typically support multiple CPU platforms from different vendors, generations, and versions (the hardware characteristics of hardware-based IOMMUs often differ across CPU platforms). Therefore, it is necessary to provide corresponding vIOMMUs for virtual machines hosted on various CPU platforms, making adaptation to different CPU platforms difficult and time-consuming.

[0031] On the other hand, the vIOMMU in related technologies is entirely simulated by software (such as the aforementioned Hypervisor). Since modifying and updating page tables that record memory address mappings involves memory management between the virtual machine and the host machine, it is necessary to ensure the correctness and consistency of the mappings recorded in the page tables. Therefore, the Hypervisor needs to intercept and simulate write operations. This is especially true for operations on critical paths, such as the invalidation operation during vIOMMU unmap (i.e., canceling / deleting mappings), which requires Hypervisor interception and simulation. However, Hypervisor write interception requires the virtual machine to perform high-overhead VM-EXIT and VM-ENTRY mode switching, meaning that page table updates severely limit system performance. When a virtual machine performs an unmap operation on the vIOMMU, the virtual machine's operating system or device driver first needs to initiate an unmap request through the vIOMMU driver, specifying the range of gIOVAs to be unmapped. Then, since the vIOMMU is virtual, the unmap operation triggers VM-EXIT (i.e., the host CPU switches from non-root mode to root mode), and the virtual machine transfers control to the hypervisor. Next, the hypervisor intercepts the virtual machine's unmap request and simulates the unmapping operation, that is, deleting the mapping relationship from the specified gIOVA to GPA (at the same time, if the host machine has enabled a hardware-based IOMMU, the hypervisor also needs to update the second-level page table maintained by the IOMMU to ensure that the unmapped gIOVA no longer corresponds to any physical memory). After unmapping, the hypervisor needs to perform an invalidation operation to ensure that all old mapping relationships in the cache are cleared. Finally, after completing the unmap and invalidation operations, the hypervisor triggers VM-ENTRY (i.e., the host CPU switches from root mode to root mode). The process of switching from Mode to Non-Root Mode (which returns control to the virtual machine) is called the process of switching from Mode to Non-Root Mode.

[0032] In fact, the hardware-based IOMMU shown in Figure 1 supports maintaining two levels of page tables, implementing a semi-virtualized solution for the IOMMU device. However, in some related technical solutions, the hardware-based IOMMU only supports maintaining one page table (i.e., gIOVA->HPA). In this case, the hypervisor needs to simulate the gIOVA->GPA page table through software, which is the so-called full virtualization solution. In this type of solution, the virtualization of the IOMMU device is entirely provided by the hypervisor software. Therefore, not only does updating the mapping relationship require the hypervisor's participation, but the address translation process based on the mapping relationship also requires the hypervisor's participation. That is, every access to the register interface involves the high-overhead VM-EXIT and VM-ENTRY, making the performance bottleneck problem more prominent in this type of solution.

[0033] To address the aforementioned technical problems in related technologies, this disclosure proposes a novel hardware-based IOMMU, and provides a system comprised of this IOMMU, a method for updating the memory address mapping relationship implemented by this IOMMU, and a method for memory address translation. The solution will be described below with reference to the accompanying drawings and related embodiments.

[0034] First, this disclosure proposes a system for managing memory address mapping relationships in a virtualization scenario. The system includes: a first IOMMU component, which is mounted on an input / output I / O physical device connected to the host machine, for maintaining a primary mapping relationship between the virtual machine input / output virtual address gIOVA allocated to the target virtual machine hosted on the host machine and the virtual machine physical address GPA allocated to the target virtual machine, and performing address translation based on the primary mapping relationship; and a second IOMMU component, which is mounted on the host machine, for maintaining a secondary mapping relationship between the GPA allocated to the target virtual machine and the corresponding host physical address HPA, and performing address translation based on the secondary mapping relationship.

[0035] Figure 2 is an architecture diagram of a system built based on a hardware-implemented dIOMMU, provided by an exemplary embodiment. As shown in Figure 2, the system consists of a second IOMMU directly mounted on the host machine and a first IOMMU component mounted on an I / O physical device connected to the host machine. It should be noted that at least one I / O physical device may be connected to the host machine. Any I / O physical device can be physically connected to the host machine, such as being directly soldered onto the host machine's motherboard (in which case the device is an integrated I / O physical device), or being connected to the host machine through a peripheral interface on the host machine's motherboard (in which case the device is an external I / O physical device, or external device).

[0036] For example, the first IOMMU component can be integrated into a CIPU (Cloud Infrastructure Processing Unit) or DPU (Data Processing Unit) connected to the host machine. That is, the I / O physical device connected to the host machine and equipped with the first IOMMU component can be a CIPU or a DPU. This method can leverage the powerful data processing capabilities of the processor to achieve efficient updating and conversion of memory address mapping relationships. The second IOMMU component can be integrated into the CPU installed on the host machine. That is, the IOMMU installed on the CPU platform itself (such as the hardware-based IOMMU mentioned above) can be used as the second IOMMU component described in this embodiment of the disclosure, thereby ensuring that this solution can be applied to current mainstream CPU platforms (that is, the CPUs of these platforms usually integrate an IOMMU, which can be used as the second IOMMU component of this solution). Of course, in addition to being integrated on the host machine's CPU, the second IOMMU component can also be integrated on other hardware assembled on the host machine, such as on the motherboard chipset (southbridge or northbridge chipset), on high-performance GPUs (Graphics Processing Units) or network adapters (PCIe (peripheral component interconnect express) devices), or on SoCs (System on Chips), etc., which will not be elaborated further.

[0037] It should be noted that whether it's the first IOMMU component integrated into the host machine's CIPU or DPU, or the second IOMMU component integrated into hardware such as the CPU, it does not affect the normal operation of the processor itself. That is, the operating logic of the IOMMU component is isolated from the processing logic of the processor it resides in. Taking the second IOMMU component integrated into the CPU as an example, "integrated" means that from a hardware perspective, the second IOMMU component is located on the CPU chip / module, but it does not affect the normal operation of the CPU core within the CPU chip / module. Furthermore, in the case where the second IOMMU component is integrated onto the CPU, the CPU chip / module can also integrate hardware components such as memory controllers, storage controllers, caches, network interfaces, PCIe controllers, Trusted Execution Environments (TEEs), GPUs, and NPUs (Neural Processing Units), which will not be elaborated upon further.

[0038] The host machine described in this disclosure can host at least one virtual machine, and the target virtual machine can be any virtual machine hosted on the host machine. This solution can be used to manage the memory address mapping relationship corresponding to any virtual machine hosted on the host machine. Each virtual machine hosted on the host machine can be uniformly managed by virtual machine management software, such as for creating virtual machines, allocating virtualized hardware resources (e.g., virtual CPU, memory, storage, and network resources) to each virtual machine, and managing the lifecycle of virtual machines (e.g., starting, stopping, pausing, migrating, and deleting virtual machines). In addition, the software can also be used to abstract the host machine's hardware (abstracting physical hardware into virtual hardware usable by the virtual machine, so that the virtual machine does not need to care about the specific details of the host machine's underlying hardware) and simulate (simulating the host machine's virtual hard disk, virtual network card, and other hardware devices, so that the virtual machine can use these devices as if using physical hardware), and isolate resources (ensuring resource isolation between different virtual machines, preventing one virtual machine from accessing or interfering with the resources of other virtual machines). This disclosure does not limit the specific form of the virtual machine management software; the following description uses Hypervisor as an example.

[0039] Virtual functions (VFs) can be deployed in the target virtual machine. A VF is not a physical device connected to the host machine, but rather a lightweight, virtualized representation of the connected physical device through abstraction. In network adapters and other PCIe devices supporting SR-IOV (Single Root I / O Virtualization) technology, a single physical device can appear as multiple independent devices, allowing them to be directly used by different virtual machines. Each such virtualized representation is called a VF—in contrast to a PF (Physical Function), which represents a traditional, fully functional physical device representation. Multiple VFs can share the same host machine's hardware resources, but to upper-layer software, they appear as independent devices. In this way, each virtual machine can have its own VF, achieving performance close to direct access to a physical device while maintaining good isolation. Of course, although a VF is a virtualized representation of a physical device, it relies on the underlying physical hardware to implement its functionality. Among them, the Virtual Function Passthrough (VF) technology can be used to directly assign the VF of the SR-IOV device to the virtual machine (VM), thereby enabling the virtual machine to bypass the software emulation layer of the Hypervisor and directly access the physical device, which significantly improves the I / O performance of the virtual machine, reduces latency, and reduces CPU overhead.

[0040] As can be seen, the Virtual Functions (VFs) deployed in the target virtual machine are equivalent to devices assembled within the virtual machine itself, which can be used to implement corresponding functions. At least some of these VFs may support DMA functionality and have DMA operation requirements; such VFs can serve as I / O virtual devices as described in this embodiment. When any I / O virtual device has a DMA requirement, the corresponding target gIOVA can be sent to the host machine's DMA controller, which triggers the first and second IOMMU components to cooperate in address translation, i.e., completing the conversion process from target gIOVA -> target GPA -> target HPA. The finally determined target HPA can then be used by the host machine's memory controller in conjunction with the I / O virtual device to perform DMA operations.

[0041] The first IOMMU component described in this disclosure is used to maintain primary mapping relationships and perform address translation accordingly, while the second IOMMU component is used to maintain secondary mapping relationships and perform address translation accordingly. As mentioned above, unlike the vIOMMU created by software simulation in related technologies, the first IOMMU component described in this disclosure is mounted in hardware on the I / O physical device connected to the host, and the second IOMMU component is directly mounted in hardware on the host. It should be noted that the primary and secondary mapping relationships are actually sets of mapping relationships. For example, the primary mapping relationship set may contain n one-to-one correspondences between n gIOVAs and n corresponding GPAs, and similarly, the secondary mapping relationship set contains n one-to-one correspondences between n GPAs and n corresponding HPAs, which will not be elaborated further.

[0042] Figure 3 is an architecture diagram of a system built based on a hardware-implemented dIOMMU according to an exemplary embodiment. As shown in Figure 3, there are two IOMMUs on the host machine: a dIOMMU and a hardware-based IOMMU, which can serve as the first and second IOMMU components in this embodiment of the disclosure, respectively. The dIOMMU, as the first IOMMU component, maintains a first-level page table that records the first-level mapping relationship between the gIOVA allocated to the target virtual machine and the GPA allocated to the target virtual machine. The IOMMU, as the second IOMMU component, maintains a second-level page table that records the second-level mapping relationship between the GPA allocated to the target virtual machine and the corresponding host machine physical address HPA. Either the first-level or second-level page table can be stored in the local storage space of the corresponding IOMMU, or it can be stored outside the corresponding IOMMU in the local storage space of the host machine; this embodiment of the disclosure does not impose any limitations on this. For example, in Figure 3, the first-level page table is stored locally in the dIOMMU, and the second-level page table is stored in the external storage space of the host machine's local IOMMU. Furthermore, the data structures of the aforementioned first-level and second-level page tables can be defined internally by the host machine and are not visible to the VM and Hypervisor. The dIOMMU can be implemented as a PCIe device, thus being allocated to the target virtual machine via the aforementioned passthrough technology. In other words, the dIOMMU can be implemented as a Virtual Function (VF) deployed within the target virtual machine using passthrough technology.

[0043] In one embodiment, the target virtual machine may have memory address update requirements. In this case, the virtual machine can initiate an address update request for the first-level mapping relationship to the first IOMMU component. For example, the I / O virtual device deployed in the target virtual machine (hereinafter referred to as the target I / O virtual device) may generate memory address update requirements during normal operation, such as needing to access a new memory region or modifying the existing memory mapping. In this case, the device can initiate the aforementioned address update request. Alternatively, the operating system of the target virtual machine may also generate memory address update requirements, such as allocating a new memory region, releasing memory, or adjusting memory mapping. In this case, the operating system can initiate the aforementioned address update request. For example, the aforementioned memory address update requirements may include, but are not limited to, memory allocation (allocating physical memory to the target virtual machine and mapping it to the virtual machine's GPA) or reclamation (when the target virtual machine releases memory, the host machine reclaims this memory and reallocates it to other virtual machines or applications), memory sharing (if the host machine supports shared memory between multiple virtual machines, the mapping relationships corresponding to different target virtual machines can be merged to save storage space) or deduplication (the host machine detects and merges duplicate mapping relationships in multiple virtual machines to further improve memory utilization), hot-adding (dynamically increasing memory allocation while the target virtual machine is running to meet the virtual machine's memory requirements) or hot-removing (dynamically reducing memory allocation while the virtual machine is running to reclaim unused memory resources), memory optimization (such as reclaiming unused memory of the target virtual machine through techniques such as memory ballooning and reallocating it to other virtual machines), and memory migration (that is, migrating the memory state of a virtual machine from one physical host to another without downtime).

[0044] Accordingly, if an IOMMU driver for the first IOMMU component is configured in the target virtual machine, the first IOMMU component can receive the aforementioned address update request initiated by the target virtual machine through this driver. The IOMMU driver can forward the address update request initiated by the target I / O virtual device or operating system to the first IOMMU component. Furthermore, the first IOMMU component can update its maintained first-level mapping relationship in response to the received request.

[0045] Building upon the aforementioned implementation, the dIOMMU can be allocated to the target virtual machine via passthrough technology, as shown by the dashed arrow pointing from the dIOMMU to the dIOMMU in Figure 3. The target virtual machine is configured with a dIOMMU driver for the dIOMMU. Address update requests initiated by the target virtual machine can be forwarded to the dIOMMU via the device driver and the dIOMMU driver. Based on the aforementioned passthrough technology, the address update request can directly instruct the dIOMMU to update the first-level mapping relationship. Therefore, the dIOMMU can respond to the request by updating the first-level mapping relationship it maintains, that is, updating the first-level mapping relationship in its maintained first-level page table.

[0046] Specifically, if the address update request is used to indicate the addition of a mapping relationship between gIOVA and GPA, then the request may include the mapping relationship to be added (i.e., the gIOVA to be added and the corresponding GPA). In this case, the first IOMMU component only needs to add these mapping relationships to the first-level page table to complete the update. Alternatively, if the address update request is used to indicate the deletion of a mapping relationship between gIOVA and GPA, then the request may include the mapping relationship to be deleted (i.e., the gIOVA to be deleted and the corresponding GPA). In this case, the first IOMMU component only needs to delete these mapping relationships accordingly in the first-level page table to complete the update. Alternatively, if the address update request is used to indicate a modification to the mapping relationship between gIOVA and GPA, the request may include the old mapping relationship that needs to be modified (such as the old gIOVA and the corresponding old GPA that need to be deleted, or descriptive information such as the index and name of the old gIOVA and the old GPA) and the modified new mapping relationship (such as the modified new gIOVA and the corresponding new GPA, the relationship between the new gIOVA and the old gIOVA and / or the relationship between the new GPA and the old GPA, etc.). In this case, the first IOMMU component needs to modify the old gIOVA and the old GPA in the first-level page table to the new gIOVA and the new GPA accordingly, which will not be elaborated further.

[0047] Furthermore, the first IOMMU component can also maintain a TLB (Translation Lookaside Buffer), which is a high-speed cache in the CPU used to accelerate the translation (or address translation) process from virtual address to physical address. It stores recently used or frequently used page table entries, so that upon receiving a first address translation request containing the target gIOVA, it can first query the TLB for the target GPA and / or target HPA. If found, the translation is completed without further querying of the first-level page table; if not found, then the first-level page table is queried. This reduces the number of queries to the first-level page table and speeds up address translation through the cached hotspot mapping relationship. Of course, the same address update request can be used to indicate the addition of at least one mapping relationship, the deletion of at least one mapping relationship, and / or the modification of at least one mapping relationship. This disclosure does not limit the specific update method for the first-level mapping relationship.

[0048] Understandably, after updating the first-level mapping relationship, the first IOMMU component can refresh the cached first-level mapping relationship in the TLB to ensure consistency between the first-level mapping relationships stored in the TLB and the first-level page table, thereby ensuring the correctness of subsequent address translations. For example, if at least one updated first-level mapping relationship corresponding to the above address update request exists in the TLB (i.e., at least one updated first-level mapping relationship is cached in the TLB), then the TLB is refreshed. Of course, if no updated first-level mapping relationship exists in the TLB, then there is no need to refresh the TLB. Specifically, when updating the mapping relationship in the first-level page table, if only at least one new mapping relationship is added (which was not cached in the TLB before being added), then the TLB does not need to be refreshed; if a mapping relationship is deleted and / or modified and at least one of the mapping relationships is cached in the TLB, then the TLB needs to be refreshed after the first-level page table is updated. When refreshing the TLB, a global refresh (i.e., refreshing the entire TLB, suitable for scenarios where the page table undergoes large-scale changes) or a partial refresh (i.e., refreshing only some TLB entries related to a specific virtual address, suitable for scenarios where the page table undergoes small-scale changes) can be used. This disclosure does not limit the scope of the refresh.

[0049] Furthermore, if the TLB maintained by the first IOMMU is only used to record the first-level mapping relationship between gIOVA and GPA, then there should also exist another TLB to record the second-level mapping relationship between GPA and HPA (this TLB can be maintained by the virtual machine, IOMMU, or Hypervisor). In this case, the first IOMMU component can also trigger an update of the second-level mapping relationship between GPA and the corresponding HPA stored in the other TLB (each of which was refreshed previously). If the TLB maintained by the first IOMMU is used to directly record the third-level mapping relationship between gIOVA and HPA, then the first IOMMU component only needs to refresh this TLB.

[0050] During normal operation, any I / O virtual device deployed in the target virtual machine (i.e., the target I / O virtual device) may require a DMA operation. In this case, the first IOMMU component can perform address translation based on a first-level mapping relationship, converting the target gIOVA to the corresponding target GPA; while the second IOMMU component can perform address translation based on a second-level mapping relationship, converting the target GPA to the corresponding target HPA. As shown in Figure 3, the I / O virtual device can send the target gIOVA to be translated to the host machine's DMA controller through the target virtual machine's driver; correspondingly, the DMA controller can initiate a first address translation request containing the target gIOVA to the first IOMMU component, instructing the latter to perform first-level address translation.

[0051] In one embodiment, the aforementioned first-level page table and second-level page table can be nested page tables, in which case the complexity of nested page table lookup is O(n^2). 2 This means that the number of lookups increases significantly with the number of page table levels. Taking a 4-level page table as an example, each address translation from target gIOVA to target GPA to target HPA based on two page tables requires approximately 20 to 24 lookup operations.

[0052] In another embodiment, the first IOMMU component can first obtain the target gIOVA contained in the first address translation request, and determine the target GPA corresponding to the target gIOVA based on the first-level mapping relationship; then, it can initiate a second address translation request containing the target GPA to the second IOMMU component, instructing the latter to perform a second-level address translation. Correspondingly, the second IOMMU component can respond to the second address translation request, and determine the target HPA corresponding to the target GPA based on the second-level mapping relationship, thereby completing the address translation from target gIOVA to target GPA to target HPA through the cooperation of the two IOMMU components. At this time, the second IOMMU component can initiate a DMA instruction containing the target HPA, instructing the target virtual machine's I / O virtual device to perform a DMA operation on the host machine's memory according to the target HPA. Compared to the aforementioned address translation method corresponding to nested page tables, this embodiment implements serialized address lookup based on two-level page tables, thereby significantly reducing the number of lookup operations. Taking a 4-level page table as an example, the first IOMMU component queries the target GPA corresponding to the target gIOVA in the first-level page table, which requires a maximum of four queries; the second IOMMU component queries the target HPA corresponding to the target GPA in the second-level page table, which also requires a maximum of four queries. In this way, only 8 query operations are needed to achieve the address translation of a target gIOVA -> target GPA -> target HPA, which greatly reduces the number of queries and significantly reduces performance overhead.

[0053] As mentioned earlier, at least one I / O virtual device can be deployed in the target virtual machine. The first IOMMU component can maintain a first subpage table for each I / O virtual device. The first subpage table of any I / O virtual device records the first-level mapping relationship between the gIOVA allocated by the target virtual machine for that I / O virtual device and the GPA of the target virtual machine. It is understood that if any two I / O virtual devices do not share memory, the first-level mapping relationships recorded in their respective first subpage tables will be completely different; if any two I / O virtual devices share memory, their respective first subpage tables will record at least one identical first-level mapping relationship, which will not be elaborated further. However, regardless of the specific content, the union of the first-level mapping relationships recorded in each of the first subpage tables of all I / O virtual devices is the (after deduplication) total number of first-level mapping relationships recorded in the aforementioned first-level page table. Therefore, the first-level page table can also be considered as the union of all the first subpage tables. In this scenario, the aforementioned first address translation request can be initiated by any I / O virtual device. Therefore, when the first IOMMU component determines the target GPA corresponding to the target gIOVA based on the first-level mapping relationship, it can first determine the target I / O virtual device that initiated the first address translation request and its target first subpage table, and then query the target GPA corresponding to the target gIOVA in the target first subpage table. This approach minimizes conflicts between the memory addresses corresponding to each I / O virtual device, facilitating sufficient permission and security control over the DMA operations of each I / O virtual device.

[0054] The first IOMMU component can create corresponding IOAS (I / O Address Space) for each of the at least one I / O virtual devices, and store the first subpage table of each I / O virtual device in the corresponding IOAS. For each I / O virtual device deployed in the target virtual machine, the dIOMMU can create multiple independent IOAS, assign different identifiers (IOASIDs) to each IOAS, and store the first subpage table of each I / O virtual device in the corresponding IOAS. Based on this, when the target I / O virtual device sends gIOVA to the dIOMMU through the DMA controller (e.g., the DMA controller initiates a first address translation request to the dIOMMU), the dIOMMU can first associate the target I / O virtual device's identity (e.g., the first address translation request includes the I / O virtual device's functional identifier) ​​with the IOASID of the target I / O virtual device, then retrieve the first subpage table of the target I / O virtual device from the corresponding IOAS, and query the target GPA corresponding to the target gIOVA, thereby completing the address translation from target gIOVA to target GPA. This method ensures that the first subpage tables of different I / O virtual devices are stored in different address spaces, avoiding duplicate recording and querying and achieving isolation.

[0055] After obtaining the target GPA through the aforementioned method, the first IOMMU component can initiate a second address translation request containing the target GPA to the second IOMMU. The second IOMMU then queries the target HPA corresponding to the target GPA based on its maintained secondary mapping relationship, thereby completing the address translation from target GPA to target HPA. Thus, through the cooperation of the first and second IOMMU components, the complete address translation process from target gIOVA to target GPA to target HPA is successfully achieved, preparing the address for subsequent accurate DMA operations.

[0056] As mentioned earlier, at least one I / O virtual device can be deployed in the target virtual machine, and the first address translation request can be initiated by the target I / O virtual device. In one embodiment, in addition to the aforementioned target gIOVA, the first address translation request may also include access description information for the target GPA, such as the target operation type (read or write), the target operation data length (e.g., reading n bits, writing m bits, etc.), and the target operation content (e.g., data to be written). In practice, this access description information can be determined by the aforementioned target I / O virtual device according to its own needs and sent to the DMA controller along with the aforementioned target gIOVA. Based on this, the first IOMMU component can also send the access description information to the second IOMMU component; correspondingly, the second IOMMU component can initiate a DMA instruction containing the target HPA and the access description information to the host machine's memory controller, so that the memory controller assists the target I / O virtual device (to the host machine's memory) in performing DMA operations according to the target HPA and the access description information. The target GPA and the access description information can be included together in the second address translation request and sent to the second IOMMU component, or the access description information can be sent separately outside the second address translation request, which will not be elaborated further.

[0057] The DMA operation requested by the aforementioned target I / O virtual device has a corresponding target operation type. From the perspective of data change, the target operation type can be an add, delete, modify, and / or query operation; from the perspective of the underlying operation method, the target operation type can include a read and / or write operation. In this regard, the first IOMMU component or the second IOMMU component can also perform access control on the DMA operation based on the target operation type to ensure the system's security, isolation, and stability as much as possible.

[0058] For example, the first IOMMU component can also maintain the first operation permission information of each I / O virtual device deployed in the target virtual machine, wherein the first operation permission information of any I / O virtual device includes: the authorized operation type of the I / O virtual device for the authorized HPA with which it has operation permission, and the authorized gIOVA corresponding to the authorized HPA, wherein the authorized gIOVA in the first-level mapping relationship corresponds to the same authorized GPA as the authorized HPA in the second-level mapping relationship. For all HPAs corresponding to the target virtual machine, any I / O virtual device may have operation permissions for at least some of them. For any HPA corresponding to the target virtual machine, if any I / O virtual device has operation permissions for that HPA, then that HPA is called the authorized HPA of that I / O virtual device. Accordingly, the GPA corresponding to that authorized HPA recorded in the secondary mapping relationship is the authorized GPA corresponding to that authorized HPA (i.e., the aforementioned "authorized GPA corresponding to the authorized HPA in the secondary mapping relationship"), and the gIOVA corresponding to that authorized GPA recorded in the primary mapping relationship is the authorized gIOVA corresponding to that authorized HPA (i.e., the aforementioned "authorized gIOVA corresponding to the authorized GPA in the primary mapping relationship"). In addition, the authorized operation type of any I / O virtual device for the authorized HPA it has operation permissions for is the type of quota DMA operation that the device can perform on the authorized HPA.

[0059] Based on the aforementioned first operation permission, before initiating the second address translation request, the first IOMMU component can first verify whether the target operation type in the access description information belongs to the authorized operation type of the target I / O virtual device for the corresponding HPA. Specifically, the second IOMMU component can initiate the second address translation request if the first operation permission information indicates that the target gIOVA is an authorized gIOVA and the target operation type is an authorized operation type. For example, let's assume that a certain HPA is address0, its corresponding gIOVA is address1 (this address can be determined jointly by the first and second level mapping relationships), and its corresponding GPA is address2 (this address can be determined according to the second level mapping relationship). In this scenario, if a certain I / O virtual device (such as Device1) has modification and query permissions for address0, then the first operation permission information for Device1 maintained by the first IOMMU component can be "Device1, address0, modification and query" (this information indicates that Device1's authorized operation types for address0 are modification and query operations). Based on this, if the target operation type recorded in the first address translation request corresponding to Device1 is a modification operation or a query operation, the first IOMMU component can normally initiate the second address translation request; if the target operation type recorded in the first address translation request is an add operation or a delete operation, the first IOMMU component will not initiate the second address translation request to avoid Device1 performing add and / or delete operations on address0 that exceed its permissions.

[0060] For example, the second IOMMU component can also maintain second operation permission information for each I / O virtual device deployed in the target virtual machine. The second operation permission information for any I / O virtual device includes: the authorized operation type of the I / O virtual device for a given authorized HPA, and the authorized GPA corresponding to that authorized HPA. Based on this two-level mapping relationship, before initiating the DMA instruction, the second IOMMU component can first verify whether the target operation type in the access description information belongs to the authorized operation type of the target I / O virtual device for the corresponding HPA. Specifically, the second IOMMU can initiate the DMA instruction if the second operation permission information indicates that the target GPA is an authorized GPA and the target operation type is an authorized operation type. For example, taking HPA as address0, its corresponding gIOVA as address1, and its corresponding GPA as address2, in this scenario, if a certain I / O virtual device (such as Device2) has read permission for address0, then the second operation permission information for Device2 maintained by the second IOMMU component can be "Device2, address0, read" (this information indicates that Device2 has the right to perform a read operation on address0). Based on this, if the target operation type recorded in the first address translation request corresponding to Device2 is a read operation, then the second IOMMU component can normally initiate a DMA instruction; if the target operation type recorded in the first address translation request is a write operation, then the second IOMMU component will not initiate a DMA instruction to avoid Device2 performing a write operation on address0 that exceeds its permissions.

[0061] It should be noted that the authorized operation types of each I / O virtual device to the gIOVA maintained by the first IOMMU component can be maintained together with the aforementioned first-level mapping relationship, such as being recorded simultaneously in the aforementioned first-level page table; similarly, the authorized operation types of each I / O virtual device to the GPA maintained by the second IOMMU component can be maintained together with the aforementioned second-level mapping relationship, such as being recorded simultaneously in the aforementioned second-level page table. Of course, the aforementioned authorized operation types and corresponding mapping relationships can also be maintained separately, such as recording the authorized operation types separately in another permission table, which will not be elaborated further.

[0062] As can be seen from the foregoing embodiments, the above-disclosed solution directly abandons the software implementation approach of "simulating vIOMMU by virtual machine management software such as Hypervisor according to the hardware characteristics of the CPU platform." Instead, the hardware installed on the connected I / O physical devices (i.e., the first IOMMU component installed on the I / O physical device and the second IOMMU component installed on the host machine) directly maintains the first-level mapping relationship between gIOVA and GPA and the second-level mapping relationship between GPA and HPA. The two then cooperate to update the mapping relationship and perform memory address translation. Therefore, this solution abandons the "software-simulated virtual IOMMU (vIOMMU)" and implements a "hardware IOMMU," that is, a hardware-based dIOMMU. On the one hand, given that current CPU platforms typically have hardware computing units such as CPU, CIPU, and DPU, this solution does not need to consider the underlying hardware differences of different manufacturers, generations, or even versions of CPU platforms, nor does it need to be specifically adapted to different CPU platforms, significantly improving the compatibility and versatility of the IOMMU across CPU platforms. On the other hand, the process of updating the memory address mapping relationship and converting the memory address can be completed with the cooperation of hardware (i.e., the first and second IOMMU components), without the need for the virtual machine and its management software to perform high-overhead mode switching. Therefore, the efficiency of IOMMU mapping relationship update and memory address conversion is greatly improved, thereby significantly improving IOMMU performance.

[0063] Figure 4 illustrates an exemplary embodiment of a method for updating memory address mapping in a virtualization scenario. The method is applied to a first IOMMU component mounted on an I / O physical device connected to a host machine. This first IOMMU component maintains a primary mapping relationship between the gIOVA allocated to the target virtual machine hosted on the host machine and the GPA allocated to the target virtual machine. The target virtual machine is configured with an IOMMU driver for the first IOMMU. The host machine is also equipped with a second IOMMU component, which maintains a secondary mapping relationship between the GPA allocated to the target virtual machine and the corresponding HPA. The method includes steps 402-404.

[0064] Step 402: Receive the address update request initiated by the target virtual machine for the first-level mapping relationship through the IOMMU driver; Step 404: Update the first-level mapping relationship in response to the address update request.

[0065] In one embodiment, the first IOMMU component further maintains a translation backup buffer (TLB), and the method further includes: after the first-level mapping relationship is updated, refreshing the first-level mapping relationship cached in the TLB.

[0066] Figure 5 illustrates an exemplary embodiment of a method for implementing memory address translation in a virtualization scenario. The method is applied to a first IOMMU component mounted on an I / O physical device connected to a host machine. This first IOMMU component maintains a primary mapping relationship between the gIOVA allocated to the target virtual machine hosted on the host machine and the GPA allocated to the target virtual machine. The host machine is also equipped with a second IOMMU component, which maintains a secondary mapping relationship between the GPA allocated to the target virtual machine and the corresponding HPA. The method includes steps 502-504.

[0067] Step 502: In response to the first address translation request from the virtual machine, obtain the target gIOVA contained in the first address translation request, and determine the target GPA corresponding to the target gIOVA based on the first-level mapping relationship; Step 504: Initiate a second address translation request containing the target GPA to the second IOMMU component, so that the second IOMMU component can determine the target HPA corresponding to the target GPA based on the second-level mapping relationship.

[0068] Optionally, at least one I / O virtual device is deployed in the target virtual machine, and the first IOMMU component maintains a first subpage table for each I / O virtual device. The first subpage table of any I / O virtual device records a first-level mapping relationship between the gIOVA allocated by the target virtual machine for that I / O virtual device and the GPA of the target virtual machine. Determining the target GPA corresponding to the target gIOVA based on the first-level mapping relationship includes:

[0069] Determine the target I / O virtual device that initiated the first address translation request and its target first subpage table, and query the target GPA corresponding to the target gIOVA in the target first subpage table.

[0070] The specific implementation methods for updating memory address mapping relationships in a virtualization scenario and for implementing memory address translation in a virtualization scenario can be found in the previous system-related embodiments, and will not be repeated here.

[0071] Figure 6 is a schematic structural diagram of a device provided in an exemplary embodiment. Referring to Figure 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610, and may also include other hardware required for its functions. One or more embodiments of this disclosure can be implemented in software, for example, the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it. Of course, in addition to software implementation, one or more embodiments of this disclosure do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0072] Referring to Figure 7, the device for updating memory address mapping relationships in a virtualization scenario can be applied to the device shown in Figure 6 to implement the technical solution of this disclosure. Specifically, the device is applied to a first IOMMU component mounted on an I / O physical device connected to the host machine. This first IOMMU component maintains a primary mapping relationship between the gIOVA allocated to the target virtual machine hosted on the host machine and the GPA allocated to the target virtual machine. The target virtual machine is configured with an IOMMU driver for the first IOMMU component. The host machine is also equipped with a second IOMMU component, which maintains a secondary mapping relationship between the GPA allocated to the target virtual machine and the corresponding HPA. The device includes: an update request receiving unit 701, used to receive an address update request initiated by the target virtual machine for the primary mapping relationship through the virtual input / output memory management unit driver; and a mapping relationship updating unit 702, used to update the primary mapping relationship in response to the address update request.

[0073] Optionally, the host machine is further equipped with a second virtual input / output memory management unit component. The second virtual input / output memory management unit component maintains a two-level mapping relationship between the virtual machine physical address allocated to the target virtual machine and the corresponding host machine physical address. The second virtual input / output memory management unit component is used to perform address translation based on the two-level mapping relationship.

[0074] Optionally, the first virtual input / output memory management unit component also maintains a translation backup cache, and the device further includes a cache refresh unit 703, used to refresh the first-level mapping relationship cached in the translation backup cache after the first-level mapping relationship is updated.

[0075] Please refer to Figure 8. The device for implementing memory address translation in a virtualization scenario can be applied to the device shown in Figure 6 to achieve the technical solution of this disclosure. Specifically, the device is applied to a first IOMMU component mounted on an I / O physical device connected to the host machine. This first IOMMU component maintains a primary mapping relationship between the gIOVA allocated to the target virtual machine hosted on the host machine and the GPA allocated to the target virtual machine. The host machine is also equipped with a second IOMMU component, which maintains a secondary mapping relationship between the GPA allocated to the target virtual machine and the corresponding HPA. The device includes: a first address translation unit 801, used to respond to a first address translation request from the virtual machine, obtain the target virtual machine input / output virtual address contained in the first address translation request, and determine the target virtual machine physical address corresponding to the target virtual machine input / output virtual address based on the primary mapping relationship; and a second request initiation unit 802, used to initiate a second address translation request containing the target virtual machine physical address to the second virtual input / output memory management unit component, so that the second virtual input / output memory management unit component can determine the target host machine physical address corresponding to the target virtual machine physical address based on the secondary mapping relationship.

[0076] Optionally, the target virtual machine deploys at least one input / output virtual device, and the first virtual input / output memory management unit component maintains a first subpage table for each input / output virtual device. The first subpage table of any input / output virtual device records a first-level mapping relationship between the virtual machine input / output virtual address allocated by the target virtual machine for that input / output virtual device and the virtual machine physical address of the target virtual machine. The second request initiation unit 802 is specifically used to: determine the target input / output virtual device that initiates the first address translation request and the target first subpage table of the target input / output virtual device, and query the target virtual machine physical address corresponding to the target virtual machine input / output virtual address in the target first subpage table.

[0077] Based on the same concept as the methods described above, this disclosure also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor executes the executable instructions to implement the steps of the method as described in any of the above embodiments.

[0078] Based on the same concept as the methods described above, this disclosure also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0079] Based on the same concept as the methods described above, this disclosure also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

Claims

1. A system for managing memory address mapping relationships in a virtualization scenario, the system comprising: A first virtual input / output memory management unit component is mounted on an input / output physical device connected to the host machine. It is used to maintain a first-level mapping relationship between the virtual machine input / output virtual addresses allocated to the target virtual machine hosted on the host machine and the virtual machine physical addresses allocated to the target virtual machine, and to perform address translation based on the first-level mapping relationship. The second virtual input / output memory management unit component, which is mounted on the host machine, is used to maintain a two-level mapping relationship between the virtual machine physical address allocated to the target virtual machine and the corresponding host machine physical address, and to perform address translation based on the two-level mapping relationship.

2. The system according to claim 1, wherein, The first virtual input / output memory management unit component is further configured to: in response to a first address translation request from the target virtual machine, obtain the target virtual machine input / output virtual address contained in the first address translation request, and determine the target virtual machine physical address corresponding to the target virtual machine input / output virtual address based on the first-level mapping relationship; and initiate a second address translation request containing the target virtual machine physical address to the second virtual input / output memory management unit component.

3. The system according to claim 2, wherein, The second virtual input / output memory management unit component is further configured to: in response to the second address translation request, determine the target host physical address corresponding to the target virtual machine physical address based on the secondary mapping relationship.

4. The system according to claim 2, wherein, The target virtual machine has at least one input / output virtual device deployed in it. The first address translation request is initiated by the target input / output virtual device among the at least one input / output virtual devices. The first address translation request also includes access description information for the physical address of the target virtual machine. The first virtual input / output memory management unit component is further configured to: send the access description information to the second virtual input / output memory management unit component.

5. The system according to claim 4, wherein, The second virtual input / output memory management unit component is further configured to: send a direct memory access instruction containing the target host physical address and the access description information to the host's memory controller, so that the memory controller assists the target input / output virtual device in performing direct memory access operations according to the target host physical address and the access description information.

6. The system according to claim 5, wherein, The access description information includes the target operation type of the direct memory access operation requested by the target input / output virtual device. The first virtual input / output memory management unit component also maintains first operation permission information for each input / output virtual device deployed in the target virtual machine. The first operation permission information for each input / output virtual device includes: the authorized operation type of the input / output virtual device for an authorized host physical address to which it has operation permission, and the authorized virtual machine input / output virtual address corresponding to the authorized host physical address. The authorized virtual machine physical address corresponding to the authorized virtual machine input / output virtual address in the first-level mapping relationship and the authorized virtual machine physical address corresponding to the authorized host physical address in the second-level mapping relationship are the same virtual machine physical address. The first virtual input / output memory management unit component initiates the second address translation request, including: initiating the second address translation request when the first operation permission information indicates that the target virtual machine input / output virtual address belongs to an authorized virtual machine input / output virtual address and the target operation type belongs to an authorized operation type.

7. The system according to claim 5, wherein, The second virtual input / output memory management unit component also maintains second operation permission information for each input / output virtual device deployed in the target virtual machine. The second operation permission information for each input / output virtual device includes: the authorized operation type of the input / output virtual device for an authorized host physical address to which it has operation permission, and the authorized virtual machine physical address corresponding to the authorized host physical address. The second virtual input / output memory management unit component initiates the direct memory access instruction, including: initiating the direct memory access instruction when the second operation permission information indicates that the target virtual machine physical address belongs to an authorized virtual machine physical address and the target operation type belongs to an authorized operation type.

8. The system according to claim 1, wherein, The target virtual machine is configured with a virtual input / output memory management unit (VIPM) driver for the first VIPM memory management unit component, and the first VIPM memory management unit component is further configured to: The virtual input / output memory management unit driver receives the address update request initiated by the target virtual machine for the first-level mapping relationship, and updates the first-level mapping relationship in response to the address update request.

9. The system according to claim 8, wherein, The first virtual input / output memory management unit component also maintains a translation backup buffer, and the first virtual input / output memory management unit component is further used for: After the first-level mapping relationship is updated, the first-level mapping relationship cached in the translation backup cache is refreshed.

10. The system according to any one of claims 1-9, wherein, The input / output physical device connected to the host machine is a cloud infrastructure processor or a data processor.

11. The system according to any one of claims 1-9, wherein, The second virtual input / output memory management unit component is integrated into the central processing unit of the host machine.

12. A method for updating memory address mapping relationships in a virtualization scenario, applied to a first virtual input / output memory management unit (VIP / MMU) component mounted on an input / output physical device connected to a host machine, the first VIP / MMU component maintaining a primary mapping relationship between virtual machine input / output virtual addresses allocated to a target virtual machine hosted on the host machine and virtual machine physical addresses allocated to the target virtual machine, the target virtual machine being configured with a VIP / MMU driver for the first VIP / MMU component; the method includes: The virtual input / output memory management unit driver receives the address update request initiated by the target virtual machine for the first-level mapping relationship; The first-level mapping relationship is updated in response to the address update request.

13. The method according to claim 12, wherein, The host machine is also equipped with a second virtual input / output memory management unit component. The second virtual input / output memory management unit component maintains a two-level mapping relationship between the virtual machine physical address allocated to the target virtual machine and the corresponding host machine physical address. The second virtual input / output memory management unit component is used to perform address translation based on the two-level mapping relationship.

14. The method according to claim 12, wherein, The first virtual input / output memory management unit component also maintains a translation backup buffer, and the method further includes: After the first-level mapping relationship is updated, the first-level mapping relationship cached in the translation backup cache is refreshed.

15. A method for implementing memory address translation in a virtualization scenario, applied to a first virtual input / output memory management unit (VIP) component mounted on an input / output physical device connected to a host machine, the first VIP memory management unit maintaining a primary mapping relationship between virtual machine input / output virtual addresses allocated to a target virtual machine hosted on the host machine and virtual machine physical addresses allocated to the target virtual machine, the host machine further being equipped with a second VIP memory management unit, the second VIP memory management unit maintaining a secondary mapping relationship between virtual machine physical addresses allocated to the target virtual machine and corresponding host machine physical addresses; the method includes: In response to a first address translation request from the virtual machine, the target virtual machine input / output virtual address contained in the first address translation request is obtained, and the target virtual machine physical address corresponding to the target virtual machine input / output virtual address is determined based on the first-level mapping relationship; A second address translation request containing the physical address of the target virtual machine is initiated to the second virtual input / output memory management unit component, so that the second virtual input / output memory management unit component can determine the target host physical address corresponding to the physical address of the target virtual machine based on the second-level mapping relationship.

16. The method according to claim 15, wherein, The target virtual machine has at least one input / output virtual device deployed in it. The first virtual input / output memory management unit component maintains a first subpage table for each input / output virtual device. The first subpage table of any input / output virtual device records a first-level mapping relationship between the virtual machine input / output virtual address allocated by the target virtual machine for that input / output virtual device and the virtual machine physical address of the target virtual machine. Determining the target virtual machine physical address corresponding to the target virtual machine input / output virtual address based on the first-level mapping relationship includes: Determine the target input / output virtual device that initiated the first address translation request and the target first subpage table of the target input / output virtual device, and query the target virtual machine physical address corresponding to the target virtual machine input / output virtual address in the target first subpage table.

17. An electronic device comprising: processor; Memory for storing processor-executable instructions; wherein the processor performs the following operations by executing the executable instructions: The virtual input / output memory management unit (VIMMU) driver receives address update requests initiated by the target virtual machine (VM) regarding the first-level mapping relationship. The target VM is configured with a VIMMU driver for a first VIMMU component, which maintains a first-level mapping relationship between the VM I / O virtual addresses allocated to the target VM on the host machine and the VM physical addresses allocated to the target VM. The first VIMMU component is mounted on an input / output physical device connected to the host machine. The first-level mapping relationship is updated in response to the address update request.

18. An electronic device comprising: processor; Memory for storing processor-executable instructions; wherein the processor performs the following operations by executing the executable instructions: In response to a first address translation request from a virtual machine, the target virtual machine input / output virtual address contained in the first address translation request is obtained, and the target virtual machine physical address corresponding to the target virtual machine input / output virtual address is determined based on the first-level mapping relationship; A second address translation request containing the physical address of the target virtual machine is initiated to the second virtual input / output memory management unit component, so that the second virtual input / output memory management unit component can determine the target host physical address corresponding to the physical address of the target virtual machine based on the secondary mapping relationship; The second virtual input / output memory management unit component maintains a two-level mapping relationship between the virtual machine physical address allocated to the target virtual machine and the corresponding host machine physical address. The second virtual input / output memory management unit component is mounted on the host machine. The first virtual input / output memory management unit component maintains a one-level mapping relationship between the virtual machine input / output virtual address allocated to the target virtual machine hosted on the host machine and the virtual machine physical address allocated to the target virtual machine. The first virtual input / output memory management unit component is mounted on the input / output physical device connected to the host machine.

19. A computer-readable storage medium having stored thereon computer instructions, wherein, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 12-16.

20. A computer program product comprising a computer program / instructions, wherein, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 12-16.

Images