Interrupt control using guest-owned backing pages

Abstract

Techniques are disclosed for a guest virtual machine (VM) 106 to achieve programmable control of interrupts 302, 306 in a processing system using guest-owned backing pages 128. The VM programs a guest-owned backing page (e.g., a data structure in memory 103) that specifies a particular interrupt to be blocked. In response to detecting the specified interrupt, system hardware or software blocks the interrupt without executing an interrupt handler to process the interrupt. This allows the VM to protect sensitive information and program behavior with less risk that a malicious hypervisor could fail to protect the VM from, for example, unexpected or unwanted interrupts, thereby improving overall system security and predictability.

Description

[Background technology]

[0001] In classified computing environments, processing systems (e.g., servers) run multiple software programs, such as virtual machines and virtual machine managers (e.g., hypervisors), to create virtualized computing environments in which different software programs are owned by different entities. For example, in some classified computing environments, different virtual machines run by the environment are owned by different companies. The virtual machine manager (e.g., hypervisor) controls the scheduling of the different running virtual machines and provides an interface between the virtual machines and the server hardware, so that each virtual machine (VM) can operate as if it were running on its own dedicated hardware.

[0002] Because different VMs are often owned by different entities, some confidential computing systems support security features that prevent one VM from accessing data or other information associated with another VM. These security features are traditionally implemented by a virtual machine manager. However, this approach presents its own potential security problems, including allowing a malicious virtual machine manager or a malicious VM to access sensitive information of a given VM or to identify patterns in encrypted data stored by a given VM.

[0003] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0004] [Figure 1]1 is a block diagram of a processing system that supports control of interrupts based on backing pages owned by guest virtual machines (VMs), according to some embodiments. [Figure 2] FIG. 2 is a block diagram illustrating an example of the VM of FIG. 1 having different tiers associated with different trust levels, according to some embodiments. [Figure 3] 2 is a block diagram illustrating an example of the processing system of FIG. 1 that blocks and allows interrupts based on backing pages owned by guest VMs, according to some embodiments. [Figure 4] 2 is a block diagram illustrating an example of the processing system of FIG. 1 that blocks and allows interrupts based on backing pages owned by guest VMs, according to some embodiments. [Figure 5] 1 is a flow diagram illustrating a method for controlling interrupts based on backing pages owned by a guest VM, according to some embodiments. [Figure 6] FIG. 1 is a system diagram illustrating an example of data flow in a method for controlling device interrupts based on backing pages owned by a guest VM, according to some embodiments. [Figure 7] 7 is a flow diagram illustrating a method for controlling device interrupts based on backing pages owned by guest VMs using the system of FIG. 6, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1-7 illustrate a technique for a guest virtual machine (VM) to achieve programmable control of interrupts in a processing system using guest-owned backing pages. The VM programs the guest-owned backing page (e.g., a data structure in memory) that specifies a particular interrupt to be blocked. In response to detecting the specified interrupt, system hardware or software blocks the interrupt rather than executing an interrupt handler to process the interrupt. This allows the VM to protect sensitive information and program behavior with less risk that a malicious hypervisor, for example, could fail to protect the VM from unexpected or unwanted interrupts, thereby improving overall system security and predictability.

[0006] By way of example, in some cases, certain types of interrupts may cause errors or otherwise manipulate a VM to make sensitive VM data vulnerable to unauthorized access, such as by allowing execution of a malicious interrupt handler. To prevent this vulnerability, system hardware and / or software is configured to block designated interrupts based on guest-owned backing pages. Thus, in response to detecting an interrupt designated as blocked by a guest-owned backing page, the system blocks the interrupt and prevents execution of any interrupt handlers, thereby preventing unauthorized access to sensitive VM data. In some systems, interrupts are managed by a VM manager, such as a hypervisor. However, this approach is vulnerable to a malicious hypervisor. For example, a malicious hypervisor could introduce an unexpected interrupt into a VM, which could in turn disclose sensitive VM data to the hypervisor or one or more other VMs. Using the techniques herein, in some embodiments, guest-owned backing pages are owned and managed exclusively by the guest VM itself. Thus, the VM programs the guest-owned backing pages directly, thereby controlling itself which interrupts are allowed or blocked by system hardware and / or software.

