Provides interrupts from the I / O Memory Management Unit to the guest operating system

Abstract

An electronic device includes: a processor that executes a guest operating system; a memory having a guest portion that is reserved for storing data and information to be accessed by the guest operating system; and an input-output memory management unit (IOMMU). The IOMMU performs operations for signaling an interrupt to the guest operating system. For these operations, the IOMMU obtains a location in a virtual advanced programmable interrupt controller (APIC) backup page for the guest operating system in the guest portion of the memory from an entry in an interrupt remapping table associated with the guest operating system. The IOMMU then writes information about the interrupt to the location in the virtual APIC backup page. Next, the IOMMU communicates an indication of the interrupt to the guest operating system.

Description

Background Art

[0001] Related technologies

[0002] Some electronic devices (e.g., servers or desktop computers, etc.) support "virtualization" of electronic device hardware such as input-output (IO) devices. Virtualization involves: when an intermediate entity on or in the electronic device intercepts / redirects or otherwise assists access by a software instance (e.g., application, etc.) executing on the electronic device, the intermediate entity provides the software instance with the illusion that the software instance can directly access the electronic device hardware. A common intermediate entity is a "virtual machine." A virtual machine is a software entity that abstracts the electronic device hardware and simulates or presents a known interface to the electronic device hardware, thereby enabling the software instance to execute on various types and arrangements of underlying electronic device hardware (possibly including electronic device hardware with which the software instance would otherwise be incompatible). In some electronic devices, 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 executing other software instances (such as productivity applications, databases, etc.).

[0003] In some electronic devices, virtual machines are 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 (PRGRM) 104, such as a database, software application, etc., are executed. The virtual machine 100 communicates with a hypervisor 106, which interfaces between a host operating system (host OS) 108 and the virtual machine 100. The host operating system 108 provides an interface between the electronic device hardware 110 and the hypervisor 106. In addition, the hypervisor 106 interfaces between the virtual machine 100 and an input-output management unit (IOMMU) 112, which serves as a memory management unit and controller for the IO device hardware 114.

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

[0005] FIG2 presents a block diagram illustrating the communication between a guest operating system and an IOMMU handled by a hypervisor. In FIG2 , a plurality of elements are illustrated as dotted / stippled; these elements are logs, buffers, etc. stored in a memory (e.g., the main memory of an electronic device) and thus accessed through typical memory access techniques. Together with the guest operating system 102, the hypervisor 106, and the IOMMU 112, the elements in FIG2 include a guest peripheral page request (PPR) log 200, a guest command buffer (CMD BUF) 202, and a guest event log 204, which are structures (e.g., lists, tables, etc.) in memory for storing data and information of the guest operating system 102 and other entities in the electronic device. In addition, the elements include guest pointers (PTRs) / status registers (REGs) 206, which are a set of locations in memory for storing pointers to guest operating system structures and status information associated with the guest operating system. The elements also include an IOMMU peripheral page request (PPR) log 208, an IOMMU command buffer 210, and an IOMMU event log 212, which are structures (e.g., lists, tables, etc.) in memory for storing communications from and to the IOMMU 112. The elements additionally include IOMMU memory mapped input-output (MMIO) pointer / 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. The elements also include a virtual advanced programmable interrupt controller (APIC) backing page 216 and a guest interrupt log 218, which are structures for communicating information about interrupts originating from the IOMMU from the IOMMU to the guest operating system through the hypervisor 106.

[0006] In operation, and using a command as an example, the guest operating system 102 writes a command destined for the IOMMU 112 to the guest command buffer 202 (i.e., to the next available location in the buffer in memory that stores commands from the guest operating system 102). As shown by the dashed line in FIG. 2 , the hypervisor 106 detects the guest operating system's write to the guest command buffer 202, retrieves and processes the command (e.g., replaces the guest domain ID and / or guest device ID in the command with the corresponding host domain ID and / or device ID, etc.), and stores the processed command in the IOMMU command buffer 210. The hypervisor 106 also updates the tail pointer for the IOMMU command buffer 210 in the IOMMU MMIO pointer / status register 214 to indicate the newly written command (e.g., increments the tail pointer to the next location in the IOMMU command buffer 210). The IOMMU 112 then retrieves the command from the IOMMU command buffer 210 using the tail pointer (and / or other pointers) and executes the command, which causes the IOMMU 112 to perform the corresponding action. The hypervisor 106 performs similar operations (e.g., replacing the host device ID with the guest device ID, etc.) for IOMMU 112 writes to the IOMMU peripheral page request log 208 and the IOMMU event log 212. Since the memory reads and writes, pointer updates, and other operations performed by the hypervisor 106 have a longer latency, intervening with the hypervisor 106 between the guest operating system 102 and the IOMMU 112 results in delays in processing communications, keeps the processor busy, and increases traffic on the memory bus of the electronic device.

[0007] In operation, the IOMMU 112 communicates interrupts originating from the IOMMU, such as time-, fault-, or error-based interrupts, directly to the guest operating system 102. More specifically, the IOMMU 112 communicates interrupts to the guest operating system 102 through the hypervisor 106—rather than communicating interrupts directly to the guest operating system 102. To communicate the interrupt to the guest operating system 102, the IOMMU 112 signals the interrupt to the hypervisor 106. The hypervisor 106 then writes information about the interrupt into the virtual APIC backing page 216 and signals the occurrence of the interrupt to the guest operating system 102. For example, the hypervisor 106 may set one or more interrupt request register bits associated with the interrupt in the virtual APIC backing page 216 and then assert a doorbell signal or write to a shared memory location to signal the occurrence of the interrupt to the guest operating system 102. Upon receiving the signal from the hypervisor 106, the guest operating system 102 obtains information about the interrupt from the virtual APIC backing page 216 and processes the interrupt. In some electronic devices, the guest operating system 102 may be in an inactive state (e.g., shut down while another guest operating system is executing) when the interrupt occurs. In this case, the hypervisor 106 adds information about the interrupt to the guest interrupt log 218, which will be used to handle the interrupt when the guest operating system 102 returns to an active state. As with other types of communications, relying on the hypervisor 106 as an interface for interrupt handling results in longer interrupt handling times, more memory bus traffic, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 presents a block diagram illustrating a virtual machine and a hypervisor.

[0009] 2 presents a block diagram illustrating communications between a guest operating system and an IOMMU handled by a hypervisor.

[0010] Figure 3 A block diagram illustrating a virtual machine and a hypervisor according to some embodiments is presented.

[0011] Figure 4 A block diagram is presented showing an electronic device according to some embodiments.

[0012] Figure 5 A block diagram is presented showing portions of memory accessed by an IOMMU according to some embodiments.

[0013] Figure 6 A block diagram illustrating values ​​stored in a guest copy of an IOMMU MMIO register is presented according to some embodiments.

[0014] Figure 7A block diagram is presented illustrating communications between a guest operating system and an IOMMU handled by the IOMMU according to some embodiments.

[0015] Figure 8 A flow diagram is presented that illustrates a process during which an IOMMU signals an interrupt to a guest operating system according to some embodiments.

[0016] Fig. 9 A block diagram illustrating a lookup in an interrupt remapping table according to some embodiments is presented.

[0017] Like reference numerals refer to like figure elements throughout the drawings and the description. DETAILED DESCRIPTION

[0018] The following description is presented to enable any person skilled in the art to make and use the described embodiments, and is provided in the context of a specific 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 may be applied to other embodiments and applications. Therefore, 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] the term

