Domain identifier and device identifier translation by the input / output memory management unit

Abstract

An electronic device includes a processor that executes a guest operating system and a hypervisor, an input / output (IO) device, and an input / output memory management unit (IOMMU). The IOMMU processes communication between the IOMMU and the guest operating system by the following operations: in the communication received from the guest operating system, replacing a guest domain ID with a corresponding host domain identifier (domain ID) and / or replacing a guest device ID with a corresponding host device identifier (device ID) before further processing the communication; in the communication received from the IO device, replacing a host device ID with a guest device ID before providing the communication to the guest operating system; and placing a guest domain ID and / or a guest device ID in the communication generated in the IOMMU and destined for the guest operating system, and then providing the communication to the guest operating system. The IOMMU processes the communication without the intervention of the hypervisor.

Description

BACKGROUND OF THE INVENTION

[0001] RELATED ART

[0002] Some electronic devices (e.g., servers or desktop computers, etc.) support “virtualization” of electronic device hardware such as input / output (I / O) devices. Virtualization involves an intermediate entity above or within the electronic device, such that when the intermediate entity intercepts / redirects or otherwise assists accesses made by a software instance (e.g., an application program, etc.) executing on the electronic device, the software instance is given the illusion that it can directly access the electronic device hardware. For example, a common intermediate entity is a “virtual machine”. A virtual machine is a software entity that abstracts the electronic device hardware and emulates or presents a known interface of the electronic device hardware, such that a software instance can execute on underlying electronic device hardware of various types and arrangements—possibly including electronic device hardware that would otherwise be incompatible with the software instance. In some electronic devices, the virtual machine supports the execution of one or more operating system instances, called “guest” operating systems. The guest operating systems, in turn, provide an environment for the execution of other software instances (such as productivity applications, databases, etc.).

[0003] In some electronic devices, the virtual machine is managed and controlled by a software entity called a hypervisor. The hypervisor can start or initialize the virtual machine; control, monitor, and assist the virtual machine's access to the electronic device hardware; terminate or shut down the virtual machine, etc. FIG. 1 presents a block diagram showing a virtual machine and a hypervisor. As can be seen in FIG. 1, there are three virtual machines (VMs) 100, under each of which a guest operating system (guest OS) 102 and one or more programs (PRGRMS) 104, such as databases, software applications, etc., are executed. The virtual machines 100 communicate with a hypervisor 106, which is coupled between a host operating system (host OS) 108 and the virtual machines 100. The host operating system 108 provides an interface between the electronic device hardware 114 and the hypervisor 106. In addition, the hypervisor 106 is coupled between an input / output management unit (IOMMU) 112 and the virtual machines 100, and the IOMMU serves as a memory management unit and controller for the I / O device hardware 114.

[0004] The operations performed by the hypervisor include handling the communication between the electronic device hardware and the guest operating system (or more generally, the virtual machine). For example, the hypervisor can translate, redirect, or otherwise assist in the communication between the guest operating system and the input / output memory management unit (IOMMU). The communication handled by the hypervisor includes communications such as the writing of the peripheral page request (PPR) log and event log of the IOMMU, and the writing of the command buffer of the guest operating system. The PPR log, event log, and command buffer writing are described in detail in the AMD I / O Virtualization Technology (IOMMU) Specification, Revision 3.00 of December 2016, the entire content of which is incorporated herein by reference.

[0005] Figure 2 presents a block diagram showing the communication between the guest operating system and the IOMMU handled by the hypervisor. In Figure 2, many elements are shown in dotted form; these elements are logs, buffers, etc. stored in the memory (e.g., the main memory of the electronic device) and thus accessed by typical memory access techniques. The elements in Figure 2 together with the guest operating system 102, the hypervisor 106, and the IOMMU 112 include the guest peripheral page request (PPR) log 200, the guest command buffer (CMDBUF) 202, and the guest event log 204, which are structures (e.g., lists, tables, etc.) in the memory for storing the communication to and from the guest operating system 102. In addition, the elements include the guest pointers (PTRS) / status registers (REGS) 206, which are a set of locations in the memory for storing pointers to guest operating system structures and status information associated with the guest operating system. The elements also include the IOMMU peripheral page request log 208, the IOMMU command buffer 210, and the IOMMU event log 212, which are structures (e.g., lists, tables, etc.) in the memory for storing the communication to and from the IOMMU 112. The elements also include the IOMMU memory mapped input / output (MMIO) pointers / status registers (REGS) 214 in the IOMMU 112, which are a set of registers in the IOMMU 112 for storing pointers to various IOMMU 112 structures and status information associated with the IOMMU 112.

[0006] In operation, and using a command as an example, the guest operating system 102 writes a command to the IOMMU 112 into the guest command buffer 202 (i.e., into the next available location in the buffer of the memory where commands from the guest operating system 102 are stored). Since the guest operating system 102 uses in the command a "guest" domain ID and / or device ID that is different from the "host" domain identifier (domain ID) and / or device identifier (device ID) used by the IOMMU 112, the IOMMU 112 will not be able to identify the correct device and / or domain (the domain ID and device ID are described elsewhere herein, but generally identify a specific device or a protected domain from a set of devices in an electronic device, which is a mechanism for grouping devices to perform memory access). Using the command without translating or converting the guest domain ID and / or device ID may thus cause the command not to be processed correctly by the IOMMU 112, which may lead to errors in the electronic device. Therefore, the hypervisor 106 (shown as a dashed line in FIG. 2) intercepts the write by the guest operating system to the guest command buffer 202, looks up in the hypervisor data structure a mapping from the guest domain ID and / or guest domain ID to the host domain ID and / or device ID, replaces the guest domain ID and / or guest device ID in the command with the corresponding host domain ID and / or device ID, and stores the updated command in the IOMMU command buffer 210. Then, the IOMMU 112 retrieves the command from the IOMMU command buffer 210 and executes the command, which causes the IOMMU 112 to perform the corresponding action. The hypervisor 106 performs at least some similar operations: writes to the IOMMU peripheral page request log 208 and the IOMMU event log 212 by the IOMMU 112 (but replacing the host device ID with the guest device ID, etc.), accesses to the guest pointer / status register 206, and accesses to the IOMMU MMIO pointer / status register 214. Since the latency of the memory read / write, mapping lookup, and other operations performed by the hypervisor 106 is relatively long, using the intervention of the hypervisor 106 between the guest operating system 102 and the IOMMU 112 will cause a delay in processing the communication, make the processor busy, and increase the traffic on the memory bus of the electronic device. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 presents a block diagram showing a virtual machine and a hypervisor.

[0008] FIG. 2 presents a block diagram showing the communication between a guest operating system and an IOMMU processed by a hypervisor.

[0009] Figure 3 Presents a block diagram showing a virtual machine and a hypervisor according to some embodiments.

[0010] Figure 4The figure presents a block diagram of an electronic device according to some embodiments.

[0011] Figure 5 The figure presents a block diagram of a memory portion accessed by an IOMMU according to some embodiments.

[0012] Figure 6 The figure presents a block diagram of the communication between a guest operating system processed by an IOMMU and the IOMMU according to some embodiments.

[0013] Figure 7 The figure presents a flowchart of a process for processing communication from a guest operating system in an IOMMU according to some embodiments.

[0014] Figure 8 The figure presents a flowchart of a process for processing communication from an input / output (IO) device to a guest operating system in an IOMMU according to some embodiments.

