Provision of Interrupts from the Input / Output Memory Management Unit to the Guest Operating System

Abstract

The electronic device includes a processor that executes a guest operating system, a memory having a guest portion reserved for storing data and information accessed by the guest operating system, and an input / output memory management unit (IOMMU). The IOMMU performs operations to notify the guest operating system of an interrupt. For these operations, the IOMMU obtains the location of the guest operating system's virtual Advanced Programmable Interrupt Controller (APIC) backing page in the guest portion of 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 of the virtual APIC backing page. The IOMMU then communicates an indication of the interrupt to the guest operating system.

Description

Background Art

[0001] (Related Art) Some electronic devices (e.g., servers, desktop computers, etc.) support “virtualization” of electronic device hardware such as input / output (IO) devices. Virtualization gives the illusion to an instance of software (e.g., an application program, etc.) running on or within an electronic device that the instance of software can directly access the electronic device hardware, but in reality, it involves an intermediate entity intercepting / redirecting or otherwise assisting the accesses made by the instance of software. For example, one common intermediate entity is a “virtual machine”. A virtual machine is a software entity that abstracts the electronic device hardware and emulates or presents a known interface to the electronic device hardware, thereby enabling an instance of software to run on various types and configurations of electronic device hardware (which may include electronic device hardware with which the instance of software is not compatible). In some electronic devices, the virtual machine supports the execution of one or more instances of an operating system called a “guest” operating system. On the other hand, the guest operating system provides an environment for running other instances of software such as productivity applications, databases, etc.

[0002] In some electronic devices, virtual machines are managed and controlled by a software entity known as a hypervisor. The hypervisor can start or initialize a virtual machine, control, monitor, and assist the virtual machine in accessing the electronic device hardware, end or close the virtual machine, and so on. FIG. 1 is a block diagram showing a virtual machine and a hypervisor. As seen in FIG. 1, there are three virtual machines (VMs) 100, under each of which one or more programs (PRGRMS) 104 such as a guest operating system (guest OS) 102, a database, and software applications are executed. The virtual machines 100 communicate with the hypervisor 106, and the hypervisor 106 interfaces between the host operating system (host OS) 108 and the virtual machines 100. The host operating system 108 provides an interface between the electronic device hardware 110 and the hypervisor 106. Further, the hypervisor 106 interfaces between the virtual machines 100 and the input / output memory management unit (IOMMU) 112, and the IOMMU 112 functions as a controller for the memory management unit and the I / O device hardware 114.

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

[0004] FIG. 2 is a block diagram showing communication between a guest operating system and an IOMMU processed by a hypervisor. In FIG. 2, some elements are shown in dotted / dashed lines, and these elements are logs, buffers, etc. stored in a memory (e.g., the main memory of an electronic device), and thus are accessed via typical memory access techniques. The elements in FIG. 2 include a guest peripheral page request (PPR) log 200, a guest command buffer (CMD BUF) 202, and a guest event log 204 together with a guest operating system 102, a hypervisor 106, and an IOMMU 112, and these are structures (e.g., lists, tables, etc.) in the memory used to store data and information for the guest operating system 102 and other entities of the electronic device. Further, the elements include a guest pointer (PTRS) / status register (REGS) 206, which is a set of positions in the memory for storing pointers to guest operating system structures and status information related to the guest operating system. Further, the elements include an IOMMU peripheral page request (PPR) log 208, an IOMMU command buffer 210, and an IOMMU event log 212, and these are structures (e.g., lists, tables, etc.) in the memory used to store communications from and to the IOMMU 112. Also, the elements include an IOMMU memory mapped input / output (MMIO) pointer / status register (REGS) 214 in the IOMMU 112, which is a set of registers in the IOMMU 112 for storing pointers to various IOMMU 112 structures and status information related to the IOMMU 112. Further, the elements include a virtual advanced programmable interrupt controller (APIC) backing page 216 and a guest interrupt log 218, and these are structures used to communicate information regarding IOMMU source interrupts from the IOMMU to the guest operating system via the hypervisor 106.

[0005] During operation, using commands as an example, the guest operating system 102 writes commands destined for the IOMMU 112 to the guest command buffer 202 (i.e., to the next available position in the buffer in the memory where commands from the guest operating system 102 are stored). The hypervisor 106 detects the writing to the guest command buffer 202 of the guest operating system as shown by the dotted line in FIG. 2, acquires and processes the commands (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 commands in the IOMMU command buffer 210. Also, the hypervisor 106 updates the tail pointer in the IOMMU MMIO pointer / status register 214 of the IOMMU command buffer 210 to indicate the newly written command (e.g., increments the tail pointer to the next position in the IOMMU command buffer 210). Next, the IOMMU 112 acquires commands from the IOMMU command buffer 210 using the tail pointer (and / or other pointers) and executes the commands. Thereby, the IOMMU 112 executes the corresponding actions. The hypervisor 106 performs similar operations for the writing of the IOMMU 112 to the IOMMU peripheral page request log 208 and the IOMMU event log 212 (e.g., replaces the host device ID with the guest device ID, etc.). The reading and writing of memory, the update of pointers, and other operations performed by the hypervisor 106 have a longer latency. For this reason, intervening the hypervisor 106 between the guest operating system 102 and the IOMMU 112 for use leads to a delay in processing communication, causes the processor to be in a busy state, and increases the traffic on the memory bus within the electronic device.

[0006] During operation, the IOMMU 112 indirectly communicates IOMMU source interrupts, such as interrupts based on events, faults, or errors, to the guest operating system 102. More specifically, the IOMMU 112 communicates the interrupts to the guest operating system 102 via the hypervisor 106 and does not communicate the interrupts directly to the guest operating system 102. To communicate an interrupt to the guest operating system 102, the IOMMU 112 notifies the hypervisor 106 of the interrupt. Next, the hypervisor 106 writes information about the interrupt to the virtual APIC backing page 216 and notifies the guest operating system 102 of the occurrence of the interrupt. 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 either assert a doorbell signal or write to a shared memory location to notify the guest operating system 102 of the occurrence of the interrupt. Upon receiving the notification from the hypervisor 106, the guest operating system 102 retrieves 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., switched out while another guest operating system is being executed) when an interrupt occurs. In this case, the hypervisor 106 adds information about the interrupt to the guest interrupt log 218, and this information is used to process the interrupt when the guest operating system 102 returns to an active state. As with other types of communication, relying on the hypervisor 106 as an interface for interrupt processing leads to increased processing time for interrupts and increased memory bus traffic.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

[0008] Throughout the drawings and the description, like reference numerals refer to the same drawing elements.

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

[0010] (Terminology) In the following description, various terms are used to describe embodiments. The following is a simplified general description of these terms. It should be noted that these terms may have important additional features not described in this specification in order to be clear and concise, and thus this description is not intended to limit the terms.

[0011] Functional block: A functional block refers to a group, set, and / or collection of one or more circuit elements that are related to each other, such as integrated circuit elements, discrete circuit elements, etc. Circuit elements are "related to each other" in that the circuit elements share at least one characteristic. For example, the circuit elements that are related to each other can be included in a specific integrated circuit chip or a part thereof, assembled thereon, or otherwise coupled, and can be involved in the performance of a predetermined function (such as a computing or processing function, a memory function, etc.) and can be controlled by a common control element and / or a common clock, etc. A functional block can include any number of circuit elements ranging from a single circuit element (e.g., a single integrated circuit logic gate) to millions or billions of circuit elements (e.g., an integrated circuit memory).

[0012] (Virtualization, Virtual Machines, and Hypervisors) The described embodiments support "virtualization" of electronic device hardware such as memory, input / output (IO) devices, etc. Virtualization generally gives the illusion to instances of software running on an electronic device that the instances of software can directly access the electronic device hardware, when in fact, it involves an intermediate entity intercepting / redirecting or otherwise assisting the accesses made by the instances of software. For example, an instance of software may be presented with a set of electronic device registers, memory locations, electronic device settings, and other functional blocks that appear to the instance of software as the actual device registers, memory locations, etc. of the electronic device but are merely copies presented by the intermediate entity. In this case, the intermediate entity receives, intercepts (sniffs), or otherwise obtains access to the copy of the electronic device hardware and performs the corresponding interaction with the actual electronic device hardware on behalf of the instance of software. Virtualization of electronic device hardware enables various electronic devices to use various configurations of electronic device hardware, various levels, positions, or identifiers, etc. of the electronic device hardware, and has many advantages such as an instance of software being presented via an intermediate entity using the same interface to the electronic device hardware. Further, the intermediate entity can determine whether to permit or block access to the electronic device hardware by a given instance of software, and thus, virtualization of the electronic device hardware enables protection of the electronic device hardware (or a part thereof) and / or an instance of software running on the electronic device. By controlling access as described above, the intermediate entity can share the electronic device hardware among some instances of software and / or provide exclusive access to a part of the electronic device hardware to an individual instance of software.