[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 this term may have important additional aspects, which are not listed herein for the sake of clarity and brevity, and therefore the description is not intended to limit the term.

[0021] Functional Block: A functional block refers to a group, set, and / or collection 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, the interrelated circuit elements may be included in a particular integrated circuit chip or a portion thereof, manufactured on a particular integrated circuit chip or a portion thereof, or otherwise coupled to a particular integrated circuit chip or a portion thereof, may be involved in the execution of a given function (computational or processing function, memory function, etc.), may be controlled by a common control element and / or 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 "virtualization" of electronic device hardware such as memory, input-output (IO) devices, etc. Virtualization generally involves: when an intermediate entity on or in the actual electronic device intercepts / redirects, translates, or otherwise assists the access performed by the software instance executed on the electronic device, the intermediate entity provides the software instance with the illusion that the software instance can directly access the electronic device hardware. 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 copy 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 electronic device hardware virtualization, such as enabling different electronic devices to use different electronic device hardware arrangements, different electronic device hardware addresses, locations, or identifiers, etc., while the software instance presents the same interface with the electronic device hardware via the intermediate entity. In addition, the intermediary entity can determine whether to allow or block access to the electronic device hardware by a given software instance, and thus the virtualization of the electronic device hardware implements protection of the electronic device hardware (or portions thereof) and / or software instances executing on the electronic device. By controlling access as described above, the intermediary entity can share the electronic device hardware between multiple software instances and / or provide exclusive access to portions of the electronic device hardware to a separate software instance.

[0024] In the described embodiments, the intermediate entity includes a "virtual machine". A virtual machine is a software entity that abstracts the electronic device hardware and presents a known interface to the actual or simulated electronic device hardware to the software instance. Abstracting the hardware enables the software instance to execute on various types and arrangements of underlying electronic device hardware (possibly including electronic device hardware with which the software instance would otherwise be incompatible). 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 executing other software programs (such as applications, databases, etc.).

[0025] In the described embodiments, the virtual machines are 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; initialize the data structures, tables, etc. used by the virtual machine or the guest operating system; terminate or shut down the virtual machine, etc. Figure 3 A block diagram illustrating a virtual machine and a hypervisor according to some embodiments is presented. Figure 3As can be seen in FIG. 1 , 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 a database, software application, etc., are executed. The virtual machines 300 communicate with a hypervisor 306, which interfaces 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. Unlike the one shown in FIG. 1 for the existing electronic device, in FIG. Figure 3 314, without the intervention of the hypervisor 306 (as shown by the thicker line between the IOMMU 312 and the guest operating system 302). Thus, unlike in existing electronic devices, in the described embodiments, the hypervisor 306 is not responsible for performing at least some operations for handling communications between the guest operating system 302 and the IOMMU 312, as described herein. However, note that some communications occur between the IOMMU 312 and the hypervisor 306, as shown by the line between the hypervisor 306 and the IOMMU 312. Further, note that in some embodiments, the host operating system 308 is not present and the hypervisor 306 communicates more directly with the electronic device hardware 310.

[0026] Overview

[0027] In the described embodiments, the electronic device includes a processor, a memory (e.g., a main memory), a plurality of input-output (IO) devices (e.g., a network interface device, a disk controller, etc.), and an input-output memory management unit (IOMMU) interfaced between the processor and the IO devices. The processor executes a hypervisor, one or more virtual machines, and executes guest operating systems in the virtual machines. Each of the guest operating systems is allocated a guest portion of memory (contiguous or non-contiguous regions or memory blocks) that is reserved for storing data and information to be accessed by the guest operating system. In the described embodiments, the IOMMU performs operations for handling communications between the guest operating system and the IOMMU, and vice versa.

[0028] In some embodiments, as part of the operation for handling communications between the guest operating system and the IOMMU, the IOMMU communicates information about interrupts directly to the guest operating system. In other words, the IOMMU performs an operation for signaling the guest operating system that an interrupt originating from the IOMMU (which may be generated by the IOMMU itself or based on the activity of an IO device or other entity) is waiting for the guest operating system to process or handle. After receiving information about the interrupt from the IOMMU, the guest operating system performs an operation for processing or handling the interrupt originating from the IOMMU. As used herein, information about interrupts originating from the IOMMU is communicated "directly" from the IOMMU to the guest operating system, meaning that for an active / running guest operating system, operations for communicating information about interrupts are performed without the involvement of a hypervisor. However, the hypervisor may handle some operations for communicating information about interrupts originating from the IOMMU to an inactive operating system.

[0029] In some embodiments, the IOMMU communicates information about interrupts originating from the IOMMU to the guest operating system through a corresponding virtual advanced programmable interrupt controller (APIC) backup page in the guest portion of the memory. Typically, each virtual APIC backup page is a memory portion (e.g., one or more 4kB memory pages) for an APIC functional block for a corresponding guest operating system in a virtualized electronic device. The virtual APIC backup page includes multiple locations (e.g., entries, portions, etc.) that are used by hypervisors and other entities to emulate registers, memory locations, control values, etc. of the APIC functional block so that the guest operating system can receive and process or handle interrupts. APIC, APIC virtualization, and virtual APIC backup pages are described in, for example, the AMD64 Architecture Programmer's Manual Volume 2: System Programming, Revision 3.30, September 2018, which is incorporated herein by reference in its entirety. In some embodiments, in addition to previously known interrupt control and communication locations, the virtual APIC backup page of each guest operating system also includes one or more locations dedicated to and for storing information about a specified interrupt originating from the IOMMU. For example, in some embodiments, the virtual APIC backing page for each guest operating system includes a separate location (e.g., entry, portion, etc.) for each different type of IOMMU-derived interrupt that can be handled by the guest operating system. For another example, in some embodiments, the virtual APIC backing page for each guest operating system includes a single combined location for all different types of IOMMU-derived interrupts that can be handled by the guest operating system.

[0030] In some embodiments, the IOMMU uses an interrupt remapping table to determine the location in the virtual APIC backup page where information about the interrupt is to be written for signaling the interrupt to the guest operating system. Typically, an interrupt remapping table is a table stored in a memory, the table comprising a plurality of entries, each entry being used to store an identifier (e.g., address, offset, etc.) of a location in the memory where information about a specified interrupt is to be stored. The interrupt remapping table is described in detail, for example, in the AMD I / O Virtualization Technology (IOMMU) Specification, Revision 3.00, December 2016, which is incorporated herein by reference as described above. In these embodiments, in addition to previously known entries in the interrupt remapping table, the interrupt remapping table also includes entries for storing identifiers of the above-mentioned locations in the virtual APIC backup page for each guest operating system.

[0031] In some embodiments, during operation, when the IOMMU encounters an interrupt originating from the IOMMU that is destined for a given guest operating system, the IOMMU obtains from the interrupt remapping table an identifier of a location in the virtual APIC backup page for the given guest operation where information about the interrupt is to be written. The IOMMU then uses the identifier to write information about the interrupt to the location in the virtual APIC backup page for the given guest operating system. The IOMMU also communicates an indication of the interrupt to the given guest operating system, which causes the given guest operating system to retrieve information about the interrupt from the location in the virtual APIC backup page and process or dispose of the interrupt. In some embodiments, the mechanism for communicating an indication of the interrupt to a given guest operating system depends on the active / inactive state of the guest operating system—that is, whether the processor is currently executing a given guest operating system or performing another task with a given guest operating system that is temporarily inactive. These mechanisms are described in more detail below.

[0032] The described embodiments avoid the need to rely on a hypervisor to handle interrupts originating from the IOMMU as exists in prior systems by having the IOMMU write information about interrupts originating from the IOMMU to a virtual APIC fallback page for the guest operating system and communicate an indication of the interrupt to the guest operating system, thereby communicating the interrupt directly to the guest operating system. Moving these operations from the hypervisor (implemented in software) to the IOMMU (implemented in hardware) speeds up the operations, requires less memory system bandwidth, and reduces the load on computational functional blocks in the processor, which improves the overall performance of the electronic device. The improved performance of the electronic device results in higher user satisfaction.

[0033] Electronic Devices

[0034] Figure 4A block diagram illustrating an electronic device 400 according to some embodiments is presented. Figure 4 As can be seen, electronic device 400 includes processor 402 , memory 404 , mass storage device 406 , input-output (IO) devices 408 - 412 , input-output (IO) hub 414 , and memory controller 416 .

[0035] The processor 402 is a functional block that performs calculations and other operations in the electronic device 400. The processor 402 includes two cores 418-420, each of which includes 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. The 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 backup buffer lookup, etc.), memory access protection, etc. to perform memory access by the cores 418-420. The processor 402 further includes an advanced programmable interrupt controller (APIC) 430, which is a functional block that performs operations associated with interrupt processing in the processor 402. APIC is known in the art and is therefore not described in detail. In some embodiments, APIC 430 is virtualized for guest operating systems and functions of simulations as known in the art or described herein.

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

[0037] The mass storage device 406 is a functional block and / or device that performs operations of a high-capacity non-volatile storage element for storing data and instructions for use by other functional blocks in the electronic device 400. The mass storage device 406 may be or include a high-capacity semiconductor memory (e.g., flash memory, etc.), a disk drive (hard disk drive, etc.), an optical drive, etc. A copy of the data and instructions stored in the mass storage device 406 is obtained and stored in the memory 404 for use by other functional blocks in the electronic device 400. For example, in some embodiments, data and / or instructions are retrieved from the mass storage device 406 in blocks or "pages" of a given size (e.g., 4kB, 2MB, etc.) and the pages are stored in the memory 404 for access by other functional blocks. In addition, a new page may be created at an available location in the memory 404 (e.g., for storing calculation results, etc.).

[0038] 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 devices. For example, IO devices 408-412 may include human-machine interface devices, network interface devices, audio / visual processing or providing devices, GPUs, sensor devices, disk controllers, peripheral component interfaces (PCI) devices, universal serial bus (USB) devices, etc., and each IO device performs associated operations, such as receiving input from people (e.g., keyboards, mice, etc.), receiving or sending data on a network, etc. 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 the functional blocks. For example, in some embodiments, IO devices 408-412 access (i.e., read, write, invalidate, etc.) data in memory pages in memory 428 (i.e., portions of memory reserved for a given guest operating system).