[0007] To further illustrate, in some embodiments, a VM includes multiple layers, each assigned a different address space within a virtual address space associated with the VM. A security module (e.g., a security coprocessor) of the processing system executes a designated security process to designate one of the multiple layers as the VM's trusted layer. In some embodiments, the VM's trusted layer manages the VM's security operations, while other, less trusted layers perform other operations, such as running an operating system or other software. To protect guest-owned backing pages, the system's hardware and / or software executes instructions to program (e.g., modify) guest-owned backing pages only if those instructions are issued by the VM's trusted layer, i.e., only if the instructions are issued from an address space corresponding to the trusted layer. This allows the VM's trusted layer to control the blocking of interrupts triggered by other layers of the VM, such as certain interrupts triggered by applications associated with the VM's less trusted layers.

[0008] 1 illustrates a processing system 100 that supports control of interrupts by a VM using guest-owned backing pages, according to some embodiments. Processing system 100 is generally configured to execute a set of instructions (e.g., a computer program) for performing tasks on behalf of an electronic device. Accordingly, in different embodiments, processing system 100 is part of any of a variety of electronic devices. For purposes of explanation, processing system 100 is part of an electronic device that implements a confidential computing environment, such as a server. However, in other embodiments, processor 100 is part of a desktop computer, a laptop computer, a tablet, a game console, etc.

[0009] To implement the secure computing environment and execute a set of instructions, processing system 100 includes processor 101 and memory 103. In some embodiments, processor 101 is a general-purpose processor, such as a central processing unit (CPU), that includes hardware structures configured to retrieve and execute a set of instructions. Memory 103 includes one or more memory devices configured to store and retrieve data based on commands (e.g., store and load commands) received from processor 101. Thus, in different embodiments, memory 103 is random access memory (RAM), non-volatile memory (NVM), hard disk memory, etc., or any combination thereof.

[0010] To execute the instruction set, processor 101 includes processor core 102, security module 104, and secure hardware 110. It should be understood that in some embodiments, processor 101 includes additional hardware for executing the instructions and for performing operations based on those instructions, such as additional processor cores, additional processing units (e.g., one or more graphics processing units), one or more controllers (e.g., memory controllers and input / output controllers), etc.

[0011] Processor core 102 includes one or more instruction pipelines that include multiple stages for executing instructions in a pipelined manner. Thus, for example, in some embodiments, the instruction pipeline of processor core 102 includes a fetch stage, a decode stage, a dispatch stage, one or more execute stages (with one or more corresponding execution units), a retire stage, etc. Processor core 102 also includes or has access to memory structures and other hardware (not explicitly shown in FIG. 1 ) that support the execution of instructions. For example, in some embodiments, processor core 102 includes or has access to one or more cache structures for storing data used in the execution of instructions.

[0012] In some embodiments, processor 101 is a simultaneous multithreading (SMT) processor. Thus, in some embodiments, processor core 102 and other hardware of processor 101 are configured to simultaneously execute program threads (referred to herein simply as "threads") by sharing hardware resources among the simultaneously executing threads. For example, in at least some embodiments, different threads execute simultaneously in a given stage of an instruction pipeline of processor core 102 by sharing the hardware resources of that pipeline stage. As another example, in some embodiments, different threads execute simultaneously in processor 101 by sharing portions of the cache of processor core 102. For purposes of explanation, when two or more threads are executing simultaneously in processor 101, processor 101 is said to be in SMT mode.

[0013] Security module 104 is a set of hardware structures generally configured to create, monitor, and maintain a security environment for processor 101. For example, in at least some embodiments, security module 104 is configured to manage the boot process of processor 101, initialize security-related mechanisms of processor 101, register different layers of VMs with different trust levels, monitor processing system 100 for suspicious activity or interrupts, and implement appropriate responses. In some embodiments, security module 104 includes a microcontroller, a cryptographic coprocessor (CCP) for encrypting and decrypting data, local memory and local registers, e.g., for storing cryptographic keys, and an interface for interacting with memory 103, an I / O controller of processor 101, and configuration registers of processor 101. In some embodiments, security module 104 includes environmental management control hardware capable of checking the environment and security to ensure that processor 101 is operating in accordance with specified security parameters.