[0013] In the described embodiments, the intermediate entity includes a "virtual machine". A virtual machine is a software entity that abstracts electronic device hardware and presents a known interface to software instances to actual or emulated electronic device hardware. By abstracting the hardware, software instances are enabled to execute on various types and configurations of electronic device hardware (which may include electronic device hardware with which the software instances are not compatible). In the described embodiments, the virtual machine supports the execution of one or more instances of an operating system, called a "guest" operating system. The guest operating system provides an environment for executing other software programs such as applications, databases, etc.

[0014] In the described embodiment, the virtual machine is managed and controlled by a software entity known as a hypervisor. The hypervisor can start or initialize the virtual machine, initialize data structures, tables, etc. used by the virtual machine or the guest operating system, control, monitor, and assist the access of the virtual machine to the electronic device hardware, end or close the virtual machine, and so on. FIG. 3 is a block diagram showing a virtual machine and a hypervisor according to some embodiments. As seen in FIG. 3, 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 and software applications are executed. The virtual machine 300 communicates with the hypervisor 306, and the hypervisor 306 interfaces between the host operating system (host OS) 308 and the virtual machine 300. The host operating system 308 provides an interface between the electronic device hardware 310 and the hypervisor 306. Different from that shown in FIG. 1 for existing electronic devices, in FIG. 3, the IOMMU 312 directly interfaces between the guest operating system 302 and the IO device hardware 314 without the intervention of the hypervisor 306 (as shown by the thick line between the IOMMU 312 and the guest operating system 302). Thus, different from existing electronic devices, in the described embodiment, the hypervisor 306 is not involved in the execution of at least a part of the operations for processing the communication between the guest operating system 302 and the IOMMU 312 as described herein. However, note that specific communication occurs 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, there is no host operating system 308 and the hypervisor 306 communicates more directly with the electronic device hardware 310.

[0015] (Overview) In the described embodiments, the electronic device includes a processor, a memory (e.g., main memory), several input / output (IO) devices (e.g., network interface devices, disk controllers, etc.), and an input / output memory management unit (IOMMU) that interfaces between the processor and the IO devices. The processor executes a hypervisor, one or more virtual machines, and guest operating systems in the virtual machines. Each guest operating system is allocated a guest portion of memory (a contiguous or non-contiguous region or block of memory) reserved for storing data and information accessed by that guest operating system. In the described embodiments, the IOMMU performs operations for handling communication between the guest operating system and the IOMMU.

[0016] In some embodiments, as part of the operations for handling communication between the guest operating system and the IOMMU, the IOMMU directly communicates information regarding interrupts to the guest operating system. In other words, the IOMMU performs operations to notify the guest operating system that an IOMMU source interrupt, which may be generated by the IOMMU itself or based on the activities of IO devices or other entities, is pending for processing by the guest operating system. When the guest operating system receives information regarding an interrupt from the IOMMU, the guest operating system performs operations for processing the IOMMU source interrupt. As used herein, "directly" communicating information regarding an IOMMU source interrupt from the IOMMU to the guest operating system means that the operations for communicating the interrupt-related information are performed without the involvement of the hypervisor that activates / runs the guest operating system. However, the hypervisor may handle part of the operations for communicating information regarding IOMMU source interrupts to an inactive operating system.

[0017] In some embodiments, the IOMMU communicates information regarding IOMMU source interrupts to the guest operating system via each virtual advanced programmable interrupt controller (APIC) backing page of the guest portion of memory. Generally, each virtual APIC backing page is a portion of memory (e.g., memory of one or more 4 kB pages) used to virtualize the APIC functional block in an electronic device of the corresponding guest operating system. The virtual APIC backing page includes several locations (e.g., entries, portions, etc.) used by the hypervisor or other entities to emulate the registers, memory locations, control values, etc. of the APIC functional block to enable the guest operating system to receive and process interrupts. Information regarding APIC, virtualization of APIC, and virtual APIC backing pages is described, for example, in AMD64 Architecture Programmer’s Manual Volume 2: System Programming, rev. 3.30, September 2018, which is hereby incorporated by reference in its entirety. In some embodiments, the virtual APIC backing page of each guest operating system includes one or more locations dedicated to storing information regarding a specified IOMMU source interrupt in addition to known interrupt control and communication locations. For example, in some embodiments, the virtual APIC backing page of each guest operating system includes separate locations (e.g., entries, portions, etc.) for each different type of IOMMU source interrupt that can be processed by that guest operating system. In another example, in some embodiments, the virtual APIC backing page of each guest operating system includes a single combined location for all different types of IOMMU source interrupts that can be processed by that guest operating system.

[0018] In some embodiments, the IOMMU uses an interrupt remapping table to determine the location within the virtual APIC backing page where information regarding an interrupt is written to notify the guest operating system of the interrupt. Generally, the interrupt remapping table is a table stored in memory that includes several entries, and each entry is used to store an identifier (e.g., an address, an offset, etc.) of a location in memory where information regarding a specified interrupt is written. The interrupt remapping table is described, for example, in the AMD I / O Virtualization Technology (IOMMU) Specification, rev. 3.00 of December 2016, and is incorporated herein by reference as described above. In these embodiments, in addition to the known entries in the interrupt remapping table, the interrupt remapping table includes entries for storing the identifiers of the above locations within the virtual APIC backing page of each guest operating system.

[0019] In some embodiments, during operation, when the IOMMU encounters an IOMMU source interrupt destined for a particular guest operating system, the IOMMU obtains, from the interrupt remapping table, an identifier of the location within the virtual APIC backing page of the particular guest operating system where information about the interrupt is to be written. The IOMMU then uses the identifier to write the information about the interrupt to the location in the virtual APIC backing page of the particular guest operating system. Also, the IOMMU transmits an indication of the interrupt to the particular guest operating system. Based on this indication, the particular guest operating system obtains the information about the interrupt from the location in the virtual APIC backing page and processes or handles the interrupt. In some embodiments, the mechanism used to transmit the indication of the interrupt to a given guest operating system depends on the active / inactive state of the guest operating system, i.e., whether the processor is currently executing the given guest operating system or has temporarily deactivated the given guest operating system to execute another task. The mechanism will be described in detail below.

[0020] The embodiments described, where the IOMMU writes information about the IOMMU source interrupt to the virtual APIC backing page of the guest operating system and transmits an indication of the interrupt to the guest operating system, thereby directly communicating the interrupt to the guest operating system, avoid the need to rely on the hypervisor for the processing of IOMMU source interrupts as seen in existing systems. By moving these operations from the hypervisor (implemented in software) to the IOMMU (implemented in hardware), the operations are accelerated, the required memory system bandwidth is reduced, the load on the computing functional blocks within the processor is reduced, and the overall performance of the electronic device is improved. The improvement in the performance of the electronic device leads to increased user satisfaction.

[0021] (Electronic device) Figure 4 is a block diagram showing an electronic device 400 according to some embodiments. As seen in Figure 4, the electronic device 400 includes a processor 402, a memory 404, a mass storage device 406, input / output (IO) devices 408 - 412, an input / output (IO) hub 414, and a memory controller 416.

[0022] The processor 402 is a functional block that executes 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. Further, the processor 402 includes a memory management unit (MMU) 422, which is a functional block that executes operations related to address translation (e.g., page table walk, translation lookaside buffer lookup, etc.) and memory access protection for memory access by cores 418 - 420. Additionally, the processor 402 includes an advanced programmable interrupt controller (APIC) 430, which is a functional block that executes operations related to interrupt processing in the processor 402. Since the APIC is known in the art, a detailed description thereof is omitted. In some embodiments, the APIC 430 is virtualized for guest operating systems and emulated functions as known in the art or as described herein.

[0023] Memory 404 is a functional block that executes the operations of the memory (e.g., the "main" memory) within the electronic device 400. Memory 404 includes one or more memory circuits among dynamic random access memory (DRAM), double data rate synchronous DRAM (DDR SDRAM), and / or other types of memory circuits that store data and instructions used by other functional blocks within the electronic device 400, and a control circuit that processes access (e.g., read, write, check, delete, invalidate, etc.) to the data and instructions stored in the memory circuits.