[0039] In some embodiments, the IOMMU 424 monitors operations initiated by the IO devices 408-412, such as requests for direct memory access (DMA) to the memory 404, interrupts to the cores 418-420, peripheral page requests, etc. Based on the operations initiated by the IO devices 408-412, the IOMMU 424 may determine that an interrupt is to be signaled to the hypervisor and / or the guest operating system (e.g., to an appropriate driver in the hypervisor and / or the guest operating system). For example, the IOMMU 424 may encounter an error in translating a DMA address, may write a PPR log request, etc., and may determine that an interrupt is to be signaled to the hypervisor and / or the guest operating system. Some or all of these interrupts are handled using the operations described herein.

[0040] The IO hub 414 is a functional block that performs the operation of an input-output hub that interfaces 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 operations for ensuring that communications to the IO devices 408-412 reach the intended IO devices, communications from the IO devices 408-412 correctly reach other functional blocks, preventing unauthorized access by the IO devices 408-412 to other functional blocks, and vice versa, etc. In some embodiments, the IO hub 414 interfaces between buses that use different communication standards (such as between a peripheral component interface express (PCIe) bus and a HyperTransport Express (HTE) bus). between, etc.), and thereby convert or translate the associated communications.

[0041] The IO hub 414 includes an IOMMU 424, which is a functional block that performs operations for enabling the IO devices 408-412 to access data and / or instructions in the memory 404, communicates with the processor 402 (and the guest operating system executed thereby), etc. In these embodiments, when an IO device (e.g., IO device 408) wants to access data and instructions in the memory 404, the IO device sends a memory access request (e.g., a direct memory access request or DMA) to the IOMMU 424. The IOMMU 424 then 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 obtains 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 IO device. In some embodiments, the IOMMU 424 includes page tables, translation lookaside buffers, and / or other functional blocks for translating "virtual" or local memory addresses used by the IO devices 408-412 into physical addresses where the data is actually located in the memory 404. In addition, when another functional block and / or device in the electronic device 400 wants to access an IO device (e.g., communicate with or retrieve data from the IO device), the IOMMU 424 interfaces between the functional blocks and / or devices to enable access, such as by forwarding communications, control values, data, etc.

[0042] In the described embodiments, the IOMMU 424 communicates with the guest operating system executed by the cores 418-420 in the virtual machine, and vice versa. For example, in some embodiments, the IOMMU 424 (or the IO devices 408-412 through the IOMMU 424) communicate events and peripheral page requests (PPRs) to the guest operating system. In these embodiments, the IOMMU 424 reports events such as IO page faults (page table traversals on behalf of the IO devices 408-412), IOMMU 424 hardware errors, etc. to the guest operating system through the shared guest event log in the memory 404. In addition, in these embodiments, the IOMMU 424 forwards PPRs from peripheral devices (IO devices) to the guest operating system, and the PPRs perform memory page service operations (i.e., perform operations on pages in the memory 404 that can be accessed by the guest operating system or perform operations associated with the pages) using the well-known address translation service or ATS standard through the shared guest PPR log in the memory 404. For another example, in some embodiments, the guest operating system communicates commands to the IOMMU 424. In these embodiments, the guest operating system issues commands to the IOMMU 424 through the shared guest command buffer in the memory 404 to control the IOMMU 424 and / or the IO devices 408-412, such as completion wait (which acts as a command barrier to force earlier commands to complete before the IOMMU 424 proceeds), device table entry invalidation, IOMMU 424 translation lookaside buffer entry invalidation, etc. For another example, the IOMMU 424 communicates information about interrupts originating from the IOMMU, such as peripheral page request interrupts, event-based interrupts, instruction completion-based interrupts (e.g., completion wait interrupts, completion wait synchronization interrupts, etc.), etc. to the guest operating system. As described in more detail below, the IOMMU 424 communicates information about interrupts to the guest operating system using virtual APIC lookaside pages.

[0043] In some embodiments, the IOMMU 424 provides an interface to the guest operating system that 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 in that the memory locations, registers, etc. are not used to store values ​​as assumed by the guest operating system, but are simply presented as such by the IOMMU 424. In these embodiments, the IOMMU 424 can receive values ​​from the guest operating system through the interface (e.g., which are addressed to the IOMMU MMIO address, etc.), but uses the IOMMU backing store 426 and / or other locations in the memory 404 to store a separate copy of the value in a memory location, register, etc. for each guest operating system. The memory accessed by the IOMMU 424 to communicate with the guest operating system and other entities (e.g., the processor 402, etc.) is described in more detail below.

[0044] In some embodiments, although not in Figure 4 4, but the IOMMU 424 includes a local cache memory for storing copies of data or information of the IOMMU 424. For example, in some embodiments, the cache memory is used to store copies of recently used or frequently used data from the IOMMU backup storage area 426, such as the value set of the IOMMU MMIO registers for a given guest operating system and / or the individual values ​​therein. The cache memory is smaller than the IOMMU backup storage area 426 and thus may have a capacity (i.e., memory locations) for storing only a portion (and possibly a small portion) of the data and information stored in the IOMMU backup storage area 426.

[0045] The guest memory 428 is a portion of the memory 404 (e.g., one or more contiguous or discontinuous pages or blocks of memory) that is used by the corresponding guest operating system to store data and information to be used by the guest operating system. In general, the guest operating system 428 and / or other entities can use the guest memory 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 and only certain entities are allowed to access the guest memory 428. For example, the corresponding guest operating system, hypervisor, security processor, and / or operating system in the electronic device 400 can "protect" the guest memory 428 by limiting access to the guest memory 428 to the corresponding guest operating system and specified other devices and / or functional blocks. In some embodiments, the guest memory 428 is encrypted or otherwise rendered inaccessible to non-desired entities. In some embodiments, the guest memory 428 is used to store guest event logs, guest peripheral page request (PPR) logs, and guest command buffers, which are data structures (e.g., tables, lists, etc.) used for communication between the guest operating system and the IOMMU. Additionally, in some embodiments, guest memory 428 is used to store virtual APIC backing pages (e.g., one or more N-byte memory blocks) used by the hypervisor and other entities to enable the guest operating system to receive and process / handle interrupts. The guest event log, guest peripheral page request (PPR) log, guest command buffer, and virtual APIC backing pages are described in more detail below.

[0046] Hypervisor memory 432 is a portion of memory (e.g., one or more contiguous or non-contiguous pages or blocks of memory) that is used by the hypervisor to store data and information to be used by the hypervisor and / or other entities. In general, hypervisor memory 432 may be used by the hypervisor and / or other entities to store various forms of data and information to be used by the hypervisor and / or other entities. For example, in some embodiments, hypervisor memory 432 includes data and / or information such as device tables, interrupt remapping tables, etc. Although hypervisor memory 432 is described as "hypervisor" memory, in some embodiments, hypervisor memory 432 is accessible by various other entities in the system - and only includes memory areas or locations that store data and / or information initialized, maintained, and / or accessed by the hypervisor. In some embodiments, at least some of the things shown and described as hypervisor memory 432 are simply data and / or information that is stored in system memory and can be freely read and possibly freely written by the hypervisor and / or other entities.

[0047] 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 arrow lines between elements. The communication paths include one or more buses, wires, conductors, and / or other connections, possibly together with controllers, fabric elements (switches, routers, etc.), circuit elements, etc. The communication paths are used to route commands, data, control signals, and / or other information between functional blocks. For example, in some embodiments, a coherent bus fabric or interconnect is coupled between the IO hub 414, the processor 402 (e.g., MMU 422), and the memory 404. Note that for clarity, some of the communication paths in the electronic device 400 are not shown in FIG. Figure 4 Shown in.

[0048] In some embodiments, Figure 3 The electronic device hardware 310 in the embodiment includes functional blocks and devices such as processor 402 and memory 404, and the IO device hardware 314 includes functional blocks and devices such as IO devices 408-412. In these embodiments, Figure 3 The IOMMU 312 and Figure 4 The IOMMU 424 in performs at least some of the same operations.

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

[0050] The electronic device 400 may be any electronic device that performs computing operations, or may be included therein. For example, the electronic device 400 may be 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 equipment, a network appliance, a toy, an audio-visual equipment, a home appliance, a controller, a vehicle, etc. and / or a combination thereof, or may be included therein.

[0051] Interrupts from IOMMU