[0015] Figure 9 The figure presents a flowchart of a process for generating communication to a guest operating system in an IOMMU according to some embodiments.

[0016] Figure 10 The figure presents a flowchart of a process for configuring an IOMMU to translate domain IDs and device IDs according to some embodiments.

[0017] Throughout the figures and the description, like reference numerals refer to like elements. Detailed Description

[0018] The following description is presented to enable any person skilled in the art to make and use the described embodiments, and the following description is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications. Thus, the described embodiments are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein.

[0019] Terminology

[0020] In the following description, various terms are used to describe the embodiments. The following is a simplified and general description of one of these terms. Note that the term may have important additional aspects that are not enumerated herein for the sake of clarity and brevity, and thus the description is not intended to limit the term.

[0021] Functional block: A functional block refers to a group, collection, and / or set of one or more interrelated circuit elements (such as integrated circuit elements, discrete circuit elements, etc.). Circuit elements are "interrelated" because the circuit elements share at least one property. For example, interrelated circuit elements may be included in a specific integrated circuit chip or a part thereof, fabricated on a specific integrated circuit chip or a part thereof, or otherwise coupled to a specific integrated circuit chip or a part thereof, may be involved in the execution of a given function (computing or processing function, memory function, etc.), may be controlled by a common control element and / or a common block, etc. A functional block may include any number of circuit elements, from a single circuit element (e.g., a single integrated circuit logic gate) to millions or billions of circuit elements (e.g., integrated circuit memory).

[0022] Virtualization, Virtual Machines, and Hypervisors

[0023] The described embodiments support the "virtualization" of electronic device hardware such as memories, input / output (IO) devices, etc. Virtualization generally involves an intermediate entity above or within the electronic device, so as to provide software instances executing on the electronic device with the illusion that the software instances can directly access the electronic device hardware when in fact the intermediate entity intercepts / redirects, translates, or otherwise assists the access performed by the software instances. For example, the intermediate entity may present a set of electronic device registers, memory locations, electronic device settings, and other functional blocks to the software instance, which appear to the software instance to be the actual device registers, memory locations, etc. of the electronic device, but are only copies presented by the intermediate entity. In this case, the intermediate entity receives, intercepts, or otherwise obtains access to the copies of the electronic device hardware and performs corresponding interactions with the actual electronic device hardware on behalf of the software instance. There are many benefits to the virtualization of electronic device hardware, such as enabling different electronic devices to use different arrangements of electronic device hardware, different addresses, locations, or identifiers of electronic device hardware, etc., while the software instances have the same interface to the electronic device hardware via the intermediate entity. In addition, the intermediate entity can determine whether to allow or block access to the electronic device hardware by a given software instance, and thus the virtualization of electronic device hardware realizes the protection of the electronic device hardware (or parts thereof) and / or the software instances executing on the electronic device. By controlling access as described above, the intermediate entity can share the electronic device hardware among multiple software instances and / or provide exclusive access to parts of the electronic device hardware to individual software instances.

[0024] In the described embodiments, the intermediate entity includes a "virtual machine". A virtual machine is a software entity that abstracts electronic device hardware and presents a known interface to the software instance to actual or emulated electronic device hardware. The abstracted hardware enables the software instance to execute on various types and arrangements of underlying electronic device hardware - which may include electronic device hardware that would otherwise be incompatible with the software instance. In the described embodiments, the virtual machine supports the execution of one or more operating system instances, referred to as "guest" operating systems. The guest operating system in turn provides an environment for the execution of other software programs (such as applications, databases, etc.).

[0025] In the described embodiments, the virtual machine is managed and controlled by a software entity called a hypervisor. The hypervisor can start or initialize the virtual machine; control, monitor, and assist the virtual machine's access to the electronic device hardware; terminate or shut down the virtual machine, etc. Figure 3 The figure presents a block diagram of a virtual machine and a hypervisor according to some embodiments. As Figure 3 can be seen, there are three virtual machines (VMs) 300, under each of which a guest operating system (guest OS) 302 and one or more programs (PRGRMS) 304, such as databases, software applications, etc., are executed. The virtual machines 300 communicate with a hypervisor 306, which is coupled between a host operating system (host OS) 308 and the virtual machines 300. The host operating system 308 provides an interface between the electronic device hardware 310 and the hypervisor 306. Different from that shown in FIG. 1 for existing electronic devices, in Figure 3 here, an IOMMU 312 is directly coupled between the guest operating system 302 and the IO device hardware 314 without the intervention of the hypervisor 306 (as indicated by the thicker line between the IOMMU 312 and the guest operating system 302). Thus, different from existing electronic devices, in the described embodiments, the hypervisor 306 is not responsible for performing at least some operations for handling the communication between the guest operating system 302 and the IOMMU 312, as described herein. However, note that certain communications occur between the IOMMU 312 and the hypervisor 306, as indicated by the line between the hypervisor 306 and the IOMMU 312. Additionally, note that in some cases, the host operating system 308 does not exist and the hypervisor 306 communicates more directly with the electronic device hardware 310.

[0026] Domain Identifiers and Device Identifiers

[0027] In the described embodiments, an electronic device uses a domain identifier (domain ID) and a device identifier (device ID) to identify input / output (I / O) devices for operations such as page table traversal, interrupt remapping, device access, event reporting, etc. For example, an input / output memory management unit (IOMMU) in an electronic device can use the domain ID and / or the device ID to determine the source or destination of communication between a processor (or software executing thereon) and an I / O device, determine a page table for address translation for the I / O device, report events triggered by or occurring at a particular I / O device to the processor, etc. The domain ID is a numerical value that identifies the protection domain to which an I / O device belongs. One or more I / O devices can belong to a given protection domain, and the I / O devices included in each protection domain may have the same set of address mappings (i.e., use the same page table) and access permissions for pages in memory. The device ID is a numerical identifier that includes or is generated based on information such as a bus identifier that identifies the interface bus on which the I / O device is located, a device number that identifies the I / O device among multiple devices in the electronic device, and a function number that identifies the function performed by the I / O device. The domain ID and the device ID are described in detail in the AMD I / O Virtualization Technology (IOMMU) Specification, Revision 3.00, December 2016, which is incorporated herein by reference as described above.

[0028] In some embodiments, one effect of the virtualization described above is that a guest operating system and electronic device hardware such as an IOMMU or an I / O device can use different values for the domain ID and / or the device ID. In these embodiments, the guest operating system can use "local" or "guest" values for the domain ID and / or the device ID that are selected, determined, or programmed into the guest operating system by the guest operating system, and the electronic device hardware can use "system" or "host" values for the domain ID and / or the device ID that are selected, determined, or programmed into the electronic device hardware by the electronic device hardware. Because the values of the domain ID and the device ID are different, communication between the guest operating system and the electronic device hardware involves one or more entities that process the communication (i.e., translate and / or otherwise assist the communication). Different from existing systems, in the described embodiments, the hypervisor does not translate and / or otherwise assist the communication. Instead, and as described herein, the IOMMU includes mechanisms for translating and / or otherwise assisting the communication without the intervention of the hypervisor. In some embodiments, although the hypervisor is not involved in translating and / or assisting the communication, the hypervisor can help set up or configure the IOMMU to handle the communication.

[0029] Overview

