Abstract: An electronic device includes a processor that executes a guest operating system and a hypervisor, an input-output (IO) device, and an input-output memory management unit (IOMMU). The IOMMU handles communications between the IOMMU and the guest operating system by: replacing, in communications received from the guest operating system, guest domain identifiers (domainIDs) with corresponding host domainIDs and/or guest device identifiers (deviceIDs) with corresponding host deviceIDs before further processing the communications; replacing, in communications received from the IO device, host deviceIDs with guest deviceIDs before providing the communications to the guest operating system; and placing, into communications generated in the IOMMU and destined for the guest operating system, guest domainIDs and/or guest deviceIDs before providing the communications to the guest operating system. The IOMMU handles the communications without intervention by the hypervisor.

Abstract: An electronic device includes a processor that executes one or more guest operating systems and an input-output memory management unit (IOMMU). The IOMMU accesses, for/on behalf of each guest operating system among the one or more guest operating systems, IOMMU memory-mapped input-output (MMIO) registers in a separate copy of a set of IOMMU MMIO registers for that guest operating system.

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

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

Abstract: An electronic device includes a processor that executes a guest operating system, an input-output memory management unit (IOMMU), and a main memory that stores an IOMMU backing store. The IOMMU backing store includes a separate copy of a set of IOMMU memory-mapped input-output (MMIO) registers for each guest operating system in a set of supported guest operating systems. The IOMMU receives, from the guest operating system, a communication that accesses data in a given IOMMU MMIO register. The IOMMU then performs a corresponding access of the data in a copy of the given IOMMU MMIO register in the IOMMU backing store associated with the guest operating system.

Abstract: An electronic device includes a processor that executes a guest operating system; a memory having a guest portion that is reserved for storing data and information to be accessed by the guest operating system; and an input-output memory management unit (IOMMU). The IOMMU writes, in the guest portion, information into guest buffers and/or logs used for communicating information from the IOMMU to the guest operating system. The IOMMU also reads, from the guest portion, information in guest buffers and/or logs used for communicating information from the guest operating system to the IOMMU.

Abstract: An electronic device includes a processor that executes a guest operating system, an input-output memory management unit (IOMMU), and a main memory that stores an IOMMU backing store. The IOMMU backing store includes a separate copy of a set of IOMMU memory-mapped input-output (MMIO) registers for each guest operating system in a set of supported guest operating systems. The IOMMU receives, from the guest operating system, a communication that accesses data in a given IOMMU MMIO register. The IOMMU then performs a corresponding access of the data in a copy of the given IOMMU MMIO register in the IOMMU backing store associated with the guest operating system.

Abstract: A processing system includes a plurality of input/output (I/O) devices representing a plurality of I/O resources. Each I/O resource has at least one corresponding memory mapped I/O (MMIO) address range. A trap handler detects a write request targeting a configuration space of an identified I/O resource of the plurality of I/O resources and, responsive to determining the identified I/O resource is a protected I/O resource, selectively blocks the write request from further processing by the processing system based on whether the write request would change an MMIO address decoding of the identified I/O resource.

Abstract: An electronic device includes a processor that executes a guest operating system and a hypervisor, an input-output (IO) device, and an input-output memory management unit (IOMMU). The IOMMU handles communications between the IOMMU and the guest operating system by: replacing, in communications received from the guest operating system, guest domain identifiers (domainIDs) with corresponding host domainIDs and/or guest device identifiers (deviceIDs) with corresponding host deviceIDs before further processing the communications; replacing, in communications received from the IO device, host deviceIDs with guest deviceIDs before providing the communications to the guest operating system; and placing, into communications generated in the IOMMU and destined for the guest operating system, guest domainIDs and/or guest deviceIDs before providing the communications to the guest operating system. The IOMMU handles the communications without intervention by the hypervisor.

Abstract: A system including a gasket communicatively coupled between a unified northbridge (UNB) having a cache coherent interconnect (CCI) interface and a processor having an Advanced eXtensible Interface (AXI) coherency extension (ACE). The gasket is configured to translate requests from the processor that include ACE commands into equivalent CCI commands, wherein each request from the processor maps onto a specific CCI request type. The gasket is further configured to translate ACE tags into CCI tags. The gasket is further configured to translate CCI encoded probes from a system resource interface (SRI) into equivalent ACE snoop transactions. The gasket is further configured to translate the memory map to inter-operate with a UNB/coherent HyperTransport (cHT) environment. The gasket is further configured to receive a barrier transaction that is used to provide ordering for transactions.

Abstract: A processor employs a hardware encryption module in the memory access path between an input/out device and memory to cryptographically isolate secure information. In some embodiments, the encryption module is located at a memory controller of the processor, and each memory access request provided to the memory controller includes VM tag value identifying the source of the memory access request. The VM tag is determined based on a requestor ID identifying the source of the memory access request. The encryption module performs encryption (for write accesses) or decryption (for read accesses) of the data associated with the memory access based on an encryption key associated with the VM tag.

Abstract: A system including a gasket communicatively coupled between a unified northbridge (UNB) having a cache coherent interconnect (CCI) interface and a processor having an Advanced eXtensible Interface (AXI) coherency extension (ACE). The gasket is configured to translate requests from the processor that include ACE commands into equivalent CCI commands, wherein each request from the processor maps onto a specific CCI request type. The gasket is further configured to translate ACE tags into CCI tags. The gasket is further configured to translate CCI encoded probes from a system resource interface (SRI) into equivalent ACE snoop transactions. The gasket is further configured to translate the memory map to inter-operate with a UNB/coherent HyperTransport (cHT) environment. The gasket is further configured to receive a barrier transaction that is used to provide ordering for transactions.

Abstract: The present invention provides for page table access and dirty bit management in hardware via a new atomic test[0] and OR and Mask. The present invention also provides for a gasket that enables ACE to CCI translations. This gasket further provides request translation between ACE and CCI, deadlock avoidance for victim and probe collision, ARM barrier handling, and power management interactions. The present invention also provides a solution for ARM victim/probe collision handling which deadlocks the unified northbridge. These solutions includes a dedicated writeback virtual channel, probes for IO requests using 4-hop protocol, and a WrBack Reorder Ability in MCT where victims update older requests with data as they pass the requests.

Abstract: A processor employs a hardware encryption module in the memory access path between an input/out device and memory to cryptographically isolate secure information. In some embodiments, the encryption module is located at a memory controller of the processor, and each memory access request provided to the memory controller includes VM tag value identifying the source of the memory access request. The VM tag is determined based on a requestor ID identifying the source of the memory access request. The encryption module performs encryption (for write accesses) or decryption (for read accesses) of the data associated with the memory access based on an encryption key associated with the VM tag.

Abstract: The present invention provides for page table access and dirty bit management in hardware via a new atomic test[0] and OR and Mask. The present invention also provides for a gasket that enables ACE to CCI translations. This gasket further provides request translation between ACE and CCI, deadlock avoidance for victim and probe collision, ARM barrier handling, and power management interactions. The present invention also provides a solution for ARM victim/probe collision handling which deadlocks the unified northbridge. These solutions includes a dedicated writeback virtual channel, probes for IO requests using 4-hop protocol, and a WrBack Reorder Ability in MCT where victims update older requests with data as they pass the requests.