[0024] Mass storage device 406 is a functional block and / or device that executes the operations of a mass non-volatile storage element for storing data and instructions used by other functional blocks of the electronic device 400. The mass storage device 406 may be a mass semiconductor memory (e.g., flash memory, etc.), a disk drive (hard drive, etc.), an optical drive, etc., or may include these. Copies of the data and instructions stored in the mass storage device 406 are retrieved and stored in the memory 404 for use by other functional blocks within 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 predetermined size (e.g., 4 kB, 2 MB, etc.), and the pages are stored in the memory 404 for access by other functional blocks. Further, pages may be newly generated at available locations within the memory 404 (e.g., for storing calculation results).

[0025] The IO devices 408 - 412 are functional blocks and / or devices that perform corresponding IO operations. The specific nature of the IO operations performed by each of the IO devices 408 - 412 depends on the nature of the IO device. For example, the IO devices 408 - 412 can include human interface devices, network interface devices, audio / visual processing or providing devices, GPUs, sensor devices, disk controllers, Peripheral Component Interface (PCI) devices, Universal Serial Bus (USB) devices, etc., and each IO device performs related operations such as receiving input from humans (e.g., keyboards, mice, etc.), receiving or transmitting data over a network. The IO devices 408 - 412 provide data and / or instructions to other functional blocks of the electronic device 400 or consume data and / or instructions from these. For example, in some embodiments, the IO devices 408 - 412 access (i.e., read, write, invalidate, etc.) data within a memory page in the guest memory 428 (i.e., a part of the memory reserved for a given guest operating system).

[0026] In some embodiments, the IOMMU 424 monitors operations initiated by the IO devices 408 - 412, such as direct memory access (DMA) requests 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 notified to the hypervisor and / or guest operating system (e.g., the appropriate driver within the hypervisor and / or guest operating system). For example, the IOMMU 424 may determine that a failure has occurred in DMA address translation, write a PPR log request, etc., or determine to notify the hypervisor and / or guest operating system of an interrupt. Some or all of these interrupts are processed using the operations described herein.

[0027] The I / O hub 414 is a functional block that performs the operations of an input / output hub that interfaces between the I / O devices 408-412 and other functional blocks of the electronic device 400 (e.g., the processor 402, the memory 404, etc.). The operations performed by the I / O hub 414 include operations to ensure that communications destined for the I / O devices 408-412 reach the intended I / O device, that communications from the I / O devices 408-412 reach the other functional blocks appropriately, that the other functional blocks are protected from accesses not allowed by the I / O devices 408-412, or vice versa. In some embodiments, the I / O hub 414 interfaces, converts, or translates relevant communications between buses using different communication standards (e.g., between a Peripheral Component Interconnect Express (PCIe) bus and a HyperTransport link (registered trademark)).

[0028] The IO hub 414 includes an IOMMU 424, which performs operations that enable the IO devices 408-412 to access data and / or instructions in the memory 404, and is a functional block that communicates with the processor 402 (and the guest operating system executed thereby). In these embodiments, when data and instructions are accessed in the memory 404 by an IO device (e.g., IO device 408), the IO device sends a memory access request (e.g., a direct memory access request or DMA) to the IOMMU 424. Next, the IOMMU 424 sends a corresponding request to the memory 404 to satisfy the memory access request. For example, in some embodiments, when data is retrieved based on a memory access request, the IOMMU 424 retrieves the data from the memory 404 (or from the mass storage device 406 if the data is not present in the memory 404) and transfers the data to the requesting IO device. In some embodiments, the IOMMU 424 includes a page table, a translation lookaside buffer, and / or other functional blocks used to translate the "virtual" or local memory addresses used by the IO devices 408-412 to the physical addresses of the memory 404 where the data is actually located. Further, when another functional block and / or device within the electronic device 400 accesses an IO device (e.g., communicates with the IO device or retrieves data from the IO device), the IOMMU 424 interfaces between the functional blocks and / or devices to enable access, such as by transferring communications, control values, data, etc.

[0029] In the described embodiments, the IOMMU 424 communicates with the guest operating system executed by cores 418-420 within the virtual machine, and vice versa. For example, in some embodiments, the IOMMU 424 (or the IO devices 408-412 via the IOMMU 424) communicates events and peripheral page requests (PPRs) to the guest operating system. In these embodiments, the IOMMU 424 reports events such as IO page faults (instead of the IO devices 408-412 for page table walks), errors in the IOMMU 424 hardware, etc. to the guest operating system via a shared guest event log in the memory 404. Further, in these embodiments, the IOMMU 424 transfers PPRs from a peripheral device (IO device) using a well-known address translation service or ATS standard to the guest operating system via a shared guest PPR log in the memory 404 for memory page provisioning operations (i.e., for performing operations on pages in the memory 404 accessible by the guest operating system). As another example, in some embodiments, the guest operating system communicates commands to the IOMMU 424. In these embodiments, the guest operating system issues commands such as completion wait (functioning as a command barrier to complete the previous command before the IOMMU 424 proceeds), invalidation of device table entries, invalidation of IOMMU translation lookaside buffer entries, etc. to the IOMMU 424 via a shared guest command buffer in the memory 404 to control the IOMMU 424 and / or the IO devices 408-412. As yet another example, the IOMMU 424 communicates information regarding IOMMU source interrupts such as peripheral page request interrupts, event-based interrupts, instruction completion-based interrupts (e.g., completion wait interrupts, completion wait synchronization interrupts, etc.) to the guest operating system. As will be described in detail below, the IOMMU 424 uses the virtual APIC backing page to convey interrupt-related information to the guest operating system.

[0030] In some embodiments, the IOMMU 424 provides an interface to the guest operating system, which includes memory map locations, registers, etc. used to communicate with the IOMMU 424. For example, in some embodiments, the IOMMU 424 provides a set of memory-mapped input / output (MMIO) memory locations where the guest operating system can write values, such that the values are received by the IOMMU 424. In some embodiments, the interface is virtualized. That is, memory locations, registers, etc. are not used to store values as assumed by the guest operating system, but instead are merely presented by the IOMMU 424. In these embodiments, the IOMMU 424 can receive values from the guest operating system via the interface, but for each guest operating system (e.g., addressed to IOMMU MMIO addresses, etc.), other locations in the IOMMU backing store 426 and / or memory 404 are used to store separate copies of the values of memory locations, registers, etc. Memory accessed by the IOMMU 424 to communicate with the guest operating system and other entities (e.g., the processor 402, etc.) will be described in more detail below.

[0031] In some embodiments, although not shown in FIG. 4, the IOMMU 424 includes local cache memory used to store 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 backing store 426, such as a set of values of the IOMMU MMIO registers of a given guest operating system and / or individual values therefrom. Since the cache memory is smaller than the IOMMU backing store 426, it may have only the capacity (i.e., memory locations) to store some (and perhaps only a very small part) of the data and information stored in the IOMMU backing store 426.

[0032] Guest memory 428 is a part (e.g., one or more consecutive or non - consecutive pages or blocks of memory) of memory 404 used by the corresponding guest operating system to store data and information used by the guest operating system. Generally, guest memory 428 can be used by the guest operating system and / or other entities to store any form of data and information used by the guest operating system and / or other entities. In some embodiments, guest memory 428 is protected and only specific entities are permitted to access guest memory 428. For example, the corresponding guest operating system, hypervisor, security processor, and / or the operating system within electronic device 400 can "protect" guest memory 428 by restricting access to guest memory 428 to the corresponding guest operating system and other specified devices and / or functional blocks. In some embodiments, guest memory 428 is encrypted or otherwise made inaccessible to unwanted entities. In some embodiments, guest memory 428 is used to store a guest event log, a guest peripheral page request (PPR) log, and a guest command buffer. Further, 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.

[0033] The hypervisor memory 432 is a part of the memory used by the hypervisor (e.g., one or more consecutive or non - consecutive pages or blocks of the memory) for storing data and information used by the hypervisor and / or other entities. Generally, the hypervisor memory 432 is used by the hypervisor and / or other entities and can be used to store various forms of data and information used by the hypervisor and / or other entities. For example, in some embodiments, the hypervisor memory 432 includes data and / or information such as device tables, interrupt remapping tables, etc. Although the hypervisor memory 432 is described as "hypervisor" memory, in some embodiments, the hypervisor memory 432 is accessible to various other entities within the system and simply includes a memory area or location where data and / or information initialized, maintained, and / or accessed by the hypervisor is stored. In some embodiments, at least some of what is shown and described as the hypervisor memory 432 is simply data and / or information stored in the system memory and freely readable and possibly writable by the hypervisor and / or other entities.

[0034] In some embodiments, communication paths are coupled between various functional blocks (processor 402, memory controller 416, memory 404, etc.) of the electronic device 400 as indicated by the arrow lines between the elements. The communication paths include one or more buses, wires, guides, and / or other connections, possibly along 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 the 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 some communication paths within the electronic device 400 are not shown in FIG. 4 for clarity.