[0030] In the described embodiments, an electronic device includes a processor, a memory, and a plurality of input / output (I / O) devices (e.g., network interface devices, disk controllers, etc.). The electronic device also includes an input / output memory management unit (IOMMU) coupled between the processor and the I / O devices. The processor in the electronic device executes a hypervisor, one or more virtual machines, and a guest operating system within the virtual machines. The IOMMU performs operations to handle communications between the guest operating system and the IOMMU and the I / O devices. More specifically, the IOMMU translates the guest domain ID and the guest device ID in the communications from the guest operating system into a host domain ID and a host device ID, and then processes the communications in the IOMMU and / or the I / O devices. In addition, the IOMMU translates the host domain ID and / or the host device ID in the communications from the I / O devices into a guest domain ID and / or a guest device ID, and generates a communication including the guest domain ID and / or the guest device ID, and then sends the communication to the guest operating system for processing.

[0031] The above communications processed by the IOMMU include various forms / types of communications between the guest operating system and the IOMMU and the I / O devices. Generally, the IOMMU in the described embodiments can perform translation or conversion of domain IDs and / or device IDs in any communication between the guest operating system and the IOMMU and the I / O devices. As an example of the communication from the guest operating system to the IOMMU, in some embodiments, the guest operating system writes a command into a command buffer provided by the IOMMU. When processing the command from the command buffer, the IOMMU obtains the guest domain ID and / or the device ID from the command, and uses an ID translation table to look up the corresponding host domain ID and / or the host device ID. Then, the IOMMU replaces the guest domain ID and / or the device ID with the host domain ID and / or the host device ID before further processing the command. As an example of the communication from the IOMMU to the guest operating system, in some embodiments, the IOMMU writes a peripheral page request (PPR) into the page request interrupt log of the guest operating system. Before writing the PPR into the log, the IOMMU obtains the host device ID (or determines the host device ID based on the source I / O device) from the PPR and uses the device table entry of the source I / O device to look up the associated guest device ID. Then, the IOMMU replaces the host device ID with the guest device ID, and then stores the PPR in the peripheral page request log of the guest operating system. As another example of the communication from the IOMMU to the guest operating system, in some embodiments, when generating a communication to the guest operating system (e.g., regarding an event, etc.), the IOMMU uses an ID translation table and / or a device table to determine the guest domain ID and / or the guest device ID to be included in the communication, and thus does not include the host domain ID and / or the host device ID in the communication generated by the IOMMU.

[0032] In some embodiments, the above ID translation table and / or device table are populated / configured / updated by a hypervisor or another software or hardware entity (e.g., an operating system, etc.) to include information to be used by the IOMMU for processing communications. For example, in some embodiments, the hypervisor conveys to the IOMMU the mapping between guest domain IDs and / or device IDs and host domain IDs and / or device IDs, and the IOMMU writes the mapping into the ID translation table. In these embodiments, the IOMMU includes or provides one or more memory-mapped input / output (MMIO) registers (or corresponding memory locations in memory), and each mapping is written therein sequentially until the IOMMU has received and stored all mappings from the hypervisor.

[0033] In some embodiments, the IOMMU does not internally store at least a portion of the ID translation table and / or device mapping table. In these embodiments, the IOMMU stores some or all of the ID translation table and / or device table in memory (e.g., main memory) or another backing store. In these embodiments, the IOMMU includes one or more private memory translation tables or lists in which the location of the ID translation table (e.g., base address, length, etc.) and / or device table in memory or backing store is stored.

[0034] By processing communications between the guest operating system and the IOMMU as described above, the IOMMU performs operations that were previously performed by a hypervisor in existing devices. Removing the operations from a software-implemented hypervisor to a hardware-implemented IOMMU enables the operations to be performed with less latency and reduced processor operations, which helps to improve the performance of the IOMMU and the processor. In turn, this can help to improve the performance of the electronic device, thereby enhancing user satisfaction.

[0035] Electronic Device

[0036] Figure 4 The figure shows a block diagram of an electronic device 400 according to some embodiments. As Figure 4 can be seen, the electronic device 400 includes a processor 402, a memory 404, a mass storage device 406, input / output (I / O) devices 408 - 412, an input / output (I / O) hub 414, and a memory controller 416.

[0037] Processor 402 is a functional block that performs computational operations in electronic device 400. Processor 402 includes two cores 418 - 420, each core including one or more computing mechanisms, such as a central processing unit (CPU) core, a graphics processing unit (GPU) core, an embedded processor, an application specific integrated circuit (ASIC), and / or other computing mechanisms. Processor 402 also includes a memory management unit (MMU) 422, which is a functional block that performs operations associated with address translation (e.g., page table traversal, translation lookaside buffer lookup, etc.), memory access protection, etc., for memory access by cores 418 - 420.

[0038] Memory 404 is a functional block that performs the operations of memory (e.g., “main” memory) in electronic device 400. Memory 404 includes: memory circuitry, such as dynamic random access memory (DRAM), double data rate synchronous DRAM (DDR SDRAM), and / or one or more of other types of memory circuitry for storing data and instructions used by other functional blocks in electronic device 400; and control circuitry for handling access to data and instructions stored in the memory circuitry (e.g., reading, writing, checking, deleting, invalidating, etc.).

[0039] Mass storage device 406 is a functional block and / or device that performs the operations of high - capacity non - volatile storage elements to store data and instructions for use by other functional blocks in electronic device 400. Mass storage device 406 may be or include high - capacity semiconductor memory (e.g., flash memory, etc.), disk drives (hard disk drives, etc.), optical drives, etc. Copies of data and instructions stored in mass storage device 406 are retrieved and stored in memory 404 for use by other functional blocks in electronic device 400. For example, in some embodiments, data and / or instructions are retrieved from mass storage device 406 in blocks or “pages” of a given size (e.g., 4 kB, 2 MB, etc.) and the pages are stored in memory 404 for access by other functional blocks. Additionally, pages may be newly created at available locations in memory 404 (e.g., for storing computation results, etc.).

[0040] The IO devices 408 - 412 are functional blocks and / or devices that perform corresponding IO operations. The specific nature of the IO operations performed by each of the IO devices 408 - 412 depends on the nature of the IO device. For example, the IO devices 408 - 412 can include human - machine interface devices, network interface devices, audio / visual processing or providing devices, GPUs, sensor devices, disk controllers, Peripheral Component Interconnect (PCI) devices, Universal Serial Bus (USB) devices, etc., and each IO device performs associated operations such as receiving input from a person (e.g., keyboard, mouse, etc.), receiving or sending data over a network, etc. The IO devices 408 - 412 provide data and / or instructions to other functional blocks in the electronic device 400 or consume data and / or instructions from them. For example, in some embodiments, the IO devices 408 - 412 access (i.e., read, write, invalidate, etc.) data in memory pages in the memory 404 that are private to the guest operating system.

[0041] The IO hub 414 is a functional block that performs the operations of an input - output hub that couples between the IO devices 408 - 412 and other functional blocks in the electronic device 400 (e.g., the processor 402, the memory 404, etc.). The operations performed by the IO hub 414 include the following operations: ensuring that communications destined for the IO devices 408 - 412 reach the intended IO device, communications from the IO devices 408 - 412 reach the other functional blocks correctly, preventing unauthorized access by the IO devices 408 - 412 to the other functional blocks, and vice versa, etc. In some embodiments, the IO hub 414 couples between buses that use different communication standards (such as between a Peripheral Component Interconnect Express (PCIe) bus and HyperTransport and so on), and thus converts or translates the associated communications.