[0014] Secure hardware 110 includes hardware and associated microcode of processor 101 that supports processor core 102 in executing instructions but is not accessible or modifiable by software executing on processor core 102. For example, in some embodiments, secure hardware 110 includes hardware that implements finite state machines, hardwired control unit operations, and other hardware that performs at least some operations generated by processor core 102 based on executing instructions. However, because the operations of secure hardware 110 are not accessible or modifiable by executing software, secure hardware 110 can provide security functions in the course of performing operations, as described further herein, and those functions are not subject to unauthorized modification. For example, secure hardware 110 can control the scheduling of software executing on processor core 102.

[0015] As described above, processing system 100 is generally configured to implement a confidential computing environment, particularly by running multiple VMs (e.g., VM 106), also referred to as guests, and hypervisor 107, also referred to as a host, to manage the execution of the multiple VMs. Because different VMs and, at least in some cases, hypervisor 107, are often owned by different entities, processing system 100 implements security features to protect data of a given VM from access by other software, such as another VM or hypervisor 107. For example, processing system 100 implements VM data security by implementing secure area 120 of memory 103 that stores encrypted data. In particular, processor 101 is configured to encrypt designated data of each VM according to a corresponding private encryption key and store the encrypted data in secure area 120. Because the data is encrypted, data of one VM is protected from unauthorized access by other VMs and hypervisor 107. In at least some embodiments, cryptographic keys for the VM are managed by security module 104, and data encryption and decryption for the VM is performed by a dedicated hardware encryption / decryption module (not shown) in the memory controller (not shown) of processor 101.

[0016] To further explain by way of example, in the illustrated embodiment, secure area 120 stores two data blocks for VM 106: control information 121 and VM storage area (VMSA) 122. Control information 121 stores control information for VM 106, and VMSA stores data for software programs executed by VM 106. In response to a request by VM 106 to store information (e.g., in response to VM termination), processor 101 encrypts the information using an encryption key associated with VM 106 and stores the information in the corresponding block (either control information 121 or VMSA 122). Similarly, in response to a request by VM 106 to retrieve information from secure area 120, processor 101 obtains the requested information from the corresponding block, decrypts the information using an encryption key associated with VM 106, and provides the decrypted information to VM 106.

[0017] To provide further security for VM data, in some embodiments, security module 104 is configured to associate different layers of VM 106 with different trust levels. FIG. 2 illustrates an example of a VM 106 having different layers, according to some embodiments. In the illustrated example, VM 106 includes N layers (where N is an integer), including layer 230, layer 231, and additional layers up to Nth layer 232. In some embodiments, each of layers 230-232 corresponds to a different address space. For example, in some embodiments, VM 106 employs a virtual address space to specify the memory location of each software instruction and each data operand for different software programs and operations of VM 106. Each of layers 230-232 corresponds to a different portion of VM 106's virtual address space. Thus, the virtual address space of layer 231 corresponds to the virtual address space of the instructions and data operands of layer 231's programs and operations. However, in some embodiments, VM 106 does not include different layers, such that all components of VM 106 effectively operate at a high level of trust.

[0018] 1 , in at least some embodiments, layers 230-232 are assigned different trust levels by security module 104. For example, in some embodiments, before VM 106 is allowed to run on processing system 100, VM 106 undergoes a provisioning process. During the provisioning process, VM 106 provides authentication information, such as one or more security keys, to security module 104 to register layers 230-232 with different trust levels. In response to verification of the authentication information, security module 104 assigns each of layers 230-232 the requested trust level.

[0019] In at least some embodiments, the trust levels of layers 230-232 are enforced by secure hardware 110. For example, in some cases, one or more specified operations, such as modifying a page table of VM 106, are permitted to be performed only by layers 230-232 with a threshold level of trust. In response to an instruction to perform a specified operation, secure hardware 110 identifies which of layers 230-232 issued the instruction, for example, based on the virtual address of the instruction. If the identified layer has the required trust level, secure hardware executes the instruction. Otherwise, secure hardware 110 does not execute the instruction. In this manner, secure hardware 110 ensures that the instruction is executed only by layers of VM 106 with the specified trust level. For purposes of illustration, assume that layer 230 of VM 106 is registered by security module 104 as having the highest trust level, layer 231 is registered as having a lower trust level, and so on, with layer 232 having the lowest trust level.

