Virtualization event processing in a layered virtulization architecture

The present invention relates to the field of data processing, and more particularly to the field of virtualization of resources in a data processing apparatus.

In general, the concept of virtualization of resources within a data processor allows each OS to have multiple instances of one or more operating systems (each "OS") on a single data processor. And it will be possible to carry out even if it is intended to have full and direct control over its resources. Virtualization typically uses software (eg, a virtual machine monitor, or "VMM"), where the VMM implements virtualization policies such as sharing and / or allocating physical resources across VMs ("virtualized environments"). It is implemented by presenting to each OS a "virtual machine" ("VM") that has virtual resources that the OS can completely and directly control while maintaining the system environment to do so. Each OS running on a VM and any other software that does not know the virtualized environment is referred to as "guest" or "guest software", while "host" or "host software" is virtualized. Software such as VMM that runs outside the environment and may or may not know the virtualized environment.

<p num="0003"> The processor in the data processor is, for example, in two modes, the "root" mode in which the software runs directly on hardware outside of one of the virtualization environments, and in the software's intended privilege level. You can support virtualization by running in "non-root" mode, which runs within a virtualized environment hosted by a VMM that runs in root mode. In a virtualized environment, certain events, actions and situations, such as external interrupts or external attempts to access privileged registers or resources, can be "suspended", i.e., the VMM can act to enforce virtualization policies, for example. You can let the processor exit the virtualized environment so that you can. The processor can support an instruction to set the virtual environment, an instruction to enter the virtual environment, an instruction to leave the virtual environment, and an instruction to maintain the virtual environment. May include register bits and other structures that indicate or control the virtualization capabilities of.</p>

<p num="0004"> The present invention is shown as an example, not limited to the accompanying drawings.</p><p num="0005"> Examples of devices and methods for processing virtualization events in a layered virtualization environment will be described.</p>

<figref num="1">It is a figure which shows the layered virtualization architecture which the Example of this invention can operate.</figref><figref num="2">It is a figure which shows the guest hierarchy of VMM in the layered virtualization architecture.</figref><figref num="3">It is a figure which shows the method of processing the top-down virtualization event by the Example of this invention.</figref><figref num="4">It is a figure which shows the method of processing the bottom-up virtualization event by the Example of this invention.</figref>

In the following description, a number of specific details, such as components and system configurations, may be described to provide a more thorough understanding of the invention. However, it will be appreciated by those skilled in the art that the invention can be practiced without the particular details mentioned above. Moreover, some well-known structures, circuits and the like are not shown in detail so as not to unnecessarily obscure the invention.