[0042] The I / O hub 414 includes an IOMMU 424, which is a functional block that performs operations for enabling the I / O devices 408-412 to access data and / or instructions in the memory 404, communicate with the processor 402, and so on. In these embodiments, when an I / O device in the memory 404 (e.g., the I / O device 408) wants to access data and instructions, the I / O device sends a memory access request (e.g., a direct memory access request or DMA) to the IOMMU 424. Then, the IOMMU 424 sends a corresponding request to the memory 404 to satisfy the memory access request. For example, in some embodiments, if data is to be retrieved based on the memory access request, the IOMMU 424 fetches the data from the memory 404 (or the mass storage device 406 if the data does not exist in the memory 404) and forwards the data to the requesting I / O device. In some embodiments, the IOMMU 424 includes page tables, translation lookaside buffers, and / or other functional blocks for translating the "virtual" or native memory addresses used by the I / O devices 408-412 into the physical addresses in the memory 404 where the data actually resides.

[0043] In the described embodiments, the IOMMU 424 communicates with the guest operating system executed by cores 418 - 420 in a virtual machine, and vice versa. For example, in some embodiments, the IOMMU 424 (or the IO devices 408 - 412 via the IOMMU 424) transmits events and peripheral page requests (PPRs) to the guest operating system. In these embodiments, the IOMMU 424 reports events such as illegal device table entries, IO page faults (representing page table walks for the IO devices 408 - 412), IOMMU 424 hardware errors, etc. to the guest operating system via a shared guest event log in the memory 404. Additionally, in these embodiments, the IOMMU 424 forwards PPRs from peripheral devices (IO devices) to the guest operating system, and the PPRs are configured to perform memory page service operations (i.e., perform operations on or associated with pages in the memory 404 accessible by the guest operating system) using well-known address translation services or ATS standards via a shared guest PPR log in the memory 404. As another example, in some embodiments, the guest operating system transmits commands to the IOMMU 424. In these embodiments, the guest operating system issues commands to the IOMMU 424 via a shared guest command buffer in the memory 404 to control the IOMMU 424 and / or the IO devices 408 - 412, such as complete wait (which serves as a command barrier to force an earlier command to complete before the IOMMU 424 proceeds), device table entry invalidation, IOMMU 424 translation lookaside buffer entry invalidation, etc. As described herein, the IOMMU 424 translates the guest domain ID and / or device ID in the communication to the host domain ID and / or device ID, and vice versa.

[0044] In some embodiments, the IOMMU 424 provides an interface to the guest operating system, and the interface includes memory-mapped locations, registers, etc. for communicating with the IOMMU 424. For example, in some embodiments, the IOMMU 424 provides a set of memory-mapped input / output (MMIO) memory locations to which the guest operating system can write values so that the IOMMU 424 will receive the values. In some embodiments, the interface is virtualized because, as assumed by the guest operating system, the memory locations, registers, etc. are not used to store values but are simply presented as being used by the IOMMU 424. In these embodiments, the IOMMU 424 can receive values from the guest operating system via the interface, but uses a backing store 426 and / or other locations in the memory 404 to store separate copies of the values in the memory locations, registers, etc. of each guest operating system. The memory accessed by the IOMMU 424 to communicate with the guest operating system and other entities (such as the processor 402, etc.) is described in more detail below.

[0045] The guest memory 428 is a part of the memory 404 (e.g., one or more pages of the memory), and this part is used by the corresponding guest operating system (e.g., the guest operating system 302) to store data and information to be used by the guest operating system. Generally, the guest operating system can use the guest memory 428 to store any form of data and information used by the guest operating system and / or other entities. In some embodiments, the guest memory 428 is protected so that only certain entities are allowed to access the guest memory 428. In some embodiments, the guest memory 428 is used to store structures such as guest event logs, guest peripheral page request (PPR) logs, and guest command buffers, which are data structures (e.g., tables, lists, etc.) for communication between the guest operating system and the IOMMU. The guest event log, guest peripheral page request (PPR) log, and guest command buffer are described in more detail below.

[0046] In some embodiments, communication paths are coupled between various functional blocks (processor 402, memory controller 416, memory 404, etc.) in the electronic device 400, as shown by the arrow lines between the elements. The communication paths include one or more buses, wires, leads, and / or other connections that may be together with controllers, structural elements (switches, routers, etc.), circuit elements, etc. The communication paths are used to route commands, data, control signals, and / or other information between the functional blocks. For example, in some embodiments, a coherent bus structure or interconnect is coupled between the IO hub 414, the processor 402 (e.g., the MMU 422), and the memory 404. Note that for clarity, some communication paths in the electronic device 400 are not shown in Figure 4 the figure.

[0047] In some embodiments, Figure 3 the electronic device hardware 310 in Figure 3 includes functional blocks and devices such as the processor 402 and the memory 404, and the IO device hardware 314 includes functional blocks and devices such as the IO devices 408 - 412. In these embodiments, Figure 4 the IOMMU 312 in

[0048] The electronic device 400 is shown as using a specific number and arrangement of components (e.g., functional blocks and devices such as processor 402, memory 404, etc.) and communication paths. However, for illustrative purposes, the electronic device 400 is simplified, and in some embodiments, there are different numbers or arrangements of components and / or communication paths in the electronic device 400. For example, the electronic device 400 may include a power supply subsystem, a display, etc. Generally, the electronic device 400 includes sufficient components and communication paths to perform the operations described herein.

[0049] The electronic device 400 can be or can be included in any electronic device that performs computing operations. For example, the electronic device 400 can be or can be included in an electronic device such as a desktop computer, a laptop computer, a wearable electronic device, a tablet computer, a smart phone, a server, an artificial intelligence device, a virtual or augmented reality device, a network appliance, a toy, an audio-visual device, a household appliance, a controller, a vehicle, etc. and / or a combination thereof.

[0050] Memory Portion Accessed by IOMMU

[0051] In some embodiments, the IOMMU accesses data and information in different portions of a memory (e.g., memory 404) to perform the operations described herein. In some of these embodiments, the portions of the memory include an IOMMU backing store (e.g., IOMMU backing store 426), guest memory (e.g., guest memory 428), and / or hypervisor memory. Figure 5 The figure presents a block diagram showing the portions of the memory accessed by the IOMMU according to some embodiments. Although Figure 5 presented as an example, in some embodiments, the memory and / or different portions of the memory store different types and / or arrangements of information. Generally, the memory includes sufficient information to implement the operations described herein.

[0052] As Figure 5As can be seen, the IOMMU backing store 500 includes an ID translation table 502. Generally, the ID translation table 502 includes information that the IOMMU uses to translate or convert a guest domain ID and / or device ID in communications from the guest operating system to the IOMMU (or vice versa, from the IOMMU to the guest operating system) into a host domain ID and / or device ID. In some embodiments, the ID translation table 502 includes a table for domain IDs (shown as the domain ID mapping table 504) and a table for device IDs (shown as the device ID mapping table 506) separately, but separate tables are not required (and thus all translations can be included in a single table). The domain ID mapping table 504 includes a set of entries, each entry for storing an identification or indication of a guest domain ID associated with or related to a specified host domain ID. The device ID mapping table 506 includes a set of entries, each entry for storing an identification or indication of a guest device ID associated with or related to a specified host device ID. In operation, when a guest or host domain ID and / or device ID is to be translated or converted in a communication, the IOMMU performs a lookup in the ID translation table 502 (i.e., the domain ID mapping table 504 and / or the device ID mapping table 506) to obtain the corresponding translation or conversion.