[0020] 1 , processing system 100 includes an input / output memory management unit (IOMMU) that manages input / output requests associated with one or more devices 126 as they interact with processor 101 and / or memory 103. To further enhance the security of processing system 100, in some embodiments, secure hardware 110 and / or IOMMU 124 are configured to block specified interrupts based on guest-owned backing pages 128 or pointers to guest-owned backing pages stored in VMSA 122. For example, in some embodiments, guest-owned backing pages in VMSA 122 specify particular interrupts that should be blocked because an interrupt handler associated with the interrupt is expected to be able to disclose secure information in processing system 100. Secure hardware 110 and / or IOMMU 124 are configured to identify, in response to the interrupt, whether the interrupt should be blocked. If the interrupt should not be blocked, secure hardware 110 proceeds to execute the interrupt handler and / or IOMMU 124 notifies VM 106 of the interrupt. If the guest-owned backing page indicates that the interrupt should be blocked, secure hardware 110 does not execute the interrupt handler and / or IOMMU 124 does not notify VM 106 of the interrupt, and in some embodiments, IOMMU 124 notifies security module 104 and / or VM 106 that the interrupt was blocked, for example, by generating an exception. In response, in some embodiments, security module 104 takes corrective action, such as instructing processor 101 to stop executing software or sending an error message to processor 101, VM 106, or another processing system (not shown).

[0021] Guest-owned backing page 128 is a programmable data structure. Thus, by storing specific values ​​in backing page 128 (also referred to as programming backing page 128), VM 106 can designate specific interrupts for blocking by secure hardware 110 and / or IOMMU 124. In some embodiments, backing page 128 is programmable only by VM 106 or a trusted layer (e.g., layer 230) of VM 106. In the example shown in FIG. 1 , VM 106 programs backing page 128 by storing control information in backing page 128. Thus, in some embodiments, interrupts to be blocked are designated by VM 106 or trusted layer 230 via programming backing page 128 with control information. This provides VM 106 creators with flexibility to protect secure information from potential security breaches resulting from specific interrupts. In some embodiments, backing page 128 includes a general per-vector mask or control that allows or blocks specific vectors, and individual per-vector masks or controls that allow or prevent vectors from being triggered by the hypervisor. Additionally, in some embodiments, VM 106 can program backing page 128 directly and / or exclusively rather than through a request to hypervisor 107, thus further enhancing the security of VM 106.

[0022] An example of VM 106 programming backing page 128 to block specified interrupts in processor 101, according to some embodiments, is shown in Figure 3. In the illustrated example, VM 106 or VM 106's trusted layer 231 programs guest-owned backing page 128 with control information. In the example of Figure 3, the control information in backing page 128 specifies that particular interrupts or types of interrupts should be blocked and / or allowed. However, in other embodiments, the control information specifies, for example, that all interrupts, particular interrupts, particular types of interrupts (maskable or non-maskable interrupts, exceptions, etc.), one or more interrupts of different corresponding types, interrupts associated with one or more particular devices, and / or interrupts associated with one or more particular types of devices are to be blocked.

[0023] After the control information is stored in backing page 128, either hypervisor 107 or devices 126 trigger an interrupt 302, which is handled by interrupt handling logic 304. Based on the control information in backing page 128, secure hardware 110 blocks interrupt 302, and in particular prevents the interrupt from being introduced into VM 106. Furthermore, after the control information is stored in backing page 128, one or more of devices 126 triggers a second interrupt 306, which is handled by interrupt handling logic 308. Based on the control information in backing page 128, secure hardware 110 does not block interrupt 306, but instead stores an indication of the interrupt, for example, in memory 103, and notifies VM 106 of the interrupt. 3, VM 106 can control which types of interrupts are blocked and / or allowed by processor 101, and which devices or types of devices can provide interrupts to VM 106. VM 106 can therefore implement any of a variety of security protections itself, particularly when the hypervisor is untrusted, providing VM 106 with the flexibility to adapt to changing security needs and environments.