[0052] In the described embodiments, the IOMMU (e.g., IOMMU 424) performs operations for communicating interrupts originating from the IOMMU to the guest operating system with signals. Interrupts communicated to the guest operating system with signals are "originating from the IOMMU" because the interrupts are generated by the IOMMU. For example, the IOMMU may generate an interrupt to notify the guest operating system of events encountered, executed, or occurring in the IOMMU, such as faults or errors, guest operating system logs or buffer writes, etc. As another example, the IOMMU may generate an interrupt to notify the guest operating system of operations initiated by the IO device and / or errors or faults that occur when processing operations initiated by the IO device. Typically, in the described embodiments, the IOMMU may use the described mechanisms (i.e., virtual APIC backup pages, etc.) to communicate any type of interrupts to the guest operating system with signals. In other words, an "interrupt originating from the IOMMU" may be or include any interrupt that can be communicated from the IOMMU to the guest operating system.

[0053] Portions of memory accessed by the IOMMU

[0054] In some embodiments, the IOMMU accesses data and information in different portions of memory (e.g., memory 404) in order to perform the operations described herein and other operations. In some of these embodiments, the memory portions include an IOMMU backing store (e.g., IOMMU backing store 426), guest memory (e.g., guest memory 428), and / or hypervisor memory. Figure 5 A block diagram illustrating portions of memory accessed by an IOMMU according to some embodiments is presented. Figure 5 Presented as examples, but in some embodiments, the memory and / or different portions of the memory store different types and / or arrangements of information. Typically, the memory includes sufficient information to implement the operations described herein.

[0055] As in Figure 5 As can be seen in FIG. 5 , the IOMMU backing store 500 includes an ID translation table 502. Typically, the ID translation table 502 includes information used by the IOMMU to translate or convert guest domain IDs and / or device IDs in communications from a guest operating system to the IOMMU (or vice versa for communications from the IOMMU to the guest operating system). Domain IDs and device IDs 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 noted above.

[0056] In some embodiments, the ID translation table 502 includes a separate table for domain IDs (shown as domain ID mapping table 504) and a table for device IDs (shown as device ID mapping table 506), but separate tables are not required (so all translations may 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 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 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., domain ID mapping table 504 and / or device ID mapping table 506) to obtain the corresponding translation or conversion.

[0057] The IOMMU backing store 500 also includes guest controls 508. Typically, the guest controls 508 include copies of values ​​stored in or from interface registers and control registers for a guest operating system in the electronic device. For each supported guest operating system, the guest controls 508 include copies of guest interface registers and / or guest operating system control registers (or at least the values ​​therein) that control the interaction between the IOMMU and the guest operating system. For example, for each guest operating system, the guest controls 508 may include mapping control registers for communicating the domain ID and / or device ID mapping of the guest operating system to the IOMMU.

[0058] 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 (e.g., guest command buffers, guest event logs, and guest PPR logs) in the guest portion of memory 404 (e.g., guest memory 428) for the guest operating system. More specifically, for each supported guest operating system, the guest MMIO 510 includes a copy of the values ​​used to control access to the buffers and logs in the guest portion of memory 404. For example, in some embodiments, the IOMMU supports 2 N guest operating systems (which can interact with, handle their communications, etc.), where N = 10, 16, or other values, and thus guest MMIO 510 includes up to 2 values N In the described embodiment, the values ​​used to control access are similar to the values ​​stored in the IOMMU MMIO registers in existing devices, although a separate set of values ​​is maintained for each supported guest operating system - and refers to the guest portion of memory 404 for that guest operating system (rather than a single copy in the IOMMU in existing devices).

[0059] Figure 6 A block diagram illustrating values ​​stored in guest MMIO 510 according to some embodiments is presented. Figure 6 The example in , shows the values ​​of a single complete IOMMU MMIO register set for a given guest operating system and the values ​​of portions of two adjacent IOMMU MMIO register sets above and below the single complete set of values. Figure 6 It is shown in this manner to illustrate that, as described above, in some embodiments, the IOMMU backing store 426 includes multiple separate value sets, each value set being associated with a given guest operating system. Figure 6 Presented as an example, in some embodiments, guest MMIO 510 stores different values ​​or different arrangements of values. Typically, guest MMIO 510 and / or another entity stores sufficient information to access buffers and logs in the guest portion of memory, as described herein.

[0060] The values ​​in each value set in the guest MMIO 510 can be generally grouped into values ​​associated with a guest command (CMD) buffer, a guest event log, and a guest PPR log of the guest operating system. For a guest command buffer, the values ​​include a command tail pointer 600, which is a pointer or other reference indicating the end, tail, or most recently written entry of the guest command buffer in the corresponding guest portion of memory 404. In other words, the command tail pointer 600 stores a pointer or reference indicating the location of the tail or most recently written entry of the command buffer, such as a memory address, for example, some or all bits of a physical address in the guest portion of memory 404. The values ​​of the guest command buffer also include a command head pointer 602, which is a pointer or other reference indicating the head or base of the command buffer (i.e., the location in the corresponding guest portion of memory 404 where the command buffer begins and / or the buffered commands begin). The values ​​of the guest command buffer also include a command length 604, which is a value indicating the current size or maximum size of the command buffer, such as the number of entries or bytes. The guest command buffer values ​​also include command control 606, which is a bit set or sequence that includes a plurality of bits (or combinations thereof) that indicate the configuration of the guest operating system and / or the command buffer in the corresponding guest portion of memory 404. For example, in some embodiments, command control 606 includes bits that indicate whether certain command buffer-related interrupts are enabled, whether command buffering or processing is enabled (or disabled / paused), what types of commands are present or allowed to be present in the command buffer, etc. For example, in some embodiments, command control 606 includes control values ​​for command buffers similar to those described in the AMD I / O Virtualization Technology (IOMMU) Specification, Revision 3.00 (which specification is incorporated herein by reference as described above), such as CmdWaitInt, CmdBufRun, CmdWaitInteEn, CmdBufEn, and / or other values.

[0061] For the event log, the values ​​in the guest MMIO 510 (i.e., event tail pointer 608, event head pointer 610, event length 612, and event control 614) are functionally similar to those described above for the command buffer, although these values ​​are used to access the event log in the corresponding guest portion of memory 404. The same is true for the PPR log, because the values ​​in the guest MMIO 510 (i.e., PPR tail pointer 616, PPR head pointer 618, PPR length 620, and PPR control 622) are functionally similar to those described above for the command buffer, although these values ​​are used to access the PPR log in the corresponding guest portion of memory 404.

[0062] In some embodiments, fewer than the supported number of guest operating systems (and possibly much fewer) may be executing in the electronic device 400 at any given time. In some of these embodiments, the IOMMU backing store 500 is dynamically adjusted to include enough space to store the guest MMIO 510, etc. In other words, when the guest operating system is initialized / active, the hypervisor and / or another entity may allocate, attach, or activate space in the IOMMU backing store 500 (i.e., in the guest MMIO 510) for storing the IOMMU MMIO register values ​​of the guest operating system. In some of these embodiments, the IOMMU backing store 500 does not have additional empty / unused space allocated for virtual machines that do not yet exist (i.e., have not yet been initialized) in the electronic device 400.

[0063] In some embodiments, the hypervisor performs at least some initialization operations for the IOMMU backup storage area 500. For example, in some embodiments, the hypervisor allocates memory (e.g., continuous or scattered memory pages) in the memory 404 for storing the IOMMU backup storage area. As described above, the memory 404 is a general memory used by various functional blocks (e.g., cores 418-420, etc.) in the electronic device 400 to store data and information - and not just local memory in the IOMMU. Therefore, this operation involves the hypervisor allocating space in the "main" memory of the electronic device 400 for storing the IOMMU backup storage area. For example, in some embodiments, for each active guest operating system, the hypervisor writes the initial value to a copy of the IOMMU MMIO register in the backup storage area through the IOMMU. Therefore, the hypervisor writes the initial value and control value of the pointer for each active guest operating system to the corresponding copy of the IOMMU MMIO register in the IOMMU backup storage area, such as when the guest operating system starts.

[0064] In some embodiments, the copy of the IOMMU MMIO register in the IOMMU backup storage area only includes a subset of the available IOMMU MMIO registers. In these embodiments, other registers can be provided by the IOMMU itself. For example, in some embodiments, the registers storing IOMMU control values ​​(e.g., IOMMU enable / disable, etc.), page table base addresses, etc. in the IOMMU are provided by the IOMMU. Typically, the IOMMU MMIO registers that are not used to access the buffer and log in the memory portion for the guest operating system are not presented as copies, but a single copy of each register is provided by the IOMMU. In some of these embodiments, the hypervisor simulates these IOMMU registers for the guest operating system, but for the registers in the IOMMU, the access is received by the IOMMU and handled in the IOMMU.