[0053] The IOMMU backing store 500 also includes guest control 508. Generally, the guest control 508 includes a copy of the values stored in or from the interface registers and control registers of the guest operating system in the electronic device. For each supported guest operating system, the guest control 508 includes a copy of the guest interface registers and / or guest operating system control registers (or at least the values therein) that control the interaction between the IOMMU and that guest operating system. By way of example, for each guest operating system, the guest control 508 may include a mapping control register for transmitting the domain ID and / or device ID mapping of the guest operating system to the IOMMU. As another example, for each guest operating system, the guest control 508 may include command control registers, event control registers, and PPR control registers that indicate how that guest interacts with the command buffer, event log, and PPR log, and / or how to otherwise configure that guest.

[0054] The IOMMU backing store 500 also includes a guest memory mapped input / output (MMIO) 510. Generally, the guest MMIO 510 includes pointers and control information for accessing buffers and logs (such as guest command buffers, guest event logs, and guest PPR logs) of the guest operating system in the guest portion of the memory 404 (e.g., guest memory 428). More specifically, for each supported guest operating system, the guest MMIO 510 includes a separate copy of the values used to perform / control access to the buffers and logs in the guest portion of the memory 404. For example, in some embodiments, the IOMMU supports (can interact with, process its communications, etc.) 2 N guest operating systems, where N = 10, 16, or other values, and thus the guest MMIO 510 includes up to 2 N copies, one for each supported guest operating system. In the described embodiments, the values used to control access are similar to the values stored in the IOMMU MMIO registers in existing devices, but a separate set of values is reserved for each supported guest operating system, referring to the guest portion of the memory 404 for that guest operating system (rather than a single copy in the IOMMU of an existing device). For example, in some embodiments, for each supported guest operating system, the guest MMIO 510 includes command, event, and PPR head and / or tail pointers (the pointers indicating the locations of the guest command buffer, guest event log, and guest PPR log in the corresponding guest portion of the memory) and control registers (the bits in which control or identify the functions and configurations of that guest operating system for commands, events, and PPRs).

[0055] The guest memory 512 includes a guest event log 514, a guest peripheral page request (PPR) log 516, and a guest command buffer 518 for the guest operating system. Generally, the guest event log 514, the guest peripheral page request log 516, and the guest command buffer 518 are memory structures (such as lists, tables, buffers, etc.) for storing the corresponding events, PPR requests, and commands for access by the IOMMU and / or the guest operating system. In operation, the IOMMU transmits events and PPRs to the guest operating system via the corresponding logs in the guest event log 514 and the guest PPR log 516 in the guest memory 512. In addition, the guest operating system transmits commands to the IOMMU via the corresponding command buffer in the guest command buffer 518 in the guest memory 512. In some embodiments, each guest operating system active in the electronic device 400 is associated with a corresponding separate guest memory (i.e., multiple pages in the memory 404), the separate guest memory including the guest event log, the peripheral page request log, and the guest command buffer used by that guest operating system and accessible by the IOMMU. This is inFigure 5 Additional guest memories 520-522 are shown behind guest memory 512.

[0056] The hypervisor memory 524 includes a device table 526. Generally, the device table 526 is a table that stores device-related information of devices (which may be actual / physical devices or virtual devices) associated with and / or coupled to an electronic device. The device table 526 includes a set of entries, each entry being usable to store information about a corresponding device, such as pointers to a page table and an interrupt table, control and configuration values, function indicators, mode indicators, domain IDs, security information and settings, etc. Additionally, in the described embodiments—and different from existing device tables—each entry in the device table 526 includes a device ID and a guest identifier of a guest operating system that communicates with, is responsible for, or is otherwise associated with the device. In operation, in addition to using the device table to determine information about a device, the IOMMU also uses the device ID and / or the guest identifier to translate or convert a guest device ID to a host device ID.

[0057] In some embodiments, some or all and / or portions of the IOMMU backing store 500, guest memory 512, and hypervisor memory 524 are not contiguous, but are stored in different regions or locations of the memory. For example, the base address of the guest event log 514 (and thus the guest event log itself) may be located in the memory far from the guest PPR log 516. Thus, the guest event log 514 may not be adjacent to the guest PPR log 516 as Figure 5 shown.

[0058] In some embodiments, the IOMMU includes a private address map that includes pointers, references, and / or other indications of the locations in the memory of various data and information accessed by the IOMMU in the memory. For example, the IOMMU private address map may include pointers to the base addresses in the memory for the guest event log 514, guest PPR log 516, etc. In these embodiments, before accessing data and information in the memory, the IOMMU looks up the locations of the data and information in the private address map.

[0059] In some embodiments, the IOMMU backing store 500 and / or portions thereof (control bits, etc.) are accessed by other entities in the electronic device 400 via the IOMMU (e.g., by sending a request to the IOMMU) or are not accessible by other entities. For example, at least some of the data and information in the IOMMU backing store 500 can be accessed by other entities via writes to and reads from corresponding (and protected by the IOMMU) memory-mapped input / output registers in or associated with the IOMMU.

[0060] IOMMU Communicating with Guest Operating System

[0061] In the described embodiments, the IOMMU (e.g., IOMMU 424) translates or transforms the domain ID and device ID in the communication between the IOMMU (or the IO device served thereby) and the guest operating system. Figure 6 The figure presents a block diagram showing the communication between the guest operating system 600 and the IOMMU 602 processed by the IOMMU 602 according to some embodiments. Although Figure 6 a number of elements are shown in a particular arrangement, other embodiments use a different number or arrangement of elements. Generally, in the described embodiments, the IOMMU 602 includes or accesses sufficient elements to implement the operations described herein. In Figure 6 it, many elements are shown as dotted; these elements are logs, buffers, etc. stored in memory (e.g., in the IOMMU backing store 500, in the guest memory 512, etc.) and accessed by the IOMMU 602, the guest operating system 600, and / or other entities using typical memory access techniques. In some embodiments, the guest operating system 600, the IOMMU 602, and the hypervisor 604 are organized in a similar manner to Figure 3 the guest operating system 302, the IOMMU 312, and the hypervisor 306 in, but this is not required.

[0062] As Figure 6As can be seen, and different from that shown in FIG. 2 for the existing system, in the described embodiment, the IOMMU 602 and the guest operating system 600 communicate with each other more directly. In other words, the IOMMU 602 and the guest operating system 600 communicate with each other via the guest event log 514, the guest PPR log 516, and the guest command buffer (BUFF) 518 in the memory (i.e., the guest part of the memory of the guest operating system 600 (e.g., the guest memory 428)). In addition, the guest operating system 600 and the IOMMU 602 use the guest control 508 and the guest MMIO 510 to specify how to perform the communication. For example, in some embodiments, the IOMMU 602 uses the pointer in the guest MMIO 510 to determine the locations of the guest event log 514, the guest command buffer 518, and the guest PPR log 516 of the guest operating system 600 in the memory. The hypervisor 604 does not intervene and does not otherwise participate in some or all of the operations for completing these communications. For example, the hypervisor 604 does not perform operations such as translating the domain ID and the device ID for these communications, accessing the pointer in the guest MMIO 510, and / or accessing the buffers and logs in the guest part of the memory. Instead, the IOMMU 602 performs these operations. Since the IOMMU 602 translates the domain ID and the device ID and obtains information from the guest MMIO 510, etc., the described embodiment avoids using the hypervisor 604 to handle at least part of the communication between the guest operating system 600 and the IOMMU 602, which may mean that the communication is completed faster, resulting in less load on the processor 402, the memory 404, etc.