[0024] In some embodiments, in addition to, or rather than, controlling interrupts using secure hardware 110 of processor 101, IOMMU 124 is configured to control interrupts based on guest-owned backing pages. An example according to some embodiments is shown in FIG. 4. In the illustrated example, VM 106 programs backing page 128 to store control information indicating that a particular interrupt or type of interrupt should be blocked and / or allowed. After the control information is stored in backing page 128, one of devices 126 triggers an interrupt 402, which is handled by interrupt handling logic 404. Based on the control information in backing page 128, IOMMU 124 blocks interrupt 402, specifically preventing the interrupt from being introduced to VM 106. Furthermore, after the control information is stored in backing page 128, one or more of devices 126 triggers a second interrupt 406, which is handled by interrupt handling logic 408. Based on the control information in backing page 128, IOMMU 124 does not block interrupt 406, but instead stores an indication of the interrupt, e.g., in memory 103, and notifies VM 106 of the interrupt. Thus, in the example of Figure 4, VM ​​106 can control which types of interrupts are blocked and / or allowed, and which devices or types of devices can provide interrupts to VM 106. Thus, VM 106 can itself implement any of a variety of security protections, providing VM 106 the flexibility to adapt to changing security needs and environments, especially when the hypervisor is untrusted.

[0025] 3 and 4 are merely examples, and it should be understood that in other embodiments, VM 106 stores control information reflecting different combinations of interrupts, layers of VM 106, devices 126, etc., to control which types of interrupts are blocked for VM 106 or for each layer of VM 106, which types of devices or which particular devices can generate interrupts for VM 106, etc. Thus, for example, in some embodiments, VM 106 or trusted layer 231 sets control information in backing page 128 such that a set of interrupts associated with a particular device is blocked by secure hardware 110 and / or IOMMU 124.

[0026] 5 is a flow diagram illustrating a method 500 for controlling interrupts based on backing pages owned by a guest VM, according to some embodiments. For purposes of explanation, the method 500 is described with respect to an exemplary embodiment in the processing system 100 of FIG. 1. However, it will be understood that in other embodiments, the method 500 is performed in a processing system having a different configuration than the processing system 100.

[0027] At block 502, backing page 128 receives interrupt control information from VM 106. At block 504, secure hardware 110 or IOMMU 124 receives an indication of an interrupt associated with VM 106, for example, from either processor 101 or device 126, respectively. In response, at block 506, secure hardware 110 or IOMMU 124 checks guest-owned backing page 128 in VMSA 122 to determine whether the indicated interrupt should be blocked. If the interrupt should not be blocked, method flow moves to block 508, where secure hardware 110 executes an interrupt handler corresponding to the indicated interrupt, or IOMMU 124 notifies VM 106 of the interrupt. If, at block 506, secure hardware 110 or IOMMU 124 determines that the interrupt should be blocked, method flow moves to block 510, where secure hardware 110 or IOMMU 124 blocks the interrupt. For example, secure hardware 110 may prevent execution of an interrupt handler, thereby protecting sensitive information associated with VM 106, or IOMMU 124 may prevent notification of the interrupt to VM 106, and in some embodiments, generate an exception in the VM to indicate that the interrupt has been blocked.

[0028] 6 is a system diagram illustrating an example of data flow in a processing system 600 capable of controlling device interrupts based on backing pages owned by guest VMs, according to some embodiments. In some embodiments, system 600 is a subset of processing system 100 of FIG. 1 , and an IOMMU, such as IOMMU 124, performs operations associated with system 600. In some embodiments, system 600 includes a device table 602 managed by a hypervisor, such as hypervisor 107, and a secure device table 604 managed by a secure processor, such as security module 104, and modifiable by a guest VM, such as VM 106. In some embodiments, system 600 further includes an interrupt remapping table 606 managed by hypervisor 107, and a guest-owned interrupt remapping table 608 managed by guest VM 106. In some embodiments, the system further includes a VM identification table 610 controlled by hypervisor 107, and a backing page, such as backing page 128, controlled by guest VM 106. In some embodiments, to reduce dependency on hypervisor 107 and increase security, guest interrupt remapping table 608 and backing page 128 are modifiable only by VM 106. In some embodiments, guest interrupt remapping table 608 includes controls that effectively allow or prevent interrupt vectors from being triggered by I / O devices assigned to VM 106. As shown in FIG. 6 , at a high level, system 600 detects interrupts 615 and performs actions to safely handle interrupts 615, such as ensuring that only interrupts designated as allowed by the VM in backing page 128 are allowed to be passed to the VM, that interrupts designated as blocked are blocked for the VM, and / or which particular devices or types of devices can or cannot generate interrupts for the VM, etc.However, since the system 600 of FIG. 6 is better understood in conjunction with FIG. 7, the method of FIG. 7 is described below along with further details of the exemplary system 600.