[0065] refer to Figure 5 , the guest memory 512 includes a guest event log 514, a guest peripheral page request (PPR) log 516, a guest command buffer 518, and a virtual APIC backup page 520 for the guest operating system. Generally, the guest event log 514, the guest PPR log 516, the guest command buffer 518, and the virtual APIC backup page 520 are structures (e.g., lists, tables, buffers, etc.) in the memory for storing corresponding events, PPR requests, commands, and information about interrupts and / or for processing or handling interrupts for access by the IOMMU and / or the guest operating system. For example, the guest event log 514 can be a table or a ring buffer including a plurality of entries (e.g., 24, 50, etc.), each entry being used to store information (e.g., a bit pattern) representing a specific event occurring in the IOMMU to be processed by the corresponding guest operating system. For another example, the virtual APIC backup page can be a table or list in the memory that includes the values ​​of registers or memory locations in the virtualized copy of the APIC and the values ​​provided by the IOMMU for interrupts originating from the IOMMU. In operation, the IOMMU communicates events and PPRs to the guest operating system through corresponding logs in guest event log 514 and guest PPR log 516 in guest memory 512. In addition, the guest operating system communicates commands to the IOMMU through corresponding command buffers in guest command buffers 518 in guest memory 512. The IOMMU and / or other entities also communicate information about interrupts to the guest operating system through virtual APIC fallback pages 520.

[0066] As in Figure 5 As can be seen in FIG. 5 , the virtual APIC backup page 520 includes a virtual APIC value 522, which includes values ​​of a virtualized APIC for emulating a corresponding guest operating system, such as an interrupt command register (ICR), an interrupt request register (IRR), an in-service register (ISR), an end of interrupt (EOI), etc. These values ​​and the functions associated therewith are known in the art and are described in, for example, the AMD64 Architecture Programmer's Manual Volume 2: System Programming, Revision 3.30, September 2018, which is incorporated herein by reference as described above.

[0067] The virtual APIC backup page 520 also includes an IOMMU value 524, which is a value used by the IOMMU to convey information about interrupts originating from the IOMMU to the corresponding guest operating system—and does not exist in existing electronic devices. In some embodiments, the IOMMU value 524 includes a separate value for conveying information about each allowed type of interrupt originating from the IOMMU to the corresponding guest operating system. Therefore, in these embodiments, if there are N types of interrupts originating from the IOMMU, there will be N values ​​in the IOMMU value 524. In some embodiments, the IOMMU value 524 includes a single value for conveying information about all types of interrupts originating from the IOMMU to the corresponding guest operating system. Typically, the information in the IOMMU value 524 is sufficient to convey the type, parameters, and / or other characteristics of the corresponding interrupt originating from the IOMMU to the corresponding guest operating system. For example, in some embodiments, each interrupt originating from the IOMMU can be characterized or represented by a multi-bit value, which includes one or more interrupt identifiers, one or more source / destination identifiers, one or more control values, one or more target values, and / or other values.

[0068] Although certain values ​​are shown in the virtual APIC backup page 520, in some embodiments, the virtual APIC backup page 520 includes different values ​​and / or a different arrangement of values. The virtual APIC backup page 520 generally includes sufficient values ​​to perform the operations described herein.

[0069] In some embodiments, each active guest operating system in the electronic device 400 is associated with a corresponding separate guest portion of memory (i.e., multiple pages in the memory 404) that includes a guest event log, a peripheral page request log, a guest command buffer, and a virtual APIC fallback page used by the guest operating system and accessible by the IOMMU. Figure 5 Additional guest memories 526 - 528 are shown as being located behind guest memory 512 .

[0070] The hypervisor memory 530 includes a device table 532, an interrupt remapping table 534, and a guest interrupt log 536. In general, the device table 532 is a table in which device-related information of devices (which may be actual / physical devices or virtual devices) in, associated with, and / or coupled to the electronic device is stored. The device table 532 includes a set of entries, each of which can be used to store information about the corresponding device, such as pointers to page tables and interrupt remapping tables, control and configuration values, capacity indicators, mode indicators, domain IDs, security information and settings, etc. In addition, in the described embodiment (and unlike in existing device tables), each entry in the device table 532 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 the device, the IOMMU also uses the device ID and / or guest identifier to translate or convert the guest device ID to the host device ID. The IOMMU also uses the interrupt remap table root pointer in the device table entry associated with the IOMMU to determine the location (eg, address and / or offset) in memory where the interrupt remap table 534 is stored.

[0071] The interrupt remapping table 534 is a table associated with the IOMMU that includes a plurality of entries for storing identifiers (e.g., addresses, pointers, offsets, and / or other references) to locations in memory where information about interrupts is to be written for various entities in the electronic device 400. For example, in some embodiments, the interrupt remapping table 534 includes identifiers of locations in a virtual APIC backing page for a guest operating system in a corresponding guest portion of memory where interrupt information is to be written for one or more types of interrupts originating from the IOMMU. When an interrupt is signaled to a given guest operating system, the IOMMU performs a lookup in the interrupt remapping table to determine the location in the virtual APIC backing page in the corresponding guest portion of memory where information about the interrupt is to be written.

[0072] The guest interrupt log 536 is a table, buffer, and / or other structure used by the IOMMU (and possibly other entities) to store information about interrupts to the guest operating system. When an interrupt originating from the IOMMU to a given guest operating system cannot be communicated directly to the given guest operating system using the virtual APIC fallback page as described herein, the IOMMU writes information about the interrupt to the guest interrupt log 536 and signals to the hypervisor that the interrupt is waiting to be processed by the given guest operating system. The hypervisor then obtains information about the interrupt from the guest interrupt log 536 and interacts with the given guest operating system to enable the given guest operating system to process the interrupt.

[0073] In some embodiments, the guest operating system is configured or designed to support receiving interrupts from the IOMMU through the corresponding virtual APIC backup page as described herein. For example, the guest operating system may include program code, routines, methods and / or other mechanisms for receiving interrupts from the IOMMU from the IOMMU (while other guest operating systems may not include them). For another example, the guest operating system may include one or more software switches or control values ​​that configure the guest operating system to receive interrupts from the IOMMU from (or not from) the IOMMU. In these embodiments, each guest operating system is associated with one or more configuration indicators (e.g., bits, bytes, etc.) indicating whether the guest operating system can receive interrupts from the IOMMU through the corresponding virtual APIC backup page. For another example, the electronic device, the hypervisor and / or another entity in the electronic device may prohibit the direct communication of information about interrupts from the IOMMU to one or more (and possibly all) guest operating systems. When the IOMMU is unable to send an interrupt from the IOMMU to the guest operating system through the corresponding virtual APIC backup page for one or more of these reasons, the IOMMU uses the guest interrupt log 536 as described above to communicate the interrupt to a given guest operating system.

[0074] In some embodiments, some or all of the IOMMU backing store 500, guest memory 512, and hypervisor memory 530, and / or portions thereof, are not contiguous, but are stored in different areas or locations of memory. For example, the base address of the guest event log 514 (and therefore the guest event log itself) may be located far away in memory from the guest PPR log 516. As a result, the guest event log 514 may not be as accessible as the guest PPR log 516. Figure 5 Shown next to the visitor PPR log 516.

[0075] In some embodiments, the IOMMU includes a private address map that includes pointers, references, and / or other indications of the locations in memory of various data and information to be accessed by the IOMMU. For example, in some embodiments, the IOMMU private address map includes a pointer or reference to a starting point / base address of a separate copy of the IOMMU MMIO registers for the guest operating system and / or a copy set of IOMMU MMIO registers in the IOMMU backup storage area 500. In these embodiments, before accessing the data and information in the memory, the IOMMU performs a lookup in the private address map for the location of the data and information.

[0076] In some embodiments, the IOMMU backing store 500 and / or portions thereof (control bits, etc.) are accessible to or inaccessible to other entities in the electronic device 400 through the IOMMU (e.g., by sending requests to the IOMMU). For example, at least some data and information in the IOMMU backing store 500 may be accessed by other entities through writing to and reading from corresponding IOMMU MMIO registers.

[0077] IOMMU and guest operating system communication

[0078] In the described implementation, an IOMMU (eg, IOMMU 424) handles communications between the IOMMU (or the IO devices serviced thereby) and the guest operating system. Figure 7 A block diagram is presented that illustrates communications between a guest operating system 700 and an IOMMU 702 handled by the IOMMU 702 according to some embodiments. Figure 7 Although multiple elements are shown in a particular arrangement in FIG, other embodiments use different numbers or arrangements of elements. Generally, in the described embodiments, IOMMU 702 includes or accesses sufficient elements to implement the operations described herein. Figure 7 , many elements are shown as dotted / stippled; these elements are logs, buffers, etc. stored in memory (e.g., in IOMMU backing store 500, in guest memory 512, etc.) and accessed by IOMMU 702, guest operating system 700, and / or other entities using typical memory access techniques. In some embodiments, guest operating system 700, IOMMU 702, and hypervisor 704 are accessed in a manner similar to that of FIG. Figure 3 The guest operating system 302, IOMMU 312, and hypervisor 306 in FIG. 3 are organized in a similar manner, but this is not required.