[0063] In operation, taking a command as an example, the guest operating system 600 writes an invalidate_IOMMU_pages command to the guest command buffer 518. The command causes the IOMMU 602 to invalidate a series of entries in the IOMMU translation cache, as specified by the domain ID in the command. In other words, the guest operating system performs a memory write in the corresponding guest portion of the memory to update the next open / available entry in the guest command buffer 518 to include data for the invalidate_IOMMU_pages command (i.e., the bits representing the command). Then, the guest operating system 600 sends a write command to the IOMMU to update (e.g., advance, increment, etc.) the command buffer tail pointer in the corresponding IOMMU MMIO register to indicate that the guest operating system 600 has written a command to the command buffer. The IOMMU 602 detects the write by the guest operating system 600 to the command buffer tail pointer, such as by listening for writes to the address in the corresponding guest command buffer, detecting a change in the value of the buffer tail pointer, receiving a write command from the guest operating system 600, etc. Upon detecting the write to the command buffer tail pointer, the IOMMU 602 uses the value of the command buffer tail pointer to retrieve the command from the command buffer in the guest portion of the memory. Since the guest domain ID used by the guest operating system 600 in the command may be different from the host domain ID used by the IOMMU 602, if the IOMMU 602 uses the command without first translating the domain ID, the IOMMU 602 may invalidate an incorrect range of entries. The IOMMU 602 therefore determines the host domain ID associated with the guest domain ID in the command using an ID translation table (e.g., ID translation table 502). The IOMMU then retrieves the command from the guest command buffer 518 and replaces the guest domain ID in the command with the host domain ID. The IOMMU 602 then processes the command, causing the IOMMU 602 to invalidate the range of entries indicated by the host domain ID in its translation cache. The IOMMU 602 performs some similar operations at least for writes by the IOMMU 602 to the guest PPR log 516 and the guest event log 514 - such as replacing the host device ID with the guest device ID in a PPR request from an IO device or placing the guest domain ID and / or device ID in an event.

[0064] Although the hypervisor 604 does not participate in the translation of the guest domain ID to the host domain ID, the hypervisor 604 and the guest operating system 600 and / or the IOMMU 602 can exchange communications associated with the communication between the guest operating system 600 and the IOMMU 602 separately, or the hypervisor 604 can otherwise participate in ensuring that the guest operating system 600 and / or the IOMMU 602 correctly processes the communication. For example, the hypervisor 604 can directly (through communication) or indirectly (by listening to memory accesses) determine that the guest operating system 600 is communicating (e.g., writing to a command buffer) and can perform operations such as sending an interrupt signal to the guest operating system 600 and / or the IOMMU 602, updating a shared memory location used as a flag, etc.

[0065] Process of Translating Domain ID and Device ID in IOMMU

[0066] Figure 7 The figure presents a flowchart of a process for processing communications from a guest operating system in an IOMMU (e.g., IOMMU 424) according to some embodiments. More specifically, Figure 7 Operations are presented for translating a guest domain ID and / or a device ID in a communication from a guest operating system to a host domain ID and / or a device ID before processing the communication in the IOMMU. Note that, Figure 7 The operations shown are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0067] Figure 7 The operations shown apply to any communication received in the IOMMU from a guest operating system having a guest domain ID and / or a device ID. For example, the IOMMU can receive commands in a command buffer (e.g., within the guest command buffer 518 in the guest memory 512). Generally, the IOMMU can translate a guest domain ID and / or a device ID into a host domain ID and / or a device ID in various forms of communication from the guest operating system.

[0068] When the IOMMU receives a communication including a guest domain ID and / or a guest device ID from a guest operating system (e.g., guest operating system 600), Figure 7The operation begins (step 700). As described above, and as an effect of virtualization, the guest operating system uses a set of domain IDs and device IDs, which may be partially or completely different from the set of domain IDs and device IDs used by the electronic device (or "host") hardware (such as the IOMMU and / or IO devices). (It is possible that the domain ID and / or device ID may partially or fully match, but this possibility is small, especially in an electronic device that includes a large number of IO devices, virtual devices, domains, etc.). From the perspective of the IOMMU and other electronic device hardware, the communication received from the guest operating system may therefore include incorrect domain IDs and / or device IDs.

[0069] Then, the IOMMU determines the host domain ID associated with the guest domain ID and / or the host device ID associated with the guest device ID using the corresponding entry in the ID translation table (e.g., ID translation table 502) (step 702). For example, the IOMMU may use the guest domain ID to look up the corresponding host domain ID in the ID translation table. Note that in some embodiments, the ID translation table includes separate domain ID mapping and device ID mapping tables (e.g., domain ID mapping table 504 and device ID mapping table 506) - and the IOMMU performs the lookups accordingly.

[0070] The IOMMU then replaces the guest domain ID with the host domain ID and / or the guest device ID with the host device ID in the communication (step 704). For this operation, the IOMMU may change the communication itself, i.e., by writing the updated bits to the communication. Alternatively, the IOMMU may write or set internal registers, memory locations, etc. with the values of the host domain ID and / or device ID, thereby presetting or preparing the IOMMU for subsequent processing of the communication.

[0071] Then, the IOMMU processes the communication (step 706). For this operation, the IOMMU performs the typical operations associated with processing a particular communication, although after replacing the guest domain ID and / or device ID as described in step 704. For example, if the communication is a command, the IOMMU may process the command.

[0072] Figure 8 The figure presents a flowchart of a process for processing communication from an input / output (IO) device to a guest operating system in an IOMMU (e.g., IOMMU 424) according to some embodiments. More specifically, Figure 8 an operation for translating the host device ID in the communication to the guest device ID before forwarding the communication from the IO device to the guest operating system is presented. Note that Figure 8The operations shown are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0073] Figure 8 The operations shown apply to any communication received from an IO device having a host device ID in an IOMMU. For example, the IOMMU may receive a Peripheral Page Request (PPR) from the IO device. Generally, the IOMMU may translate the host device ID into a guest device ID in various forms of communication from the IO device. Additionally, although Figure 8 limited to IO devices (including the host device ID in the communication), similar operations may be performed on the host domain ID in the communication from the IO device - namely, translating the host domain ID into a guest domain ID in such communication.

[0074] When the IOMMU receives a communication including a host device ID from an IO device (e.g., IO device 408), Figure 8 the operations in start (step 800). As described above, and as an effect of virtualization, the IO device uses a set of device IDs that may be partially or completely different from the set of device IDs used by the guest operating system. From the perspective of the guest operating system, the communication received from the IO device in the IOMMU may thus include incorrect device IDs.

[0075] Then, the IOMMU determines the guest device ID associated with the host device ID using an entry in the device table (e.g., device table 526) (step 802). For example, the IOMMU may use the host device ID to look up the corresponding guest device ID in the device table.

[0076] The IOMMU then replaces the host device ID with the guest device ID in the communication (step 804). For this operation, in some embodiments, the IOMMU changes the communication itself, i.e., by writing updated bits into the communication. Alternatively, in some embodiments, the IOMMU writes or sets an internal register, memory location, etc. with the value of the guest domain ID - thereby indicating the guest device ID to the guest operating system and preparing the guest operating system to process the communication.