[0035] In some embodiments, the electronic device hardware 310 of FIG. 3 includes functional blocks and devices such as a processor 402 and a memory 404, and the IO device hardware 314 includes functional blocks and devices such as IO devices 408-412. In these embodiments, the IOMMU 312 of FIG. 3 and the IOMMU 424 of FIG. 4 perform at least a portion of the same operations.

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

[0037] The electronic device 400 can be, or can be included in, any electronic device that performs computational operations. For example, the electronic device 400 can be, or can be included in, a desktop computer, a laptop computer, a wearable electronic device, a tablet computer, a smartphone, a server, an artificial intelligence device, a virtual or augmented reality device, network equipment, a toy, an audio-visual device, a household electrical appliance, a controller, a vehicle, etc., and / or combinations thereof.

[0038] (IOMMU source interrupt) In the described embodiments, an IOMMU (e.g., IOMMU 424) performs operations to notify a guest operating system of IOMMU source interrupts. The interrupts notified to the guest operating system are "IOMMU source" in that the interrupts are generated by the IOMMU. For example, the IOMMU can generate interrupts to notify the guest operating system of events encountered, executed, or occurred in the IOMMU, such as a failure or error, writing to a log or buffer of the guest operating system. As another example, the IOMMU can generate interrupts to notify the guest operating system of an operation initiated by an I / O device and / or an error or failure that occurred during the processing of an operation initiated by the I / O device. Generally, in the described embodiments, the IOMMU can use the described mechanism (i.e., virtual APIC backing page, etc.) to notify the guest operating system of any type of interrupt. In other words, an "IOMMU source" interrupt is, or can include, any interrupt that can communicate from the IOMMU to the guest operating system.

[0039] (Part of the memory accessed by the IOMMU) In some embodiments, the IOMMU accesses data and information in different portions of memory (e.g., memory 404) to perform the operations described herein and other operations. In some of these embodiments, a portion of the memory includes an IOMMU backing store (e.g., IOMMU backing store 426), guest memory (e.g., guest memory 428), and / or hypervisor memory. FIG. 5 is a block diagram showing a portion of the memory accessed by the IOMMU according to some embodiments. Although FIG. 5 is shown as an example, in some embodiments, the memory and / or different portions of the memory store different types and / or configurations of information. Generally, the memory includes sufficient information to enable the operations described herein.

[0040] As shown in FIG. 5, the IOMMU backing store 500 includes an ID conversion table 502. Generally, the ID conversion table 502 contains information used by the IOMMU to translate or convert guest domain IDs and / or device IDs to host domain IDs and / or device IDs in communications from the 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 more fully described in the AMD I / O Virtualization Technology (IOMMU) Specification, rev. 3.00 of December 2016, which is hereby incorporated by reference as described above.

[0041] In some embodiments, the ID conversion table 502 includes separate tables for domain IDs, shown as a domain ID mapping table 504, and for device IDs, shown as a device ID mapping table 506, although separate tables are not required (thus, all conversions may be included in a single table). The domain ID mapping table 504 includes a set of entries, each entry being used to store an identification or pointer to a guest domain ID associated with or related to a specified host domain ID. The device ID mapping table 506 includes a set of entries, each entry being used to store an identification or pointer to a guest device ID associated with or related to a specified host device ID. In operation, when a guest or host domain ID and / or device ID is translated or converted in a communication, the IOMMU performs a lookup in the ID conversion table 502 (i.e., the domain ID mapping table 504 and / or the device ID mapping table 506) to obtain the corresponding translation or conversion.

[0042] The IOMMU backing store 500 also includes a guest control 508. Generally, the guest control 508 includes copies of values stored in or from interface registers and control registers for a guest operating system in an electronic device. The guest control 508 includes 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 its guest operating system for each supported guest operating system. For example, the guest control 508 may include a map control register used to communicate domain IDs and / or device ID mappings for the guest operating system to the IOMMU for each guest operating system.

[0043] The IOMMU backing store 500 further includes guest memory mapped input / output (MMIO) 510. Generally, the guest MMIO 510 includes pointers and control information used to access buffers and logs (such as guest command buffers, guest event logs, and guest PPR logs) for a guest operating system in the guest portion of memory 404 (e.g., guest memory 428). More specifically, the guest MMIO 510 includes copies of values used to control access to buffers and logs in the guest portion of memory 404 for each supported guest operating system. For example, in some embodiments, the IOMMU supports (can handle interactions, communications, etc.) a guest operating system. Here, N = 10, 16, or another value, and the guest MMIO 510 has a maximum of 2 N values for controlling access to the buffers and logs in the guest portion of memory 404 for each supported guest operating system. For example, in some embodiments, the IOMMU supports (can handle interactions, communications, etc.) a guest operating system. Here, N = 10, 16, or another value, and the guest MMIO 510 has a maximum of 2 Ninclude a copy of, each for the supported guest operating system. In the described embodiments, the values used to control access are similar to the values stored in the IOMMU MMIO registers of existing devices, but separate sets of values are maintained for each supported guest operating system and refer to the guest portion of the guest operating system in memory 404 (not a single copy in the IOMMU of an existing device).

[0044] FIG. 6 is a block diagram showing the values stored in guest MMIO 510 according to some embodiments. In the example of FIG. 6, the values of a single complete set of the IOMMU MMIO registers of a given guest operating system are shown together with the values of a portion of two adjacent sets of IOMMU MMIO registers above and below the single complete set of values. FIG. 6 is shown as such to illustrate that in some embodiments, as described above, the IOMMU backing store 426 includes a plurality of individual sets of values, each set of values associated with a given guest operating system. FIG. 6 is shown by way of example, and in some embodiments, guest MMIO 510 stores different values or values of different configurations. Generally, guest MMIO 510 and / or another entity stores sufficient information to access buffers and logs in the guest portion of memory, as described herein.

[0045] Each set of values of the guest MMIO 510 can typically be grouped into values associated with the guest command (CMD) buffer, guest event log, and guest PPR log of the guest operating system. In the case of the 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 the memory 404. In other words, the command tail pointer 600 holds some or all of the bits of the physical address in the guest portion of the memory 404 that indicate a pointer or reference such as a memory address (e.g., the location where the tail or most recently written entry of the command buffer is located). The values of the guest command buffer also include a command head pointer 602. This is a pointer or other reference indicating the head or base of the command buffer, i.e., the location where the command buffer starts in the corresponding guest portion of the memory 404, and / or the location where the buffered commands start. The values of the guest command buffer further include a command length 604. This is a value indicating the current or maximum size of the command buffer, such as the number of entries or bytes. The values of the guest command buffer further include a command control 606, which is a set or sequence of bits that includes some bits (or combinations thereof) indicating the configuration of the command buffer in the guest operating system and / or the corresponding guest portion of the memory 404. For example, in some embodiments, the command control 606 includes bits indicating whether interrupts related to a particular command buffer are enabled, whether command buffering or processing is enabled (or disabled / stopped), what types of commands are present in the command buffer, or whether they can be present, etc.For example, in some embodiments, command control 606 includes command buffer control values similar to those described in the AMD I / O Virtualization Technology (IOMMU) Specification, rev. 3.00, which, as described above, include CmdWaitInt, CmdBufRun, CmdWaitInteEn, CmdBufEn, and / or other values, etc.

[0046] In the case of the event log, the values of guest MMIO 510, namely, the functions of event tail pointer 608, event head pointer 610, event length 612, and event control 614, are similar to the functions described above for the command buffer, but these values are used for access to the event log in the corresponding guest portion of memory 404. The same applies to the PPR log, where the values of guest MMIO 510, PPR tail pointer 616, PPR head pointer 618, PPR length 620, and PPR control 622 are similar to the functions described above for the command buffer. However, these values are used for access to the PPR log in the corresponding guest portion of memory 404.

[0047] In some embodiments, a number of guest operating systems less than the number supported (and in some cases far less) may be executed at any given time on the electronic device 400. In some of these embodiments, the IOMMU backing store 500 is dynamically adjusted to include sufficient space to store guest MMIOs 510 and the like. In other words, when a guest operating system is initialized / activated, the hypervisor and / or another entity can allocate, add, or activate space in the IOMMU backing store 500 (i.e., guest MMIO 510) to store the IOMMU MMIO register values of the guest operating system. In some of these embodiments, the IOMMU backing store 500 has no additional allocated empty / unused space for virtual machines that do not yet exist (i.e., are not initialized) within the electronic device 400.