<p> FIG. 1 shows a layered virtualization architecture 100 in which an embodiment of the present invention can operate. In FIG. 1, the minimal platform hardware 110 can be any data processing device capable of running software from any OS or VMM. For example, the minimum platform hardware can be that of a personal computer, general purpose computer, portable computer, handheld device, set-top box or any other computing system.</p><p> The minimal platform hardware 110 includes a processor 120 and a memory 130. The processor 120 is a general purpose microprocessor (for example, a processor in the Pentium® processor family by Intel, an Itanium® processor family or another processor family, or another processor by another company), or It can be any type of processor, including digital signal processors or microcontrollers. FIG. 1 shows only one such processor 120, but the minimum platform hardware 110 may include any number of processors. The memory 130 may be a static random access memory or a dynamic random access memory, a semiconductor-based read-only memory or a flash memory, a magnetic disk memory or an optical disk memory, which can be read by the processor 120. It can be any other type of medium, or a combination of any of the aforementioned media. Bare platform hardware 110 may include any number of I / O devices and other devices.</p><p> In this embodiment, the VMM 140 is a "root mode host" because it runs in root mode on processor 120. The VMM 140 either runs on the minimal platform hardware 110 or has access to the minimal platform hardware 110 and provides a VM, an abstraction of the minimal platform hardware 110. Any software that is presented to or installed to create a VM in another way, manage the VM, and enforce virtualization policies within a virtualized environment supported by Virtualization Architecture 100. Can be a host of hardware, or hardware. In another embodiment, the root mode host can be any monitor, hypervisor, OS, or other software, firmware or hardware that can control hardware 110 on a minimal platform.</p><p> The guest can be any OS, any VMM containing another instance of the VMM 140, any hypervisor, or any application or other software. Each guest is required to access the minimum platform hardware 110 physical resources (processor and platform registers, memory, I / O devices, etc.) according to the processor and platform architecture presented in the VM. .. FIG. 1 shows VM150, 160, 170 and 180 running on guest OS 152 and guest applications 154 and 155 installed to run on VM150, guest VMM162 installed to run on VM160, and VM170. Shown with guest OS 172 installed to run and guest OS 182 installed to run on VM180. In this embodiment, all guests run in non-root mode. FIG. 1 shows 4 VMs and 6 guests, but within the scope of the present invention, any number of VMs can be created and any number of guests can be run on each VM. Can be installed.</p><p> The virtualization architecture 100 is "hierarchized" or "recursive" because one VMM, eg, VMM 140, can host another VMM, eg VMM 162, as a guest. In the tiered virtualization architecture 100, the VMM140 is the host of the virtualized environment, including the VMs 150 and 160, and is a minimal platform with no "intervening" monitor between it and the hardware 110 of the minimal platform. It is not a guest in any virtualized environment as it is installed to run on hardware 110 of. An "intervening" monitor is a monitor such as VMM162, which hosts a guest such as guest OS172, but is also the guest itself. The VMM 162 is the host of the virtualized environment including the VMs 170 and 180, but is also a guest in the virtualized environment hosted by the VMM 140. The intervening monitor (eg, VMM162) is represented as a parent guest in the specification and claims, but it acts as a parent to another VM (or VM hierarchy) and as a guest of the underlying VMM. (For example, VMM140 is the parent of VMM162 and VMM162 is the parent of guests 172 and 182).</p><p> A monitor such as VMM140 represents a guest "parent" such as OS152, guest application 154, guest application 155 or guest VMM162 when there is no monitor intervening between it and the guest. Guests are represented as "children" of the monitor. Guests can be children or parents. For example, guest VMM162 is a child of VMM140 and a parent of guest OS172 and guest OS182.</p><p> Resources accessible by guests can be classified as "privileged" or "unprivileged" resources. For privileged resources, the host (eg, VMM140) maintains ultimate control over the resource while facilitating the functionality desired by the guest. Unprivileged resources do not have to be controlled by the host and can be accessed directly by the guest.</p><p> In addition, each guest operating system has a variety of exceptions (eg page faults and general protection faults), interrupts (eg hardware interrupts and software interrupts) and platform events (eg initialization and system management interrupts). It wants to handle the event. These exceptions, interruptions and platform events are collectively and individually referred to as "events" herein and in the claims. Some of these events are "privileged", but by the host they ensure that the VM behaves properly, protects the host from guests, and protects guests from each other. Must be processed.</p><p> At any particular point in time, processor 120 may execute instructions from VMM140 or any guest, so VMM140 or guest is active and either running on processor 120 or processor. It can be the one that controls 120. Control can be transferred from the guest to the VMM140 if a privileged event occurs or the guest attempts to access the privileged resource. Transferring control from the guest to the host is referred to as "VM exit" in the specification and claims. After properly processing the event or properly facilitating access to the resource, the VMM 140 can return control to the guest. Transferring control from the host to the guest is referred to as "VM rush" in the specification and claims.</p><p> In addition to the VM exit that transfers control from the guest to the root mode host as described above, in the embodiments of the present invention, the VM exit transfers control from the guest to a non-root mode host such as an intervening monitor. I am also doing it. In the embodiments of the present invention, virtualization events (eg, those that can cause VM exit) can be classified as "top-down" virtualization events or "bottom-up" virtualization events.</p><p> A "top-down" virtualization event is made by starting with the parent of the active guest and proceeding towards the root mode host to determine which host was in control of the VM exit. Top-down virtualization events are virtualization events that begin with the action of an active guest, including the execution of virtualization instructions such as CPUID instructions within the processor's instruction family architecture in the Pentium® processor family. obtain. In one embodiment, the root mode host may have the ability to bypass top-down virtualization event processing for one or more virtualization events. In such an embodiment, the virtualization event can cause the root mode host to exit the VM even if it is treated as a top-down virtualization event for all intervening VMMs.</p><p> A "bottom-up" virtualization event is one in which the determination of which host has received control on a VM exit is made in the opposite direction, for example, from the root mode host to the parent of the active guest. A bottom-up virtualization event can be a virtualization event initiated by the operation of the underlying platform, such as a hardware interrupt or a system management interrupt. In one embodiment, processor exceptions are treated as bottom-up virtualization events. For example, the occurrence of a running page fault exception for an active guest will be evaluated in a bottom-up manner. This bottom-up process may apply to all processor exceptions, or a subset thereof. Further, in one embodiment, the VMM has the ability to inject events (eg, interrupts and exceptions) into its guests, or to induce such events in another way. In such an embodiment, the determination of which host is controlled on VM exit can be made by starting on top of the VMM that triggered the virtualization event, rather than from the root mode host.</p><p> In the embodiment of FIG. 1, the processor 120 controls the operation of the VM by the data stored in the virtual machine control structure (VMCS) 132. The VMCS132 may include one or more guest states, a VMM140 state, execution control information indicating how the VMM140 controls the operation of one or more guests, and VM exit and VM entry information. It is a structure that can contain other such information. The processor 120 reads the information from the VMCS 132, determines the execution environment of the VM, and limits its characteristics. In this embodiment, the VMCS 132 is stored in memory 130. The VMCS132 can be divided into a plurality of structures, each of which corresponds to one host or one guest, and each can be regarded as an independent VMCS.</p><p> A VMM "guest hierarchy" is a stack of software installed to run within one or more virtualized environments supported by VMM. The present invention can be implemented in a virtualization architecture in which the guest hierarchy includes pointer chains between VMCSs. These pointers are represented as "parent pointers" when pointing from a child VMCS to a parent VMCS, and as "child pointers" when pointing from a parent VMCS to a child VMCS.</p><p> FIG. 2 shows the guest hierarchy of the VMM 220 installed as a root mode host on hardware 210 on a minimal platform. The VMCS221 is the control structure of the VMM 220, but the root mode host can operate without the control structure. Guest 230 is a child of VMM 220, controlled by VMCS231. Therefore, the parent pointer (PP) 232 points to VMCS221. Guest 240 is also a child of VMM220, controlled by VMCS241. Therefore, the parent pointer 242 also points to VMCS221.</p><p> The guest 240 itself is a VMM with two children, guests 250 and 260, each with VMCS251 and 252, respectively. Both the parent pointer 252 and the parent pointer 262 point to VMCS241.</p><p> The guest's VMCS, which is active or running, is pointed to by a child pointer of its parent's VMCS. Therefore, FIG. 2 shows a child pointer 243 pointing to VMCS251 to indicate that guest 250 is active. Similarly, a guest VMCS with an active child pointer instead of a null child pointer is pointed to by its parent VMCS child pointer. Therefore, FIG. 2 shows a child pointer 223 pointing to the VMCS241. Thus, the parent pointer chain links the active guest VMCS with the root mode host VMCS via the VMCS of one of the intervening monitors, and the child pointer chain either links the root mode host VMCS. Link with the active guest VMCS via the intervening monitor VMCS.</p><p> VMCS221 is referred to as "root VMCS" herein and in the claims. In one embodiment, as mentioned above, there is no root VMCS. In one embodiment involving the root VMCS, the processing hardware may maintain a pointer to the root VMCS in internal registers and other data structures. As mentioned above, the active guest VMCS is, as used herein and in the claims, as the current control VMCS. For example, the VMCS251 is the current control VMCS while the guest 250 is active. In one embodiment, the processing hardware is internal registers and others. If the VMCS is not the parent VMCS, its child pointers such as child pointers 233, 253 and 263 can be null pointers. If the VMCS has no parent, for example, in root mode VMCS, its parent pointer, such as the parent pointer 222, can be a null pointer. Alternatively, such pointers can be omitted. In some embodiments, the "null" value of the null VMCS pointer can be zero. In another embodiment, other values can be interpreted as "null". For example, in one embodiment with a 32-bit address, the value 0xffffffff can be interpreted as null.</p><p> The VMCS for each guest in FIG. 2 indicates a bit, field, or another data structure (event bit) that indicates whether the guest's parent wants control when a particular virtualization event occurs. .. Each VMCS may contain any number of such bits that correspond to any number of virtualization events. FIG. 2 shows event bits 264, 254, 244 and 234.</p><p> Returning to FIG. 1, processor 120 includes control logic 121 that supports virtualization, including virtualization event processing in a layered virtualization architecture. The control logic 121 can be implemented in microcode, programmable logic, hard code logic or any other form of control logic within the processor 120. In another embodiment, the control logic 121 is in any form of hardware in a processor, in any device accessible by the processor, or in a processor-readable medium (eg, memory 130). , Software or hardware (eg, processor abstraction layer).</p><p> The control logic 121 includes event logic 122, evaluation logic 123, and exit logic 124. The event logic 122 can be divided into a top-down event logic 125 and a bottom-up event logic 126. The evaluation logic 123 can be divided into a top-down evaluation logic 127 and a bottom-up evaluation logic 128. The control logic 121 includes the execution of one or more micro-operations in the processor 120 to support virtualization, for example, in response to a virtualization instruction, another instruction from a host or guest, or a virtualization event. By causing the processor 120 to execute the method embodiment of the present invention, for example, the method embodiment shown in FIGS. 3 and 4.</p><p> FIG. 3 shows a method of handling a top-down virtualization event according to an embodiment of the present invention. In box 310 of the figure, the top-down event logic 125 recognizes a top-down virtualization event. For example, a guest can execute a CPUID instruction and the top-down event logic can be a decoder that decrypts the instruction.</p><p> In boxes 321 to 325, the top-down evaluation logic 127 determines whether VM exit will occur in response to a top-down virtualization event, and if so, which host will be controlled. Is determined. For example, the top-down evaluation logic 127 can be microcode within the processor microcode of the CPUID instruction.</p><p> In box 321 the active guest VMCS is identified as a child VMCS. In box 322, for example, by inspecting the child VMCS to determine if the event bit of the CPUID instruction virtualization event is set, it is determined whether the parent of the child wants control. If so, in box 330, exit logic 124 causes VM exit and control is transferred to its parent. For example, if there is a VM exit after only one path through box 322, the parent of the active guest is in control.</p><p> If the decision in box 322 is that the parent does not want control, then in box 323, for example, whether the parent is the root mode host by determining if the parent pointer of the parent VMCS is a null pointer. Is determined. If so, VM exit does not occur, and in box 324, the active guest handles the virtualization event itself, for example by allowing the CPUID instruction to execute normally. If the determination in box 323 indicates that the parent is not the root mode host, then box 325 follows the parent pointer of the child VMCS, replacing the last child VMCS and identifying the parent VMCS as the new child VMCS. Then, box 322 is repeated.</p><p> The following pseudocode also shows how to handle top-down virtualization events according to an embodiment of the present invention. In the example represented in this pseudo code, the root VMCS exists.</p><p><tables num="1"><img id="000002" he="223" wi="130" file="0005675743.tif" img-format="tif" img-content="drawing" /></tables> FIG. 4 shows a method of handling a top-down virtualization event according to an embodiment of the present invention. In box 410, bottom-up event logic 126 recognizes bottom-up virtualization events. In boxes 421-425, the bottom-up evaluation logic 128 determines in response to a bottom-up virtualization event whether a VM exit will occur, and if so, which host will be controlled. judge.</p><p> In box 421, the host VMCS associated with the bottom-up virtualization event is identified as the parent VMCS. For example, if the bottom-up virtualization event is a hardware-generated interrupt, the root mode host can be identified as the parent. Alternatively, if a bottom-up virtualization event (eg, exception, interrupt or other virtualization event) is triggered or injected by a host, that host can be identified as the parent.</p><p> In box 422, the child VMCS is identified by following the child pointer of the parent VMCS. Box 423 determines whether the parent wants control by, for example, inspecting the child VMCS to determine if a particular interrupt or interrupt type event bit is set. If so, in box 430, exit logic 124 causes VM exit and control is transferred to its parent. For example, if a root mode host is identified as a parent in box 421 and there is a VM exit only after one path through box 423, the root mode host is in control.</p><p> If the decision in box 423 is that the parent does not want control, then in box 424, for example, whether the child is an active guest by determining if the child pointer of the child VMCS is a null pointer. Is determined. If so, the VM exit does not occur, and in box 425, the active guest handles the virtualization event itself. If the determination in box 424 is that the child is not an active guest, in box 426 the child VMCS replaces the last parent VMCS and is identified as the new parent VMCS. Then box 422 is repeated.</p><p> The following pseudocode also shows how to handle bottom-up virtualization events according to an embodiment of the present invention. In the example represented in this pseudo code, there is a root VMCS.</p><p><tables num="2"><img id="000003" he="244" wi="129" file="0005675743.tif" img-format="tif" img-content="drawing" /></tables> Within the scope of the present invention, the methods shown in FIGS. 3 and 4 can be performed in various orders, the illustrated boxes can be omitted, and additional boxes can be added. Alternatively, it can be done by a combination of rearranged boxes, omitted boxes, or additional boxes. For example, the methods of FIGS. 3 and 4 can be combined with additional boxes to determine whether the recognized virtualization event is a top-down virtualization event or a bottom-up virtualization event. As another example, in box 430 of FIG. 4, the VM exit may not occur if the event is a hardware interrupt and the control bit indicates that the hardware interrupt is blocked, in which case the active. The guest can continue to run while the hardware interrupt is held in the wait state.</p><p> Some of the above descriptions are shown by algorithms and symbolic representations of operations on data bits in the registers or memory of computer systems. Descriptions and representations of such algorithms are the means used by those skilled in the art of data processing to effectively convey the essence of their work to others. Algorithms, both herein and generally, are considered as self-consistent arithmetic sequences that lead to the desired result. The operation requires a physical manipulation of the physical quantity. Although not necessarily, these quantities usually take the form of electrical or magnetic signals that can be stored, transferred, synthesized, compared and manipulated in other ways. It may sometimes prove convenient to represent these signals as bits, values, components, symbols, letters, terms, numbers, or the like, mainly for conventional reasons.</p><p> However, it should be kept in mind that these words and all similar words should be associated with the appropriate physical quantity and are merely a convenient label attached to such quantity. Unless otherwise specified, through the present invention, descriptions using terms such as "processing", "calculation", "calculation", "judgment" and the like are physically (in the register and memory of the computer system). Manipulating data represented as an electronic) quantity and other data similarly represented as a physical quantity in a computer system's registers, memory, or other such information storage device, information transmission device, or information display device. Can represent the operation and processing of a computer system or similar computer device to convert to.</p><p> Further, the processor 120 of the components designed according to the embodiments of the present invention and any other components or parts can be designed at various stages from production to simulation to manufacturing. The data that represents the design can represent the design in several ways. First, hardware can be represented using a hardware description language or another functional description language, as useful in simulation. In addition, or / or circuit-level models with logic and / or transistor gates can be generated at specific stages of the design process. Moreover, most designs have reached a level where, at a particular stage, they can be modeled with data that represent the physical arrangement of the various devices. When a conventional semiconductor manufacturing method is used, the data representing the device arrangement model can be data that defines the presence or absence of various features on various mask layers of the mask used to produce an integrated circuit.</p><p> In any representation of the design, the data can be stored in any form of machine-readable medium. A magnetic or optical storage medium such as a light wave or radio wave, memory, or disk that is modulated to transmit such information or otherwise generated can be a machine-readable medium. Any of these media can "contain" or "show" the design and other information used in the embodiments of the present invention, such as instructions in error recovery routines. When the electrical carrier that presents or contains the information is transmitted to the extent that the electrical signal is replicated, buffered, or retransmitted, a new replication occurs. Thus, the operation of a communication provider or network provider can constitute the creation of a replica of an article, eg, a carrier wave, that implements the techniques of the invention.</p><p> As described above, the device and the method for processing the layered virtualization event are disclosed. Although specific embodiments have been described and shown in the accompanying drawings, such examples are merely exemplary, not limiting, of the invention over a wide range, and the present invention illustrates and illustrates the particular configurations and embodiments described. It is understood that, but not limited to placement, various other modifications may come to mind by reviewing this disclosure. In technical areas such as those that are fast growing and whose further development is not easily predictable, the disclosed embodiments do not deviate from the principles of the disclosure of the present application or the scope of claims. Can be easily modified in placement and detail as facilitated by enabling.</p>

100 tiered virtualization architecture 110 Minimal Platform Hardware 120 processor 121 Control logic 122 Event logic 123 Evaluation logic 124 Exit logic 125 Top-down event logic 126 Bottom-up event logic 127 Top-down evaluation logic 128 Bottom-up evaluation logic 130 memory 132 VMCS 140 VMM 150 VM 152 Guest OS 154 Guest APP 155 Guest APP 160 VM 162 Guest VMM 170 VM 172 Guest OS 180 VM 182 Guest OS 210 Minimal Platform Hardware 220 guests 221 VMCS 222 PP 223 CP 230 guests 231 VMCS 232 PP 233 CP 234 event bits 240 guests 241 VMCS 242 PP 243 CP 244 Event bits 250 guests 251 VMCS 252 PP 253 CP 254 event bits 260 guests 261 VMCS 262 PP 263 CP 264 event bits