[0029] 7 is a flow diagram illustrating a method 700 for controlling device interrupts based on backing pages owned by a guest VM using the system of FIG. 6, according to some embodiments. As shown in FIG. 7, in some embodiments, method 700 begins with an IOMMU, such as IOMMU 124 of FIG. 1, detecting an interrupt, such as interrupt 615 of FIG. 6. After detecting interrupt 615, IOMMU 124 fetches device table entry 630 from device table 602 at block 704 and fetches secure device table entry 632, i.e., an address indicating the location of guest-owned interrupt remapping table 608, from secure device table 604 at block 706. At block 710, in some embodiments, IOMMU 124 flushes direct memory access (DMA) channels, and at block 712, in some embodiments, translates secure device table entry 632 from a guest physical address to a system physical address. In some embodiments, to translate secure device table entry 632 from a guest physical address to a system physical address, IOMMU 124 obtains a guest virtual vector 634 for interrupt 615 by indexing interrupt remapping table 606 based on device table entry 630 and interrupt 615. After obtaining guest virtual vector 634 for interrupt 615, IOMMU 124 translates secure device table entry 632 from a guest physical address to a guest interrupt remapping table system physical address 636 in guest-owned interrupt remapping table 608 based on guest virtual vector 634.

[0030] At block 714, IOMMU 124 performs a memory ownership check on the translated guest interrupt remapping table system physical address 636 of guest-owned interrupt remapping table 608 to ensure that the target VM owns that portion of memory. If the target VM does not own that portion of memory and / or the device triggering interrupt 615 is not assigned to the target VM, in some embodiments, IOMMU 124 aborts the method at block 716 and, in some embodiments, generates an exception to notify the target VM that the interrupt has been blocked. However, if the target VM does own that portion of memory, method 700 proceeds to block 718, where IOMMU 124 fetches the guest interrupt remapping table entry from guest-owned interrupt remapping table 608. In some embodiments, if no mapping is configured, the host translated interrupt is mapped to a guest vector or the interrupt is blocked, and based on the guest interrupt remapping table entry in the guest owned interrupt remapping table 608, the IOMMU 124 identifies the guest physical destination 638 and backing page location 640 and generates the guest physical vector 642 based on the interrupt 615.

[0031] At block 720, the IOMMU 124 translates the backing page location 640 from a guest physical address to a system physical address. At block 724, the IOMMU 124 performs a memory ownership check on the translated backing page location in the backing page 128 to ensure that the target VM owns that portion of memory. If the target VM does not own that portion of memory, in some embodiments, the IOMMU 124 aborts the method at block 726 and, in some embodiments, generates an exception to notify the target VM that the interrupt has been blocked. However, if the target VM does own that portion of memory, the method 700 proceeds to block 728, where the IOMMU 124 stores an index of the interrupt 615 in the backing page 128.

[0032] Substantially concurrent with the operation of block 720, at block 722, IOMMU 124 fetches the VM identification information from VM identification table 610 based on guest physical destination 638 and the VM identification table location 644 retrieved from interrupt remapping table 606. In some embodiments, IOMMU 124 obtains the VM identification table location 644 by indexing interrupt remapping table 606 based on device table entry 630 and interrupt 615. After IOMMU 124 fetches the VM identification information at block 722 and stores an indication of the interrupt 615 in backing page 128 at block 728, IOMMU 124 notifies the target VM of the interrupt 615 at block 620, for example, by sending a doorbell notification 646 to the target VM. If the target VM is not currently running, in some embodiments, IOMMU 124 requests hypervisor 107 to schedule a notification for the VM so that hypervisor 107 will notify the target VM of an interrupt the next time the target VM runs. Although not shown in FIG. 7 for clarity, in some embodiments, one or more of the “fetch” blocks (e.g., blocks 704, 706, 708, 718) include caching routines that allow IOMMU 124 to cache fetched information for later use to speed up processing.