[0077] Then, the IOMMU forwards the communication to the guest operating system (step 806). For this operation, in some embodiments, the IOMMU forwards the communication by storing the communication in a memory location such as a PPR log in the corresponding guest memory. The IOMMU may also signal or indicate to the guest operating system that the communication is ready to be processed by the guest operating system. The guest operating system then processes the communication, i.e., performs typical operations associated with processing the particular communication.

[0078] Figure 9 The figure shows a flowchart of a process for generating communications to a guest operating system in an IOMMU (e.g., IOMMU 424) according to some embodiments. More specifically, Figure 9 The figure presents operations for including a corresponding guest device ID and / or domain ID in the communication before sending the communication from the IOMMU to the guest operating system. Note that Figure 9 The operations shown are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0079] Figure 9 The operations shown apply to any communication generated by the IOMMU that includes a guest domain ID and / or device ID and is destined for the guest operating system. For example, the IOMMU may generate a communication for reporting an event (e.g., a hardware fault, a page fault, etc.) to the guest operating system based on the occurrence of the event. Generally, the IOMMU may include a guest domain ID and / or device ID in various forms of communication to the guest operating system.

[0080] When the IOMMU generates a communication to the guest operating system, Figure 9 the operations in the figure begin (step 900). As described above, and as an effect of virtualization, the IOMMU uses a set of domain IDs and device IDs that may be partially or completely different from the set of domain IDs and device IDs used by the guest operating system. From the perspective of the guest operating system, communications generated by the IOMMU using the IOMMU's view of domain IDs and device IDs may thus include incorrect domain IDs and device IDs. When generating a communication, the IOMMU determines the guest device ID and / or domain ID used by the guest operating system for the corresponding I / O device using the corresponding entry in an ID translation table (e.g., ID translation table 502) (step 902). For example, the IOMMU uses the host device ID for the corresponding I / O device to look up the corresponding guest domain ID and / or device ID in the ID translation table. The IOMMU then places the guest domain ID and / or device ID in the communication (step 904). For this operation, in some embodiments, the IOMMU writes the corresponding bits to the communication, such as in a field of a record in the communication that holds the domain ID and / or device ID.

[0081] Then, the IOMMU forwards the communication to the guest operating system (step 906). For this operation, in some embodiments, the IOMMU forwards the communication by storing the communication in a memory location such as an event log in the corresponding guest memory. The IOMMU may also signal or indicate to the guest operating system that the communication is ready to be processed by the guest operating system. The guest operating system then processes the communication, i.e., performs the typical operations associated with processing a particular communication.

[0082] Process of Configuring IOMMU to Translate Device ID and Domain ID

[0083] Figure 10 The present disclosure shows a flowchart of a process for configuring an IOMMU (e.g., IOMMU 424) to translate domain IDs and device IDs according to some embodiments. More specifically, Figure 10 operations for setting entries in an ID translation table to indicate mappings between host domain IDs and / or device IDs and guest domain IDs and / or device IDs are presented. Note that Figure 10 the operations shown are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks. For example, while the hypervisor is described as performing Figure 10 certain operations, in alternative embodiments, another entity (e.g., a virtual machine, an electronic device operating system, a guest operating system, a software application, etc.) performs the operations.

[0084] When the IOMMU receives from the hypervisor a communication indicating a guest domain ID associated with a host domain ID or a guest device ID associated with a host device ID, Figure 10 the operations in

[0085] In some embodiments, the IOMMU receives and manages communications from the hypervisor that indicate each guest domain ID and / or device ID recognized by the guest operating system and the corresponding host domain ID and / or device ID. For example, in some embodiments, at boot time or at another time, the hypervisor loops through all guest domain IDs and / or device IDs recognized by the guest operating system, determines the mapping to host domain IDs and / or device IDs, and conveys information about each domain ID or device ID pairing / mapping.

[0086] In some embodiments, an electronic device (e.g., electronic device 400 and / or a portion thereof) performs some or all of the operations described herein using code and / or data stored on a non-transitory computer-readable storage medium. More specifically, when performing the described operations, the electronic device reads the code and / or data from the computer-readable storage medium and executes the code and / or uses the data. The computer-readable storage medium can be any device, medium, or combination thereof that stores code and / or data for use by the electronic device. For example, the computer-readable storage medium can include, but is not limited to, volatile and / or non-volatile memory, including flash memory, random access memory (e.g., eDRAM, RAM, SRAM, DRAM, DDR4 SDRAM, etc.), read-only memory (ROM), and / or magnetic or optical storage media (e.g., disk drives, tapes, CDs, DVDs, etc.).

[0087] In some embodiments, one or more hardware modules perform some or all of the operations described herein. For example, the hardware module can include, but is not limited to, one or more processors / cores / central processing units (CPUs), application-specific integrated circuit (ASIC) chips, neural network processors or accelerators, field-programmable gate arrays (FPGAs), compute units, embedded processors, graphics processing units (GPUs) / graphics cores, pipelines, accelerated processing units (APUs), caches / cache controllers, memories / memory controllers, functional blocks, and / or other programmable logic devices. When such hardware modules are activated, the hardware modules perform some or all of the operations. In some embodiments, the hardware module includes one or more general-purpose circuits configured to perform the operations by executing instructions (program code, firmware, etc.).

[0088] In some embodiments, data structures representing some or all of the structures and mechanisms described herein (e.g., electronic device 400, IOMMU 424, and / or portions thereof) are stored on a non-transitory computer-readable storage medium that includes a database or other data structure that can be read by an electronic device and used directly or indirectly to fabricate hardware including the structures and mechanisms. For example, the data structure can be a behavioral description or a register transfer level (RTL) description of a hardware function in a high-level design language (HDL) (e.g., Verilog or VHDL). The description can be read by a synthesis tool that can synthesize the description to produce a netlist that includes a listing of gates / circuit elements from a synthesis library, the listing representing the functionality of hardware including the above-described structures and mechanisms. The netlist can then be placed and routed to produce a dataset describing the geometry to be applied to a mask. The mask can then be used in various semiconductor manufacturing steps to produce one or more semiconductor circuits (e.g., integrated circuits) corresponding to the above-described structures and mechanisms. Alternatively, the database on the computer-accessible storage medium can be a netlist (with or without a synthesis library) or a dataset (as needed), or Graphics Data System (GDS) II data.

[0089] In this specification, variables or unspecified values (i.e., general descriptions of values in the absence of a particular instance of a value) are represented by letters such as N. As used herein, although similar letters may be used at different locations in this specification, the variables and unspecified values in each case are not necessarily the same, i.e., there may be different variable quantities and values intended for some or all of the general variables and unspecified values. In other words, in this specification, N and any other letter used to represent variables and unspecified values are not necessarily related to each other.

[0090] As used herein, the expressions “et cetera” or “etc.” are intended to present one and / or cases, i.e., equivalents of “at least one” of the elements in a list associated with “etc.”. For example, in the statement “The electronic device performs a first operation, a second operation, etc.”, the electronic device performs at least one of the first operation, the second operation, and other operations. Additionally, the elements in the list associated with “etc.” are merely examples in a set of examples, and at least some of the examples may not appear in some embodiments.