[0079] As in Figure 72 for the prior art system, in the described embodiment, the IOMMU 702 and the guest operating system 700 communicate with each other more directly. In other words, the IOMMU 702 and the guest operating system 700 communicate with each other through the guest event log 514, the guest PPR log 516, the guest command buffer (BUFF) 518, and the virtual APIC backup page 520 in the memory (i.e., the guest portion of the memory used for the guest operating system 700 (e.g., the guest memory 428)). In addition, the guest operating system 700 and the IOMMU 702 use the guest control 508 and the guest MMIO 510 to specify how to perform communication. For example, in some embodiments, the IOMMU 702 uses a pointer in the guest MMIO 510 to determine the location of the guest event log 514, the guest command buffer 518, and the guest PPR log 516 for the guest operating system 700 in the memory. The IOMMU also uses an interrupt remapping table (e.g., interrupt remapping table 534) to determine the location in the virtual APIC backup page 520 in the memory where information about interrupts originating from the IOMMU is to be written. The hypervisor 704 does not intervene and is not otherwise involved in some or all operations for completing these communications. For example, the hypervisor 704 does not perform operations such as translating domain IDs and device IDs of these communications, accessing pointers in the guest MMIO 510, communicating interrupts specified to originate from the IOMMU to the guest operating system, and / or accessing buffers and logs in the guest portion of the memory. Instead, the IOMMU 702 performs these operations. Since the IOMMU 702 translates domain IDs and device IDs, accesses guest buffers and logs, communicates interrupts specified to originate from the IOMMU to the guest operating system, etc., the described embodiments avoid using the hypervisor 704 to handle at least a portion of the communication between the guest operating system 700 and the IOMMU 702, which can mean that the communication is completed faster, resulting in less load on the processor 402 and the memory 404, etc.

[0080] In operation, using commands as an example, the guest operating system 700 writes the invalidate_IOMMU_pages command to the guest command buffer 518. The command, when processed by the IOMMU 702, causes the IOMMU 702 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 information of the invalidate_IOMMU_pages command (i.e., bits representing the command). The guest operating system 700 then sends a write command to the IOMMU to update (e.g., advance, etc.) the command buffer tail pointer (e.g., command tail pointer 600) in the corresponding IOMMU MMIO register to indicate that the guest operating system 700 has written the command to the command buffer. The IOMMU 702 detects the guest operating system 700 writing to the command buffer tail pointer, such as by listening to a write to an 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 700, etc. Upon detecting a write of the command buffer tail pointer, the IOMMU 702 uses the value of the command buffer tail pointer to retrieve a command from the command buffer in the guest portion of memory and prepare the command for processing (e.g., replacing the host domain ID associated with the guest domain ID in the command, etc.). The IOMMU 702 then processes the command, causing the IOMMU 702 to invalidate a series of entries in the translation cache of the IOMMU 702 indicated by the host domain ID. The IOMMU 702 performs at least some similar operations for IOMMU 702 writes to the guest PPR log 516 and the guest event log 514, although in reverse, because the IOMMU 702 typically writes to these logs and the guest operating system 700 reads the logs.

[0081] In operation, the IOMMU 702 encounters or experiences a condition that results in an IOMMU-originated interrupt to be processed or handled by the guest operating system 700. The IOMMU 702 then performs a lookup in the interrupt remapping table to determine the location in the virtual APIC backing page 520 where information about the interrupt is to be written. Next, the IOMMU 702 writes the information about the interrupt to the location in the virtual APIC backing page 520 and communicates an indication of the interrupt to the guest operating system 700. The guest operating system 700 then retrieves the information about the interrupt from the location in the virtual APIC backing page 520 and uses the information about the interrupt to process or handle the interrupt.

[0082] In some embodiments, when the guest operating system 700 is unable to receive information about interrupts from the IOMMU 702 directly (i.e., through the virtual APIC backing page 520 as described herein), the IOMMU 702 communicates information about interrupts to the guest operating system 700 through the hypervisor 704 using the guest interrupt log 536. For example, the guest operating system 700 may not be able to receive interrupts from the IOMMU 702 through the virtual APIC backing page 520, or may be configured not to receive interrupts from the IOMMU 702 for security reasons, etc. In some embodiments, the IOMMU 702 preferentially communicates information about interrupts directly to the guest operating system 700 using the virtual APIC backing page 520, and only uses the guest interrupt log 536 / hypervisor 704 as a secondary / fallback option.

[0083] Although the hypervisor 704 does not participate in certain portions of the communication between the guest operating system 700 and the IOMMU 702 (e.g., translation of guest domain IDs to host domain IDs), the hypervisor 704 and the guest operating system 700 and / or the IOMMU 702 may separately exchange communications associated with the communication between the guest operating system 700 and the IOMMU 702, or the hypervisor 704 may otherwise participate in ensuring that the communication is properly handled by the guest operating system 700 and / or the IOMMU 702. As described above, the hypervisor 704 may also initialize or update the IOMMU backing store, interrupt remapping tables, etc.

[0084] The process used to signal interrupts from the IOMMU to the guest operating system

[0085] In the described embodiments, the IOMMU (e.g., IOMMU 702) performs operations for signaling interrupts to a guest operating system (e.g., guest operating system 700). For example, in some embodiments, the IOMMU signals the guest operating system an interrupt originating from the IOMMU (such as an interrupt generated in the IOMMU or based on an interrupt from an IO device). The IOMMU signals the interrupt "directly" to the guest operating system because the IOMMU itself writes information about the interrupt to a designated location in a virtual APIC backing page in the memory portion of each guest operating system using typical memory access operations—without the need for the hypervisor to participate in or handle memory access operations. The IOMMU then communicates an indication of the interrupt to the guest operating system in order to cause the guest operating system to process or handle the interrupt. Figure 8 A flowchart is presented showing a process during which an IOMMU signals an interrupt to a guest operating system according to some embodiments. Note that Figure 8The operations shown are presented as general examples of operations performed by some embodiments. The operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0086] Figure 8 The operations in 800 begin when the IOMMU generates information about an interrupt (step 800). For this operation, the IOMMU generates information about the interrupt internally by detecting a specified event, error, etc. in the IOMMU and creating corresponding information, or generates information about the interrupt by receiving an indication of the interrupt, event, error, etc. from an IO device (or other entity) and creating corresponding information about the interrupt. For example, the IOMMU itself may write data to a buffer or log associated with the guest operating system, and then generate information about the interrupt, which will be communicated to the guest operating system to inform the guest operating system that the data in the buffer or log is to be processed or disposed.

[0087] The specific format of the information about the interrupt generated by the IOMMU depends on the format of the interrupt itself, the configuration of the guest operating system, etc. For example, in some embodiments, the information about the interrupt includes specified information and / or is formatted according to the Information Signaled Interrupt (MSI) standard or protocol. Typically, the information includes at least an identification or representation of the interrupt, and may include other characteristics and / or features of the interrupt, the IOMMU, the IO device, the event or error that caused the interrupt, etc.

[0088] The IOMMU then obtains the location of a virtual APIC backup page for the guest operating system in the guest portion of memory from the entry in the interrupt remapping table associated with the guest operating system (step 802). It should be recalled that the virtual APIC backup page is a portion of memory used to store information about interrupts to be handled by the guest operating system and to otherwise virtualize / emulate the APIC in the electronic device 400. The virtual APIC backup page includes one or more locations (e.g., entries, portions, etc.) for storing information about interrupts originating from the IOMMU for processing or disposal by the guest operating system. For the operations in step 802, in some embodiments, the IOMMU uses a guest operating system identifier (ID) (such as a system device identifier) ​​assigned to the guest operating system at initialization (e.g., by system hardware, operating system, etc.) to perform a lookup in the interrupt remapping table. Fig. 9 A block diagram illustrating a lookup in an interrupt remap table according to some embodiments is presented. Fig. 9The specific arrangement of the interrupt remapping table and operations is shown, but in some embodiments, other arrangements of the remapping table and / or operations are used. Generally, in the described embodiments, the IOMMU uses the interrupt remapping table to determine the location in the virtual APIC backup page for the guest operating system where information about the interrupt is to be written.

[0089] For Fig. 9 In the illustrated embodiment, the interrupt remapping table is partitioned into a hierarchical structure of sub-tables including a LEVEL-1 interrupt remapping table 906 and an interrupt remapping table 908. Partitioning the interrupt remapping table into a hierarchical structure of sub-tables enables more efficient searching of the interrupt remapping table, storing it in memory, operating on it, etc. Although this arrangement of the interrupt remapping table is presented as an example, in some embodiments, the interrupt remapping table includes more sub-tables or is implemented as a single table. Generally, the interrupt remapping table includes sufficient information to implement the operations described herein.