[0048] In some embodiments, the hypervisor performs at least some initialization operations on the IOMMU backing store 500. For example, in some embodiments, the hypervisor allocates memory, e.g., contiguous or scattered pages of memory, to memory 404 to store the IOMMU backing store. As described above, memory 404 is the general-purpose memory within the electronic device 400 that is used by various functional blocks (e.g., cores 418-420, etc.) to store data and information, and is not just local memory within the IOMMU. Thus, this operation involves the hypervisor allocating space within the "main" memory of the electronic device 400 to store the IOMMU backing store. As another example, in some embodiments, the hypervisor writes initial values to a copy of the IOMMU MMIO registers within the backing store of each active guest operating system via the IOMMU. Thus, the hypervisor writes the initial values of the pointers and control values of each active guest operating system to each copy of the IOMMU MMIO registers of the IOMMU backing store when the guest operating system is started up, etc.

[0049] In some embodiments, only a subset of the available IOMMU MMIO registers are included in the copy of the IOMMU MMIO registers within the IOMMU backing store. In these embodiments, other registers may be provided by the IOMMU itself. For example, in some embodiments, registers within the IOMMU that store IOMMU control values (e.g., enabling / disabling of the IOMMU, etc.), the base address of the page table, etc., are provided by the IOMMU. Generally, IOMMU MMIO registers that are not used for access to a portion of the buffer and log of the guest operating system memory are not shown as a copy, but instead, a single copy of each register is provided by the IOMMU. In some of these embodiments, the hypervisor emulates these IOMMU registers for the guest operating system, but accesses are received and processed by the IOMMU for the registers within the IOMMU.

[0050] Returning to FIG. 5, the guest memory 512 includes a guest event log 514 for the guest operating system, a guest peripheral page request (PPR) log 516, a guest command buffer 518, and a virtual APIC backing page 520. Generally, the guest event log 514, the guest PPR log 516, the guest command buffer 518, and the virtual APIC backing page 520 are memory structures (e.g., lists, tables, buffers, etc.) used to store information regarding and / or for processing or handling corresponding events, PPR requests, and interrupts that are accessed by the IOMMU and / or the guest operating system. For example, the guest event log 514 may be a table or a ring buffer that includes several (e.g., 24, 50, etc.) entries, and each entry holds information (e.g., a pattern of bits) representing a specific event that occurred within the IOMMU to be processed by the corresponding guest operating system. As another example, the virtual APIC backing page may be a table or a list in memory that includes values of registers or memory locations within the virtual copy of the APIC and values of IOMMU source interrupts provided by the IOMMU. During operation, the IOMMU communicates events and PPRs to the guest operating system via the corresponding logs of the guest event log 514 and the guest PPR log 516 in the guest memory 512. Further, the guest operating system communicates commands to the IOMMU via the corresponding command buffer of the guest command buffer 518 in the guest memory 512. The IOMMU and / or other entities also transfer information regarding interrupts to the guest operating system via the virtual APIC backing page 520.

[0051] As shown in FIG. 5, the virtual APIC backing page 520 includes virtual APIC values 522, which include values for emulating the virtualized APIC of the corresponding guest operating system, such as values of the interrupt command register (ICR), interrupt request register (IRR), in-service register (ISR), interrupt end (EOI), etc. These values and related functions are known in the art and are described, for example, in AMD64 Architecture Programmer’s Manual Volume 2: System Programming, rev. 3.30, September 2018, which is incorporated herein by reference as described above.

[0052] Also, the virtual APIC backing page 520 includes IOMMU values 524, which are values used by the IOMMU to communicate information regarding IOMMU source interrupts to the corresponding guest operating system and do not exist in existing electronic devices. In some embodiments, the IOMMU value 524 includes separate values used to communicate information regarding each type of IOMMU source interrupt allowed to the corresponding guest operating system. Thus, in these embodiments, if there are N types of IOMMU source interrupts, there are N values in the IOMMU value 524. In some embodiments, the IOMMU value 524 includes a single value used to communicate information regarding all types of IOMMU source interrupts to the corresponding guest operating system. Generally, the information of the IOMMU value 524 is sufficient to communicate to the corresponding guest operating system the type, parameters, and / or other properties of each IOMMU source interrupt. For example, in some embodiments, each IOMMU source interrupt may be characterized or represented by a multi-bit value that 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.

[0053] Although specific values are shown in the virtual APIC backing page 520, in some embodiments, the virtual APIC backing page 520 includes different values and / or values of different configurations. The virtual APIC backing page 520 generally includes values sufficient to perform the operations described herein.

[0054] In some embodiments, each guest operating system active on the electronic device 400 is associated with a corresponding separate guest portion of memory (i.e., some pages in the memory 404) that includes a guest event log, a peripheral page request log, a guest command buffer, and a virtual APIC backing page used by that guest operating system and accessible by the IOMMU. This is shown in FIG. 5 as additional guest memory 526-528 behind the guest memory 512.

[0055] The hypervisor memory 530 includes a device table 532, an interrupt remapping table 534, and a guest interrupt log 536. The device table 532 is a table that stores device-related information about devices (which can be actual / physical devices or virtual devices) related to and / or coupled to an electronic device. The device table 532 includes a set of entries, and each entry can be used to store information about the corresponding device, such as pointers to page tables and interrupt remapping tables, control and configuration values, function indicators, mode indicators, domain IDs, security information and settings, etc. Further, in the described embodiments, unlike existing device tables, each entry of the device table 532 includes a device ID and a guest identifier of a guest operating system that communicates with, participates in, or is otherwise related to the device. During operation, in addition to using the device table to determine information about a device, the IOMMU translates or converts a guest device ID to a host device ID using the device ID and / or guest identifier. Also, the IOMMU uses the interrupt remapping table root pointer within the device table entry associated with the IOMMU to determine the location (e.g., address and / or offset) in memory where the interrupt remapping table 534 is stored.

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

[0057] The guest interrupt log 536 is a table, buffer, and / or other structure used by the IOMMU (and optionally other entities) to store information regarding interrupts destined for a guest operating system. If an interrupt from an IOMMU source destined for a particular guest operating system cannot communicate directly with the particular guest operating system using the virtual APIC backing page as described herein, the IOMMU writes information regarding the interrupt to the guest interrupt log 536 to indicate to the hypervisor that the interrupt is pending processing by the particular guest operating system. The hypervisor then retrieves the information regarding the interrupt from the guest interrupt log 536 and interacts with the predetermined guest operating system to enable the predetermined guest operating system to process the interrupt.

[0058] In some embodiments, the guest operating system is configured or designed to support receiving IOMMU source interrupts from the IOMMU via the corresponding virtual APIC backing page, as described herein. For example, the guest operating system may include program code, routines, methods, and / or other mechanisms for receiving IOMMU source interrupts from the IOMMU (other guest operating systems may not include them). As another example, the guest operating system may include one or more software switches or control values that configure the guest operating system to receive (or not receive) IOMMU source interrupts from the IOMMU. In these embodiments, each guest operating system is associated with one or more configuration indicators (e.g., bits, bytes, etc.) that indicate whether the guest operating system can receive interrupts from the IOMMU via the corresponding virtual APIC backing page. As yet another example, an electronic device, a hypervisor, and / or another entity within the electronic device may disable direct communication of information regarding interrupts from the IOMMU to one or more (optionally all) guest operating systems. For one or more of these reasons, if the IOMMU cannot send IOMMU source interrupts to the guest operating system via the corresponding virtual APIC backing page, the IOMMU uses the guest interrupt log 536 as described above to communicate the interrupt to a particular guest operating system.

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

[0060] In some embodiments, the IOMMU includes a private address map that includes pointers, references, and / or other indicators to the locations in memory of various data and information in the memory accessed by the IOMMU. For example, in some embodiments, the IOMMU private address map includes pointers or references to individual copies of the IOMMU MMIO registers of the guest operating system and / or the starting point / base address of a set of copies of the IOMMU MMIO registers in the IOMMU backing store 500. In these embodiments, before accessing data and information in memory, the IOMMU performs a lookup in the private address map for the location of the data and information.

[0061] In some embodiments, the IOMMU backing store 500 and / or a part thereof (such as control bits, etc.) cannot be accessed by or is accessed by other entities of the electronic device 400 via the IOMMU (e.g., by sending a request to the IOMMU). For example, at least some of the data and information in the IOMMU backing store 500 can be accessed by other entities via writing to and reading from the corresponding IOMMU MMIO registers.