[0091] The previous description of the embodiments has been given for purposes of illustration and description only. The previous description is not intended to be exhaustive or to limit the embodiments to the disclosed form. Accordingly, many modifications and variations will be apparent to practitioners in the art. Additionally, the above disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. An electronic device, which comprises: a processor that executes a guest operating system and a hypervisor; an input / output device; and an input / output memory management unit configured to handle communication between the input / output memory management unit and the guest operating system by: in communication received from the guest operating system, replacing a guest domain identifier with a corresponding host domain identifier and / or replacing a guest device identifier with a corresponding host device identifier before further processing the communication received from the guest operating system; in communication received from the input / output device, replacing a host device identifier with a guest device identifier before providing the communication received from the input / output device to the guest operating system; and placing a guest domain identifier and / or a guest device identifier in communication generated in the input / output memory management unit and destined for the guest operating system, and then providing the communication generated in the input / output memory management unit to the guest operating system, wherein the input / output memory management unit is further configured to update an identifier translation table of the input / output memory management unit to include information of the guest operating system by: receiving a configuration communication from the hypervisor indicating that a given guest domain identifier is associated with a given host domain identifier or a given guest device identifier is associated with a given host device identifier for the guest operating system; and updating an entry in the identifier translation table to include information indicating that the given guest domain identifier is associated with the given host domain identifier or the given guest device identifier is associated with the given host device identifier for the guest operating system.

2. The electronic device according to claim 1, wherein the input / output memory management unit is further configured to: when replacing the guest domain identifier with a corresponding host domain identifier and / or replacing the guest device identifier with a corresponding host device identifier in the communication received from the guest operating system, use the identifier translation table by: determining from a corresponding entry in the identifier translation table a host domain identifier for replacing the guest domain identifier and / or a host device identifier for replacing the guest device identifier in the communication received from the guest operating system.

3. The electronic device according to claim 1, wherein the input / output memory management unit is further configured to: when placing the guest domain identifier and / or the guest device identifier in the communication generated by the input / output memory management unit, use the identifier translation table by: determining from a corresponding entry in the identifier translation table a guest domain identifier and / or a guest device identifier used by the guest operating system of an input / output device associated with the communication generated by the input / output memory management unit.

4. The electronic device according to claim 1, wherein for each given domain identifier and given device identifier used by the guest operating system, the input / output memory management unit receives a corresponding individual configuration communication from the hypervisor for updating the identifier translation table during the initialization operation of the guest operating system.

5. The electronic device according to claim 1, further comprising: a memory separate from the input / output memory management unit; wherein when updating the identifier translation table, the input / output memory management unit is further configured to: receive the configuration communication from the hypervisor via a memory-mapped input / output register in the input / output memory management unit; using an input / output memory management unit private address translation table, determine a location in the input / output memory management unit backup storage area in the memory where the identifier translation table is stored; and update the identifier translation table in the input / output memory management unit backup storage area.

6. The electronic device according to claim 1, wherein the communication received from the guest operating system includes information written to a command buffer of the input / output memory management unit.

7. The electronic device according to claim 1, wherein the hypervisor is configured to: determine that a given guest device identifier is associated with a given host device identifier for the guest operating system; and update the device table to include information for the guest operating system, the update including updating an entry for the corresponding device in the device table to include the given guest device identifier and an identification of the guest operating system.

8. The electronic device according to claim 7, wherein the input / output memory management unit is further configured to: when replacing a host device identifier with a guest device identifier in a communication received from the I / O device, use the device table by: determining from the corresponding entry in the device table the guest device identifier to be used to replace the host device identifier in the communication received from the input / output device.

9. The electronic device according to claim 7, wherein for each given device identifier used by the guest operating system, the hypervisor makes a corresponding update to the device table during the initialization operation of the guest operating system.

10. The electronic device according to claim 1, wherein the communication received from the input / output device includes a peripheral page request (PPR) of the guest operating system.

11. The electronic device according to claim 1, wherein the input / output memory management unit processes the communication between the input / output memory management unit and the guest operating system without the intervention of the hypervisor.

12. A method for processing communication between an input / output memory management unit and a guest operating system in an electronic device, the electronic device including a processor executing the guest operating system and a hypervisor, an input / output device, and the input / output memory management unit, the method comprising: In a communication received from the guest operating system, the input / output memory management unit replaces the guest domain identifier with a corresponding host domain identifier and / or replaces the guest device identifier with a corresponding host device identifier before further processing the communication received from the guest operating system; In a communication received from the input / output device, the input / output memory management unit replaces the host device identifier with a guest device identifier before providing the communication received from the input / output device to the guest operating system; and the input / output memory management unit places the guest domain identifier and / or the guest device identifier in a communication generated in the input / output memory management unit and destined for the guest operating system, and then provides the communication generated in the input / output memory management unit to the guest operating system; the input / output memory management unit updates the identifier translation table to include information about the guest operating system by: receiving, from the hypervisor, a configuration communication indicating that a given guest domain identifier is associated with a given host domain identifier or that a given guest device identifier is associated with a given host device identifier for the guest operating system; and updating an entry in the identifier translation table to include information indicating that the given guest domain identifier is associated with the given host domain identifier or that the given guest device identifier is associated with the given host device identifier.

13. The method according to claim 12, further comprising: when replacing the guest domain identifier with a corresponding host domain identifier and / or replacing the guest device identifier with a corresponding host device identifier in the communication received from the guest operating system, the input / output memory management unit uses the identifier translation table by: determining, from a corresponding entry in the identifier translation table, the host domain identifier used to replace the guest domain identifier and / or the host device identifier used to replace the guest device identifier in the communication received from the guest operating system.

14. The method according to claim 12, further comprising: when placing the guest domain identifier and / or the guest device identifier in the communication generated by the input / output memory management unit, the input / output memory management unit uses the identifier translation table by: determining, from a corresponding entry in the identifier translation table, the guest domain identifier and / or the guest device identifier used by the guest operating system of the input / output device associated with the communication generated by the input / output memory management unit.

15. The method according to claim 12, further comprising: for each given domain identifier and given device identifier used by the guest operating system, the input / output memory management unit receives, from the hypervisor, a corresponding individual configuration communication for updating the identifier translation table during guest operating system initialization operations.

16. The method according to claim 12, wherein the electronic device further includes a memory separate from the input / output memory management unit, and wherein the method further includes, when updating the identifier translation table: receiving, by the input / output memory management unit, the configuration communication from the hypervisor via a memory-mapped input / output (MMIO) register in the input / output memory management unit; determining, by the input / output memory management unit, a location in the input / output memory management unit backup storage area in the memory where the identifier translation table is stored, using an input / output memory management unit private address translation table; and updating, by the input / output memory management unit, the identifier translation table in the input / output memory management unit backup storage area.

17. The method according to claim 12, wherein the communication received from the guest operating system includes information written to a command buffer of the input / output memory management unit.

18. The method according to claim 12, further including: determining, by the hypervisor, that a given guest device identifier is associated with a given host device identifier for the guest operating system; and updating, by the hypervisor, the device table to include information for the guest operating system, the updating including updating an entry for the corresponding device in the device table to include the given guest device identifier and an identification of the guest operating system.

19. The method according to claim 18, further including: when replacing a host device identifier with a guest device identifier in a communication received from the input / output device, using, by the input / output memory management unit, the device table by: determining, from a corresponding entry in the device table, the guest device identifier to be used to replace the host device identifier in the communication received from the input / output device.

20. The method according to claim 18, further including: for a given device identifier used by the guest operating system, making a corresponding update to the device table by the hypervisor during a guest operating system initialization operation.

21. The method according to claim 12, wherein the communication received from the input / output device includes a peripheral page request (PPR) of the guest operating system.

22. The method according to claim 12, wherein the input / output memory management unit processes communication between the input / output memory management unit and the guest operating system without intervention by the hypervisor.

Images