[0090] For lookups in the interrupt remapping table, the IOMMU uses the first part of the guest operating system identifier 900 (e.g., the first N bits of the M-bit guest operating system identifier 900, where N < M) and the interrupt table root pointer 904 obtained from the device table entry 902 for the IOMMU to determine a specific entry in the LEVEL-1 interrupt table 906. The entries in the LEVEL-1 interrupt table 906 store the root / base pointers for the interrupt remapping table 908. The IOMMU uses the root / base pointer and the second part of the guest operating system identifier 900 (e.g., as an offset or reference) to determine an entry in the interrupt remapping table 908. From the entry in the interrupt remapping table 908, the IOMMU retrieves the identifier (e.g., address, offset, etc.) of the location in the virtual APIC backup page 910 where information about the interrupt is to be stored.

[0091] In some embodiments, the IOMMU is capable of communicating information about two or more different types of interrupts to the guest operating system. For example, in some embodiments, the interrupt types include event notification interrupts, peripheral page request interrupts, fault or error interrupts, etc. In these embodiments, the virtual APIC backup page for each guest operating system includes two or more locations for interrupts originating from the IOMMU, each location for storing information about one or more different types of interrupts. For the lookups in the above-described interrupt remapping table, in addition to the guest operating system identifier, the IOMMU may also use a type indicator (e.g., one or more bits, etc.) to access the corresponding entry in the remapping table for a given interrupt type.

[0092] Back to Figure 8, after obtaining the location in the virtual APIC backup page (step 802), the IOMMU writes information about the interrupt to the location in the virtual APIC backup page (step 804). For this operation, the IOMMU writes at least an identifier of the interrupt to the location in the virtual APIC backup page, and may write additional information about one or more characteristics or features of the interrupt, IOMMU and / or IO device, etc. For example, in some embodiments, the location in the virtual APIC backup page includes only a single bit, which is set to indicate that an interrupt has occurred, and therefore the guest operating system should handle or handle the interrupt, for example, by executing a specified interrupt handling program code, performing one or more operations, etc. For example, in some embodiments, the location in the virtual APIC backup page includes multiple bits or bytes, which can be used to store information identifying the interrupt and other information about the characteristics or features of the interrupt. In these embodiments, the guest operating system will retrieve information about the interrupt from the virtual APIC backup page and use the information about the interrupt to handle or handle the interrupt.

[0093] Next, the IOMMU communicates the indication of the interrupt to the guest operating system (step 806). For this operation, the IOMMU notifies the guest operating system that the interrupt is waiting to be processed or disposed, that is, the information about the interrupt is present in the location in the virtual APIC backup page for the guest operating system. For example, in some embodiments, when the guest operating system is "active", that is, when the program code of the guest operating system is currently being executed by a processor core (e.g., core 418) in the electronic device (and the guest operating system system is not suspended or otherwise not being executed in favor of other program codes), communicating the interrupt includes sending a corresponding signal from the IOMMU to the executing processor core. For example, sending a signal may include one or more of the following: writing to a shared mailbox memory location, asserting a signal on a specified signal line, sending a data packet to the processor core on a communication bus, etc. As another example, in some embodiments, when the guest operating system is "inactive," i.e., when the program code of the guest operating system is not currently being executed by the processor core (and the guest operating system is suspended or otherwise not being executed in support of other program code), communicating the interrupt includes adding an entry to the guest virtual APIC log, which is a record of pending interrupts to be processed or handled by the guest operating system. The IOMMU then sends an indication to the processor via a shared mailbox memory location to add the entry to the guest virtual APIC log, assert a signal on a specified signal line, etc. The hypervisor then triggers the guest operating system to process or handle the interrupt from the virtual APIC backing page when the guest operating system is reactivated—and the guest operating system may be reactivated specifically to process or handle the interrupt.

[0094] Then, the guest operating system obtains information about the interrupt from the location in the virtual APIC backup page (step 808) and uses the information about the interrupt to process or handle the interrupt (step 810). For this operation, the guest operating system retrieves information from the location in the virtual APIC backup page through one or more memory reads. Then, the guest operating system processes or handles the interrupt by executing interrupt handling program code, performing corresponding operations, terminating one or more operations, notifying the processor core executing the guest operating system of the occurrence of the interrupt, and communicating the occurrence of the interrupt to the hypervisor or operating system with a signal, etc.

[0095] Interrupts not communicated directly from the IOMMU to the guest OS

[0096] As described above, the IOMMU uses a virtual APIC fallback page for the guest operating system to directly signal the interrupt originating from the IOMMU to the guest operating system (i.e., without the need for a hypervisor to assist in writing the virtual APIC fallback page, etc.). However, in some cases, it is not allowed to directly communicate the interrupt originating from the IOMMU to the guest operating system from the IOMMU. For example, for security reasons, efficiency, etc., the guest operating system may be configured (e.g., using a software switch, a configuration value, etc.) not to directly accept the interrupt originating from the IOMMU from the IOMMU. In such cases, the IOMMU uses a different mechanism to signal the interrupt originating from the IOMMU to the guest operating system. For example, in some embodiments, when the IOMMU cannot directly communicate the interrupt originating from the IOMMU to the guest operating system, the IOMMU uses an intermediate interrupt communication mechanism to indirectly signal the interrupt originating from the IOMMU to the guest operating system through an intermediate entity.

[0097] In some embodiments, the intermediate entity that the IOMMU uses to communicate interrupts to the guest operating system with signals is or includes a guest interrupt log. The guest interrupt log is a table, buffer, etc. in which information about interrupts is stored for the guest operating system to be finally processed with the assistance of the hypervisor (and / or other entities). During operation, after determining that a given guest operating system cannot directly accept interrupts from the IOMMU from the IOMMU, the IOMMU writes information about the interrupts to the guest interrupt log for the given guest operating system. The IOMMU then signals the hypervisor that the information has been written to the guest interrupt log and / or the hypervisor detects the writing of the guest interrupt log, which causes the hypervisor to forward or otherwise communicate the interrupt to the guest operating system (e.g., by writing the interrupt to the virtual APIC backup page for the guest operating system). The given guest operating system then handles the interrupt.

[0098] In some embodiments, the electronic device (e.g., electronic device 400 and / or a portion thereof) uses code and / or data stored on a non-transitory computer-readable storage medium to perform some or all of the operations described herein. More specifically, when performing the described operations, the electronic device reads code and / or data from a computer-readable storage medium and executes the code and / or uses the data. A computer-readable storage medium can be any device, medium, or combination thereof that stores code and / or data for use by an electronic device. For example, a computer-readable storage medium may 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.).

[0099] In some embodiments, one or more hardware modules perform the operations described herein. For example, a hardware module may include, but is not limited to, one or more processors / cores / central processing units (CPUs), application specific integrated circuits (ASIC) chips, neural network processors or accelerators, field programmable gate arrays (FPGAs), computing units, embedded processors, graphics processors (GPUs) / graphic cores, pipelines, accelerated processing units (APUs), caches / cache controllers, memory / 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, a hardware module includes one or more general-purpose circuits, which are configured by executing instructions (program code, firmware, etc.) to perform operations.

[0100] In some embodiments, a data structure representing some or all of the structures and mechanisms described herein (e.g., electronic device 400, IOMMU 424, and / or a portion thereof) is stored on a non-transitory computer-readable storage medium, the data structure including a database or other data structure that can be read by an electronic device and used directly or indirectly to manufacture hardware including the structures and mechanisms. For example, the data structure can be a behavioral level description or a register transfer level (RTL) description of the hardware functionality in a high-level design language (HDL) (e.g., Verilog or VHDL). The description can be read by a synthesis tool, which can synthesize the description to generate a netlist, which includes a list of gate / circuit elements from a synthesis library, the list representing the functionality of the hardware including the above-mentioned structures and mechanisms. The netlist can then be placed and routed to generate a data set describing the geometry to be applied to the 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-mentioned structures and mechanisms. Alternatively, the database on the computer accessible storage medium may be a netlist (with or without a synthesis library) or a data set (as desired), or Graphic Data System (GDS) II data.

[0101] In this specification, variables or unspecified values ​​(i.e., general descriptions of values ​​without specific examples of values) are represented by letters such as N. As used herein, although similar letters may be used in different places in this specification, the variables and unspecified values ​​are not necessarily the same in each case, and there may be different amounts and values ​​of variables intended for some or all of the general variables and unspecified values. In other words, in this specification, N and any other letters used to represent variables and unspecified values ​​are not necessarily related to each other.

[0102] As used herein, the expression "etcetera" or "etc." is intended to present one and / or circumstances, i.e., the equivalent of "at least one" of the elements in the list associated with etc. For example, in the sentence "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 the other operation. Furthermore, the elements in the list associated with etc. are merely examples in an example set—and at least some of the examples may not appear in some embodiments.