[0062] (Communication between the IOMMU and the guest operating system) In the described embodiments, an IOMMU (e.g., IOMMU 424) processes communication between the IOMMU (or the IO device served thereby) and the guest operating system. FIG. 7 is a block diagram showing communication between a guest operating system 700 and an IOMMU 702 processed by the IOMMU 702 according to some embodiments. Although some elements are shown in a particular configuration in FIG. 7, other embodiments may use a different number or configuration of elements. Generally, in the described embodiments, the IOMMU 702 includes or has access to elements sufficient to enable the operations described herein. In FIG. 7, some elements are shown in dashed / dotted lines. These elements are logs, buffers, etc. stored in memory (e.g., in the IOMMU backing store 500, in the guest memory 512, etc.) and accessed using typical memory access techniques by the IOMMU 702, the guest operating system 700, and / or other entities. In some embodiments, the guest operating system 700, the IOMMU 702, and the hypervisor 704 are configured similarly to the guest operating system 302, the IOMMU 312, and the hypervisor 306 of FIG. 3, but this is not a requirement.

[0063] As shown in FIG. 7, unlike that shown in FIG. 2 for the existing system, in the described embodiment, the IOMMU 702 and the guest operating system 700 communicate more directly with each other. In other words, the IOMMU 702 and the guest operating system 700 communicate with each other via the guest event log 514, the guest PPR log 516, the guest command buffer (BUFF) 518, and the virtual APIC backing page 520 of the memory (i.e., the guest portion of the memory of the guest operating system 700 (e.g., guest memory 428)). Further, the guest operating system 700 and the IOMMU 702 use the guest control 508 and the guest MMIO 510 to instruct how the communication is to be performed. For example, in some embodiments, the IOMMU 702 uses a pointer in the guest MMIO 510 to determine the locations in memory of the guest event log 514, the guest command buffer 518, and the guest PPR log 516 for the guest operating system 700. Also, the IOMMU determines the location of the virtual APIC backing page 520 of the memory where information regarding the IOMMU source interrupts is written using an interrupt remapping table (e.g., interrupt remapping table 534). The hypervisor 704 does not intervene in some or all of the operations to complete these communications and is not otherwise involved. For example, the hypervisor 704 does not perform operations such as conversion of domain IDs and device IDs for these communications, access to pointers in the guest MMIO 510, transmission to the guest operating system regarding IOMMU source interrupts, and / or access to buffers and logs in the guest portion of the memory. Instead, the IOMMU 702 performs these operations. Since the IOMMU 702 converts domain IDs and device IDs, accesses guest buffers and logs, and transmits specified IOMMU source interrupts to the guest operating system, etc., the described embodiment avoids using the hypervisor 704 to handle at least a portion of the communication between the guest operating system 700 and the IOMMU 702.This may mean that communication is completed more quickly and the load on the processor 402, the memory 404, etc. is reduced.

[0064] During operation, using the command as an example, the guest operating system 700 writes the invalidate_IOMMU_pages command to the guest command buffer 518. When the command is processed by the IOMMU 702, the IOMMU 702 invalidates a range of entries in the IOMMU translation cache specified by the domain ID of the command. In other words, the guest operating system executes a memory write in the corresponding guest portion of the memory and updates the next open / available entry in the guest command buffer 518 to include the information of the invalidate_IOMMU_pages command (i.e., the bits representing the command).

[0065] Next, the guest operating system 700 sends a write command to the IOMMU, updates (e.g., advances) the command buffer tail pointer (e.g., command tail pointer 600) in the corresponding IOMMU MMIO register, indicating that the guest operating system 700 has written a command to the command buffer. The IOMMU 702 detects the writing of the command buffer tail pointer by the guest operating system 700, for example, via snooping of the write to the address in the corresponding guest command buffer, detection of a change in the value of the buffer tail pointer, reception of the write command from the guest operating system 700, etc. Upon detecting the writing of the command buffer tail pointer, the IOMMU 702 uses the value of the command buffer tail pointer to obtain a command from the command buffer in the guest portion of memory and prepares the command for processing (e.g., replacing the guest domain ID associated with the guest domain ID in the command with the host domain ID). Next, the IOMMU 702 processes the command, whereby the IOMMU 702 invalidates the range 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 writing to the guest PPR log 516 and the guest event log 514, but conversely, the IOMMU 702 normally writes these logs and the guest operating system 700 reads the logs.

[0066] During operation, the IOMMU 702 encounters or experiences a state that causes an IOMMU source interrupt to be processed or handled by the guest operating system 700. Next, the IOMMU 702 performs a lookup in the interrupt remapping table to determine the location within the virtual APIC backing page 520 where information regarding the interrupt is written. Next, the IOMMU 702 writes the information regarding the interrupt to the location within the virtual APIC backing page 520 and transmits an indication of the interrupt to the guest operating system 700. Next, the guest operating system 700 retrieves the information regarding the interrupt from the location within the virtual APIC backing page 520 and uses the information regarding the interrupt to process or handle the interrupt.

[0067] In some embodiments, if the guest operating system 700 cannot receive information regarding an interrupt directly from the IOMMU 702, i.e., via the virtual APIC backing page 520 described herein, the IOMMU 702 uses the guest interrupt log 536 to communicate information regarding the interrupt to the guest operating system 700 via the hypervisor 704. For example, the guest operating system 700 may not be able to receive an interrupt from the IOMMU 702 via the virtual APIC backing page 520, or may be configured not to receive an interrupt from the IOMMU 702 for security reasons or the like. In some embodiments, the IOMMU 702 preferentially uses the virtual APIC backing page 520 to communicate information regarding the interrupt directly to the guest operating system 700 and uses only the guest interrupt log 536 / hypervisor 704 as a secondary / fallback option.

[0068] The hypervisor 704 is not involved in specific parts of the communication between the guest operating system 700 and the IOMMU 702 (e.g., the conversion of the guest domain ID to the host domain ID, etc.), but the hypervisor 704 and the guest operating system 700 and / or the IOMMU 702 can exchange communications related to the communication between the guest operating system 700 and the IOMMU 702 separately. Alternatively, the hypervisor 704 may be involved in ensuring in other ways that the communication is properly processed by the guest operating system 700 and / or the IOMMU 702. As described above, the hypervisor 704 may initialize or update the IOMMU backing store, the interrupt remapping table, etc.

[0069] (Process of notifying the guest operating system of an interrupt from the IOMMU) In the described embodiments, an IOMMU (e.g., IOMMU 702) performs operations to notify a guest operating system (e.g., guest operating system 700) of an interrupt. For example, in some embodiments, the IOMMU notifies the guest operating system of an IOMMU source interrupt such as an interrupt generated by the IOMMU or an interrupt based on an interrupt from an I / O device. The IOMMU "directly" notifies the guest operating system, and the IOMMU itself uses normal memory access operations (without the hypervisor participating in or processing the memory access operations) to write information regarding the interrupt to a specified location of a virtual APIC backing page in a portion of each guest operating system's memory. Next, the IOMMU transmits an indication of the interrupt to the guest operating system to cause the guest operating system to process or handle the interrupt. FIG. 8 is a flowchart showing a process by which an IOMMU notifies a guest operating system of an interrupt according to some embodiments. Note that the operations shown in FIG. 8 are shown as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0070] The operation of FIG. 8 begins when the IOMMU generates information regarding an interrupt (step 800). In this operation, the IOMMU internally generates information regarding the interrupt, such as by detecting an event, error, etc. specified by the IOMMU and generating corresponding information, or receiving an indication of an interrupt, event, error, etc. from an I / O device (or other entity) and generating corresponding information regarding the interrupt. For example, the IOMMU itself may write data to a buffer or log related to the guest operating system and then generate information regarding the interrupt to be communicated to the guest operating system, notifying the guest operating system that the data in the buffer or log has been processed or handled.

[0071] The specific format of the information regarding the interrupts generated by the IOMMU depends on the format of the interrupts themselves, the configuration of the guest operating system, etc. For example, in some embodiments, the information regarding the interrupts includes the specified information and / or is formatted according to the Message Signaled Interrupt (MSI) standard or protocol. Generally, the information includes at least the identification or representation of the interrupt and may include other properties and / or characteristics such as the interrupt, the IOMMU, the I / O device, the event or error leading to the interrupt, etc.

[0072] Next, the IOMMU obtains, from an entry in the interrupt remapping table associated with the guest operating system, the location within the virtual APIC backing page of the guest operating system in the guest portion of memory (step 802). Recall that the virtual APIC backing page is a portion of memory used to store information regarding interrupts processed by the guest operating system and, otherwise, to virtualize / emulate the APIC in the electronic device 400. The virtual APIC backing page includes one or more locations (entries, portions, etc.) used to store information regarding interrupts from the IOMMU source for processing or handling by the guest operating system. For the operation in step 802, in some embodiments, the IOMMU performs a lookup in the interrupt remapping table using a guest operating system identifier (ID), such as a system device identifier assigned to the guest operating system at initialization (e.g., by the system hardware, operating system, etc.). FIG. 9 is a block diagram showing a lookup in the interrupt remapping table according to some embodiments. Although a particular arrangement of the interrupt remapping table and operations is shown in FIG. 9, 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 where interrupt-related information is written to the virtual APIC backing page of the guest operating system.