[0033] As disclosed herein, in some embodiments, a method includes controlling interrupts in a virtualized computing environment based on a guest-owned backing page. In one aspect, the controlling includes receiving a request from a virtual machine to store control information in a backing page to block the interrupt at the processor, and blocking the interrupt in response to the request and in response to detecting the interrupt. In another aspect, the control information specifies a particular type of interrupt. In yet another aspect, the control information specifies an interrupt associated with a particular device. In yet another aspect, the control information specifies an interrupt associated with a particular type of device.

[0034] In one aspect, blocking the interrupt includes generating an exception. In another aspect, blocking the interrupt includes blocking the interrupt at a processor. In yet another aspect, blocking the interrupt includes blocking the interrupt at a memory management unit. In yet another aspect, the method includes encrypting the guest-owned backing page.

[0035] In some embodiments, the processor is configured to implement a virtualized computing environment, the virtualized computing environment configured to control interrupts using guest-owned backing pages. In one aspect, to control the interrupts, the virtualized computing environment is configured to receive a request from the virtual machine to store control information in the backing page to block the interrupt at the processor, and to block the interrupt in response to the request and in response to detecting the interrupt. In another aspect, the control information specifies a particular type of interrupt. In yet another aspect, the control information specifies an interrupt associated with a particular device.

[0036] In one aspect, the control information specifies an interrupt associated with a particular type of device. In another aspect, blocking the interrupt comprises generating an exception. In yet another aspect, blocking the interrupt comprises blocking the interrupt at a processor. In yet another aspect, blocking the interrupt comprises blocking the interrupt at a memory management unit. In another aspect, the guest-owned backing page is encrypted.

[0037] In some embodiments, the memory management unit is configured to control interrupts in the virtualized computing environment using guest-owned backing pages. In one aspect, the memory management unit is further configured to control interrupts in the virtualized computing environment using a guest-owned interrupt remapping table.

[0038] A computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0039] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s). The executable instructions stored on the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0040] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.

[0041] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. controlling interrupts in a virtualized computing environment based on a guest-owned backing page; method.

2. The controlling comprises: receiving a request from a virtual machine to store control information in the guest-owned backing page to block interrupts on a processor; and blocking the interrupt in response to the request and in response to detecting the interrupt.

10. The method of claim 1.

3. the control information specifying a particular type of interrupt; The method of claim 2.

4. the control information specifying an interrupt associated with a particular device; The method of claim 2.

5. the control information specifying an interrupt associated with a particular type of device; The method of claim 2.

6. blocking the interrupt includes generating an exception.

3. The method of claim 2.

7. blocking the interrupt includes blocking the interrupt in a processor. The method of claim 2.

8. blocking the interrupts includes blocking the interrupts in a memory management unit. The method of claim 2.

9. encrypting the guest-owned backing page; The method of any one of claims 1 to 8.

10. 1. A processor configured to implement a virtualized computing environment, comprising: the virtualized computing environment is configured to control interrupts using guest-owned backing pages; Processor.

11. The virtualized computing environment, in order to control the interrupts, receiving a request from a virtual machine to store control information in the guest-owned backing page to block interrupts on a processor; In response to the request and in response to detecting the interrupt, blocking the interrupt; configured to: The processor of claim 10.

12. the control information specifying a particular type of interrupt; The processor of claim 11.

13. the control information specifying an interrupt associated with a particular device; The processor of claim 11.

14. the control information specifying an interrupt associated with a particular type of device; The processor of claim 11.

15. blocking the interrupt includes generating an exception. The processor of claim 11.

16. blocking the interrupt includes blocking the interrupt in a processor. The processor of claim 11.

17. blocking the interrupts includes blocking the interrupts in a memory management unit. The processor of claim 11.

18. the guest-owned backing page is encrypted; A processor according to any one of claims 10 to 17.

19. A memory management unit configured to control interrupts in a virtualized computing environment using guest-owned backing pages.

20. the memory management unit is configured to control interrupts within the virtual computing environment using a guest-owned interrupt remapping table.

20. The memory management unit of claim 19.

Images