[0103] The foregoing description of the embodiments is given for the purpose of illustration and description only. The foregoing description is not intended to be exhaustive or to limit the embodiments to the disclosed forms. Therefore, many modifications and variations will be apparent to practitioners in the art. In addition, 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, comprising: a processor, the processor executing a guest operating system; a memory having a guest portion reserved for storing data and information to be accessed by the guest operating system; as well as An input-output memory management unit IOMMU, the IOMMU being configured to: Interrupts are signaled to the guest operating system by: obtaining a location in a virtual advanced programmable interrupt controller APIC fallback page for the guest operating system in the guest portion of the memory from an entry in an interrupt remapping table associated with the guest operating system; Writing information about the interrupt into the location in the backup page of the virtual advanced programmable interrupt controller APIC; as well as An indication of the interrupt is communicated to the guest operating system.

2. The electronic device according to claim 1, wherein: When obtaining the location in the virtual APIC fallback page from the entry in the interrupt remapping table, the IOMMU is configured to: Obtaining a base address of the interrupt remapping table from a device table entry associated with the IOMMU; determining the entry in the interrupt remap table using the base address and a guest operating system identifier (ID); and The address of the location in the virtual APIC backing page is retrieved from the entry in the interrupt remap table.

3. The electronic device as claimed in claim 2, wherein: The virtual APIC backing page in the guest portion of the memory includes a plurality of locations, each location among the plurality of locations being associated with a different type of interrupt, and the interrupt remap table includes a separate entry for storing an indicator for each of the plurality of locations; and When obtaining the location in the virtual APIC fallback page from the interrupt remapping table entry, the IOMMU is configured to: The type of the interrupt is used along with the base address and the guest operating system ID to determine the entry in the interrupt remap table.

4. The electronic device as claimed in claim 2, wherein: The interrupt remapping table includes a hierarchy of at least two sub-tables, each sub-table except a final sub-table in the hierarchy of sub-tables includes an identifier of a next sub-table in the hierarchy, and the final sub-table includes the address of the location in the virtual APIC backup page; and When using the base address and the guest operating system ID to determine the entry in the interrupt remap table, the IOMMU is configured to traverse the hierarchy of sub-tables to the final sub-table using corresponding portions of the base address and / or the guest operating system ID.

5. The electronic device of claim 1 , wherein the IOMMU is further configured to: determining whether to allow the interrupt to be communicated directly from the IOMMU to the guest operating system; and When direct communication of the interrupt is permitted, signaling the interrupt to the guest operating system; and When direct communication of the interrupt is not permitted, the interrupt is indirectly signaled to the guest operating system using one or more intermediate interrupt communication mechanisms.

6. The electronic device as claimed in claim 5, wherein: When determining whether to allow direct communication of the interrupt, the IOMMU is configured to: One or more settings in a device table entry associated with the IOMMU are examined to determine: Whether IOMMU interrupt propagation is enabled; and / or Whether the guest operating system is configured to receive interrupts from the IOMMU.

7. The electronic device of claim 5, wherein the one or more intermediate interrupt communication mechanisms include a guest interrupt log, and the IOMMU is further configured to: storing information about the interruption in the visitor interruption log; Wherein a hypervisor executed by the processor detects or is notified of the IOMMU to store the information about the interrupt in the guest interrupt log and indicate the interrupt to the guest operating system.

8. An electronic device as described in claim 1, wherein the processor executes a hypervisor that initializes and maintains the interrupt remapping table by storing an identifier of a location in a virtual APIC backup page for a guest operating system in a corresponding guest portion of the memory in a corresponding entry in the interrupt remapping table.

9. The electronic device of claim 1 , wherein communicating the indication of the interrupt to the guest operating system comprises: When the guest operating system is currently active: An interrupt is signaled to the processor.

10. The electronic device of claim 1, wherein communicating the indication of the interrupt to the guest operating system comprises: When the guest operating system is not currently active: Add entries to the guest virtual APIC log; as well as An indication is sent to the processor to add the entry to the guest virtual APIC log.

11. The electronic device according to claim 1, wherein: Based on the indication of receiving the interrupt on behalf of the guest operating system, the processor is configured to handle the interrupt for the guest operating system by: Retrieving the information about the interrupt from the location in the virtual APIC backup page; and The interruption is processed or handled using the information about the interruption.

12. The electronic device of claim 1, wherein the interrupt is an interrupt originating from an IOMMU.

13. A method for signaling an interrupt in an electronic device, the electronic device comprising: a processor, the processor executing a guest operating system; a memory having a guest portion reserved for storing data and information to be accessed by the guest operating system; and an input-output memory management unit IOMMU, the method comprising: The IOMMU communicates interrupt signals to the guest operating system in the following manner: Obtaining, by the IOMMU, a location in a virtual advanced programmable interrupt controller APIC backup page for the guest operating system in the guest portion of the memory from an entry in an interrupt remapping table associated with the guest operating system; Writing, by the IOMMU, information about the interrupt to the location in the virtual advanced programmable interrupt controller APIC backup page; and An indication of the interrupt is communicated by the IOMMU to the guest operating system.

14. The method of claim 13, wherein obtaining the location in the virtual APIC backup page from the entry in the interrupt remapping table comprises: Obtaining, by the IOMMU, a base address of the interrupt remapping table from a device table entry associated with the IOMMU; determining, by the IOMMU, the entry in the interrupt remapping table using the base address and a guest operating system identifier (ID); as well as The address of the location in the virtual APIC fallback page is retrieved by the IOMMU from the entry in the interrupt remap table.

15. The method of claim 14, wherein: the virtual APIC backing page in the guest portion of the memory comprising a plurality of locations, each location among the plurality of locations being associated with a different type of interrupt, and the interrupt remap table comprising a separate entry for storing an indicator for each of the plurality of locations; and Acquiring the location in the virtual APIC backup page from the interrupt remapping table entry comprises: The type of the interrupt is used by the IOMMU along with the base address and the guest operating system ID to determine the entry in the interrupt remapping table.

16. The method of claim 14, wherein: The interrupt remapping table includes a hierarchy of at least two sub-tables, each sub-table except a final sub-table in the hierarchy of sub-tables includes an identifier of a next sub-table in the hierarchy, and the final sub-table includes the address of the location in the virtual APIC backup page; and Using the base address and the guest operating system ID to determine the entry in the interrupt remapping table includes: The base address and / or corresponding portions of the guest operating system ID are used by the IOMMU to traverse the hierarchy of sub-tables to the final sub-table.

17. The method of claim 13, further comprising: determining, by the IOMMU, whether to allow the interrupt to be communicated directly from the IOMMU to the guest operating system; as well as When direct communication of the interrupt is permitted, signaling the interrupt to the guest operating system by the IOMMU; and When direct communication of the interrupt is not permitted, the interrupt is indirectly signaled to the guest operating system by the IOMMU using one or more intermediate interrupt communication mechanisms.

18. The method of claim 17, wherein determining whether to allow direct communication of the interruption comprises: One or more settings in a device table entry associated with the IOMMU are examined by the IOMMU to determine: Whether IOMMU interrupt communication is enabled; and / or Whether the guest operating system is configured to receive interrupts from the IOMMU.

19. The method of claim 17, wherein the one or more intermediate outage communication mechanisms include a visitor outage log, and the method further comprises: storing, by the IOMMU, information about the interrupt in the guest interrupt log; Wherein a hypervisor executed by the processor detects or is notified of the IOMMU to store the information about the interrupt in the guest interrupt log and indicate the interrupt to the guest operating system.

20. The method of claim 13, wherein the processor executes a hypervisor, and the method further comprises: The interrupt remapping table is initialized and maintained by the hypervisor by storing an identifier of a location in a virtual APIC backing page for a guest operating system in a corresponding guest portion of the memory in a corresponding entry in the interrupt remapping table.

21. The method of claim 13, wherein communicating the indication of the interrupt to the guest operating system comprises: When the guest operating system is currently active: The IOMMU transmits an interrupt signal to the processor.

22. The method of claim 13, wherein communicating the indication of the interrupt to the guest operating system comprises: When the guest operating system is not currently active: An entry is added by the IOMMU to the guest virtual APIC log; as well as An indication is sent by the IOMMU to the processor to add the entry to the guest virtual APIC log.

23. The method of claim 13, wherein: Based on the indication of receiving the interrupt on behalf of the guest operating system, the processor is configured to handle the interrupt for the guest operating system by: Retrieving the information about the interrupt from the location in the virtual APIC backup page; and The interruption is processed or handled using the information about the interruption.

24. The method of claim 13, wherein the interrupt is an interrupt originating from an IOMMU.

Images