[0073] For the embodiment shown in FIG. 9, the interrupt remapping table is divided into a hierarchy of sub-tables including a level 1 (LEVEL1) interrupt remapping table 906 and an interrupt remapping table 908. Dividing the interrupt remapping table into a hierarchy of sub-tables enables more efficient searching, storing in memory, operation, etc. of the interrupt remapping table. This configuration of the interrupt remapping table is shown as an example, but in some embodiments, the interrupt remapping table includes more sub-tables or is implemented as a single table. Generally, the interrupt remapping table contains sufficient information to enable the operations described herein.

[0074] For a lookup 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 IOMMU's device table entry 902 to determine a specific entry in the level 1 interrupt table 906. The entry in the level 1 interrupt table 906 stores a root / base pointer 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 within the interrupt remapping table 908. From the entry in the interrupt remapping table 908, the IOMMU obtains an identifier (e.g., an address, offset, etc.) of the location within the virtual APIC backing page 910 where interrupt-related information is stored.

[0075] In some embodiments, the IOMMU can communicate information regarding two or more different types of interrupts to the guest operating system. For example, in some embodiments, the types of interrupts can include event notification interrupts, peripheral page request interrupts, fault or error interrupts, etc. In these embodiments, the virtual APIC backing page of each guest operating system includes the positions of two or more IOMMU source interrupts, and each position is used to store information regarding one or more different types of interrupts. In the above lookup in the interrupt remapping table, in addition to the guest operating system identifier, the IOMMU can use a type indicator (e.g., one or more bits, etc.) to access the corresponding entry in the interrupt remapping table for a specific interrupt type.

[0076] Returning to FIG. 8, after obtaining the position within the virtual APIC backing page (step 802), the IOMMU writes the interrupt-related information to the position within the virtual APIC backing page (step 804). In this operation, the IOMMU writes at least the identifier of the interrupt to the position of the virtual APIC backing page and may also write additional information regarding one or more properties or characteristics such as the interrupt, the IOMMU, and / or the I / O device. For example, in some embodiments, the position within the virtual APIC backing page includes only a single bit that is set to indicate that an interrupt has occurred and thus the guest operating system should handle or respond to the interrupt, for example, by executing a specified interrupt handling program code and performing one or more operations. As another example, in some embodiments, the position within the virtual APIC backing page includes multiple bits or bytes that can be used to store information identifying the interrupt, along with other information regarding the properties and characteristics of the interrupt. In these embodiments, the guest operating system obtains the interrupt-related information from the virtual APIC backing page and uses the interrupt-related information to handle or respond to the interrupt.

[0077] Next, the IOMMU communicates the interrupt indicator to the guest operating system (step 806). In this operation, the IOMMU notifies the guest operating system that the interrupt is being processed or waiting to be handled, that is, that information about the interrupt exists at the location of the virtual APIC backing page of 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 of the electronic device (e.g., core 418) (and the guest operating system is not stopped or not being executed preferentially over other program code), communicating the interrupt includes sending a corresponding signal from the IOMMU to the executing processor core. For example, sending the signal can include one or more of writing to a memory location of a shared mailbox, asserting a signal on a designated signal line, sending a packet to the processor core on a communication bus, etc. As another example, in some embodiments, when the guest operating system is "inactive", that is, when the program code of the guest operating system is not currently being executed by a processor core (and the guest operating system is stopped or not being executed preferentially over other program code), communicating the interrupt includes adding an entry to the guest virtual APIC log, which is a record of the interrupts pending to be processed or handled by the guest operating system. Next, the IOMMU sends an indication of the addition of the entry to the guest virtual APIC log to the processor via the memory location of the shared mailbox and asserts a signal on a designated signal line or the like. Next, when the hypervisor triggers the guest operating system to reactivate the guest operating system, the interrupt from the virtual APIC backing page can be processed or handled, and the guest operating system may be specifically reactivated to process or handle the interrupt.

[0078] Next, the guest operating system obtains information regarding the interrupt from a position within the virtual APIC backing page (step 808), and processes or handles the interrupt using the information regarding the interrupt (step 810). In this operation, the guest operating system obtains information from a position in the virtual APIC backing page via one or more memory reads. Next, the guest operating system executes interrupt processing program code, executes corresponding operations, ends one or more operations, notifies the processor core on which the guest operating system is running of the occurrence of the interrupt, and notifies the hypervisor or the operating system of the occurrence of the interrupt, etc., to process or handle the interrupt.

[0079] (Interrupts not communicated directly from the IOMMU to the guest operating system) As described above, the IOMMU uses the virtual APIC backing page of the guest operating system to directly notify the guest operating system of the IOMMU source interrupt (i.e., without the assistance of the hypervisor in writing to the virtual APIC backing page, etc.). However, in some cases, it is not permitted to communicate the IOMMU source interrupt directly from the IOMMU to the guest operating system. For example, the guest operating system may be configured not to directly receive the IOMMU source interrupt from the IOMMU for security reasons, efficiency, etc. (e.g., using software switches or configuration values, etc.). In such a case, the IOMMU uses a different mechanism to notify the guest operating system of the IOMMU source interrupt. For example, in some embodiments, when the IOMMU cannot directly communicate the IOMMU source interrupt to the guest operating system, the IOMMU uses an intermediate interrupt communication mechanism to indirectly notify the guest operating system of the IOMMU source interrupt via an intermediate entity.

[0080] In some embodiments, the intermediate entity that the IOMMU uses to notify the guest operating system of an interrupt is or includes a guest interrupt log. The guest interrupt log is a table, buffer, etc. in which information about the interrupt is stored for the guest operating system to ultimately process with the assistance of the hypervisor (and / or another entity). During operation, after a particular guest operating system determines that it cannot directly receive an IOMMU source interrupt from the IOMMU, the IOMMU writes information about the interrupt to the guest interrupt log of the particular guest operating system. Next, the IOMMU notifies the hypervisor that the information has been written to the guest interrupt log and / or that the hypervisor has detected the writing to the guest interrupt log, whereupon the hypervisor transfers or communicates the interrupt to the guest operating system (such as via writing the interrupt to the virtual APIC backing page of the guest operating system). Next, the designated guest operating system processes the interrupt.

[0081] In some embodiments, an electronic device (e.g., electronic device 400 and / or a part thereof) uses code and / or data stored in a non-transitory computer-readable storage medium to perform some or all of the operations described herein. More specifically, the electronic device reads the code and / or data from the computer-readable storage medium and executes the code and / or uses the data when performing the described operations. The computer-readable storage medium may be any device, medium, or combination thereof that stores the code and / or data used by the electronic device. For example, the computer-readable storage medium can include, but is not limited to, volatile memory and / or non-volatile memory such as 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 drive, magnetic tape, CD, DVD, etc.).

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

[0083] 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 portions thereof) can be read by an electronic device and is stored in a non-transitory computer-readable storage medium that includes a database or other data structure that can be used directly or indirectly to manufacture hardware that includes the structures and mechanisms. For example, the data structure may be an operational level description or a register transfer level (RTL) description of the hardware functionality in a high-level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool, which can synthesize the description to generate a netlist that includes a list of gate / circuit elements representing the functionality of the hardware that includes the structures and mechanisms described above from a synthesis library. Next, the netlist can be placed, routed, and a data set describing the geometries to be applied to the mask can be generated. Then, the mask can be used in various semiconductor manufacturing steps to manufacture one or more semiconductor circuits (e.g., integrated circuits) corresponding to the structures and mechanisms described above. Alternatively, the database on the computer-accessible storage medium may be, as needed, a netlist (with or without a synthesis library) or a data set or Graphic Data System (GDS) II data.

[0084] As used herein, variables or unspecified values (i.e., a general description of a value without a specific instance of the value) are represented by letters such as N. Similar letters may be used elsewhere in this description, but as used herein, the variables and unspecified values in each case are not necessarily the same, i.e., different variable amounts and values may exist for some or all of the general variables and unspecified values. In other words, the N and other letters used to represent variables and unspecified values in this description are not necessarily related to each other.

[0085] As used herein, the expression "et cetra" or "etc." is intended to present cases of "and / or", that is, those corresponding to "at least one" of the elements in the list related to "etc.". For example, in the sentence "The electronic device performs the first operation, the second operation, etc.", the electronic device performs at least one of the first operation, the second operation, and other operations. Further, the elements in the list related to "etc." are merely examples in a set of embodiments, and some of the embodiments may not appear in some embodiments.

[0086] The above description of the embodiments is presented for purposes of illustration and description only. These are not intended to be exhaustive or to limit the embodiments to the disclosed forms. Accordingly, many modifications and variations will be apparent to those skilled in the art. Further, 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 that executes a guest operating system; a guest portion secured for storing data and information accessed by the guest operating system, the guest portion including a virtual APIC backing page used for storing data for emulating an advanced programmable interrupt controller (APIC) function block of the guest operating system; an input / output memory management unit (IOMMU); wherein the IOMMU is configured to: obtain a location of the virtual APIC backing page of the guest operating system in the guest portion of the memory from an entry of an interrupt remapping table associated with the guest operating system; write information regarding an interrupt to the location of the virtual APIC backing page; transmit an indicator of the interrupt to the guest operating system; thereby being configured to notify the guest operating system of an interrupt. The electronic device.

2. When the IOMMU obtains a location within the virtual APIC backing page from the entry of the interrupt remapping table, the IOMMU is configured to: obtain a base address of the interrupt remapping table from a device table entry associated with the IOMMU; determine an entry of the interrupt remapping table using the base address and a guest operating system identifier (ID); obtain an address of the location of the virtual APIC backing page from the entry of the interrupt remapping table. The electronic device according to Claim 1.

3. The virtual APIC backing page of the guest portion of the memory includes a plurality of locations, each of the plurality of locations being used for storing data associated with a different type of interrupt, and the interrupt remapping table includes individual entries for storing indicators of each of the plurality of locations. When the IOMMU obtains a location within the virtual APIC backing page from the interrupt remapping table, ​ configured to determine an entry of the interrupt remapping table using the type of the interrupt together with the base address and the guest operating system ID The electronic device according to claim 2

4. The interrupt remapping table includes at least two levels of sub-tables, each sub-table other than the last sub-table in the levels of sub-tables includes an identifier of the next sub-table in the levels, and the last sub-table includes an address of a position of the virtual APIC backing page When determining an entry of the interrupt remapping table using the base address and the guest operating system ID, the IOMMU is configured to proceed to the last sub-table of the levels of sub-tables using a corresponding part of the base address and / or the guest operating system ID The electronic device according to claim 2

5. The IOMMU determines whether direct communication of the interrupt from the IOMMU to the guest operating system is permitted when direct communication of the interrupt is permitted, notifies the guest operating system of the interrupt when direct communication of the interrupt is not permitted, uses one or more intermediate interrupt communication mechanisms to indirectly notify the guest operating system of the interrupt configured to perform the above The electronic device according to claim 1

6. When determining whether direct communication of the interrupt is permitted, the IOMMU checks one or more settings of a device table entry associated with the IOMMU to determine whether communication of the interrupt by the IOMMU is effective and / or whether the guest operating system is configured to receive an interrupt from the IOMMU The electronic device according to claim 5

7. The one or more intermediate interrupt communication mechanisms include a guest interrupt log The IOMMU is configured to store information about the interrupt in the guest interrupt log The hypervisor executed by the processor detects or is notified that the IOMMU has stored information regarding the interrupt in the guest interrupt log, and indicates the interrupt to the guest operating system. The electronic device according to claim 5.

8. The processor executes a hypervisor that initializes and maintains the interrupt remapping table by storing an identifier of a position in a virtual APIC backing page for a guest operating system of each guest portion of the memory in a corresponding entry of the interrupt remapping table. The electronic device according to claim 1.

9. Transmitting the indicator of the interrupt to the guest operating system includes transmitting an interrupt to the processor when the guest operating system is currently active. The electronic device according to claim 1.

10. Transmitting the indicator of the interrupt to the guest operating system includes adding an entry to a guest virtual APIC log and transmitting an indicator of adding the entry to the guest virtual APIC log to the processor when the guest operating system is not currently active. The electronic device according to claim 1.

11. The processor is configured to process an interrupt of the guest operating system by obtaining information regarding the interrupt from a position in the virtual APIC backing page and processing or handling the interrupt using the information regarding the interrupt based on receiving the indicator of the interrupt on behalf of the guest operating system. The electronic device according to claim 1.

12. The interrupt is an IOMMU source interrupt. The electronic device according to claim 1.

13. A method for notifying an interrupt in an electronic device including a processor that executes a guest operating system, a memory having a guest portion secured for storing data and information accessed by the guest operating system, the guest portion including a virtual APIC backing page used to store data for emulating an advanced programmable interrupt controller (APIC) functional block of the guest operating system, and an input / output memory management unit (IOMMU), comprising: the IOMMU obtaining a location of the virtual APIC backing page of the guest operating system in the guest portion of the memory from an entry of an interrupt remapping table associated with the guest operating system; the IOMMU writing information regarding the interrupt to the location of the virtual APIC backing page; the IOMMU transmitting an indicator of the interrupt to the guest operating system; whereby the IOMMU notifies the guest operating system of the interrupt. Method. **Claim 14** Obtaining the location within the virtual APIC backing page from the entry of the interrupt remapping table comprises: the IOMMU obtaining a base address of the interrupt remapping table from a device table entry associated with the IOMMU; the IOMMU determining an entry of the interrupt remapping table using the base address and a guest operating system identifier (ID); the IOMMU obtaining an address of the location of the virtual APIC backing page from the entry of the interrupt remapping table. The method of claim 13. **Claim 15** The virtual APIC backing page of the guest portion of the memory includes a plurality of locations, each of the plurality of locations being used to store data associated with a different type of interrupt, the interrupt remapping table including individual entries for storing indicators for each of the plurality of locations. Obtaining the location within the virtual APIC backing page from the interrupt remapping table entry comprises: The method according to claim 14, wherein the IOMMU determines an entry of the interrupt remapping table by using the type of the interrupt together with the base address and the guest operating system ID. The method of claim 14. **Claim 16** The interrupt remapping table includes a hierarchy of at least two sub-tables, each sub-table other than the last sub-table in the hierarchy of sub-tables includes an identifier of the next sub-table in the hierarchy, and the last sub-table includes an address of a position of the virtual APIC backing page. Determining an entry of the interrupt remapping table by using the base address and the guest operating system ID includes: The IOMMU proceeds to the last sub-table of the hierarchy of sub-tables by using a corresponding part of the base address and / or the guest operating system ID. The method of claim 14. **Claim 17** The method further includes: the IOMMU determines whether direct communication of the interrupt from the IOMMU to the guest operating system is permitted; when direct communication of the interrupt is permitted, the IOMMU notifies the guest operating system of the interrupt; and when direct communication of the interrupt is not permitted, the IOMMU uses one or more intermediate interrupt communication mechanisms to indirectly notify the guest operating system of the interrupt. When direct communication of the interrupt is permitted, the IOMMU notifies the guest operating system of the interrupt. When direct communication of the interrupt is not permitted, the IOMMU uses one or more intermediate interrupt communication mechanisms to indirectly notify the guest operating system of the interrupt. The method of claim 13. **Claim 18** Determining whether direct communication of the interrupt is permitted includes: The IOMMU checks one or more settings of a device table entry associated with the IOMMU to determine whether interrupt communication by the IOMMU is valid and / or whether the guest operating system is configured to receive interrupts from the IOMMU. The method of claim 17. **Claim 19** The one or more intermediate interrupt communication mechanisms include a guest interrupt log. The method further includes: The IOMMU stores information about the interrupt in the guest interrupt log. The hypervisor executed by the processor detects or is notified that the IOMMU has stored information regarding the interrupt in the guest interrupt log, and indicates the interrupt to the guest operating system. The method of claim 17.

20. The processor executes a hypervisor. The method includes initializing and maintaining the interrupt remapping table by the hypervisor storing an identifier of a position in a virtual APIC backing page for a guest operating system of each guest portion of the memory in a corresponding entry of the interrupt remapping table. The method of claim 13.

21. Transmitting an indication of the interrupt to the guest operating system includes when the guest operating system is currently active, the IOMMU sending an interrupt to the processor. The method of claim 13.

22. Transmitting an indication of the interrupt to the guest operating system includes when the guest operating system is not currently active, the IOMMU adding an entry to a guest virtual APIC log and sending an indication to the processor that the entry has been added to the guest virtual APIC log. The method of claim 13.

23. Based on receiving an indication of the interrupt on behalf of the guest operating system, the processor obtains information regarding the interrupt from a position in the virtual APIC backing page and uses the information regarding the interrupt to process or handle the interrupt, thereby being configured to process an interrupt of the guest operating system. The method of claim 13.

24. The interrupt is an IOMMU source interrupt. The method of claim 13.

Images