intel 虚拟化文档 1
3 VMX non-root operation 3.1 Instructions that cause vm exit 3.1.1 Instructions That Cause VM Exits Unconditionally 20 3.1.2 Instructions That Cause v M Exits Conditionally 21 3.2 Other causes of VM exits 3 Changes to instruction behavior in VMX non-root operation... 25 3.4 Other Changes in VMX non-root operation 28 3.4.1 Event blockin 28 3.4.2 Treatment of Task Switches 4 Memory Virtualization 29 4.1 Processor Operating Modes Memory Virtualization 29 4.2 Guest Host Physical Address Spaces 29 4.3 Virtualizing Virtual Memory by Brute Force 4.4 Alternate Approach to Memory Virtualization 5 Handling interruptions in VMM 32 5.1 VMX andling interrupts 5.2 External interrupt virtualization 35 5.2.1 Virtualization of Interrupt Vector pace 5.2.2 Control of Platform Interrupts 37 5.2.3 Examples of Handling of External Interrupts 39 A APPENDIX: First steps in programming a VMM 42 A 1 Discovering support for VMX 42 A 2 Enabling and entering VMX operation 42 A 3 Software Access to the vmcs and related structures 42 A.3.1 Software Access to the Virtual-Machine Control Structure 42 A.3.2 VMREAD, VMWRITE, alld Encodings of VMCS Fields. 43 A 3.3 Software Access to Related structures A.3.4 VMXON Region 43 4.3.5 Using VMClEAR to initialize a vMCs region A. 3. 6 VMCs states A 4 Supporting processor operating modes in guest invironments A.4.1 Emulating guest Execut 46 A.5 Using vmx instructions 46 A6 VMM setup tear down 46 A 7 Preparation and launching a virtual machine 47 A 8 Handling of VM exits 48 A.8.1 Handling VM Exits Due to Exceptions 49 A 9 Multiprocessor considerations A.g.1 Initialization 50 A 9. 2 Moving a VMCS Between Processors 10 Perforin 52 1 Background, motivation and introduction to Intel virtualization extensions 1.1 Challenges to virtualizing Intel architecture Established and emerging applications motivate strong support for virtualiza tion in both server and client computing systcms. Unfortunately, thc IA-32 and Itanium architectures impose many challenges to providing such support Software techniques exist that address some of those challenges Intel microprocessors provide protection based on the concept of a. 2-bit privilege level, using 0 for most-privileged software and 3 for the least privileged The privilege level deterInlines whether privileged instructions, which control basic CPU functionality, can execute without fault; it also controls address space accessibility based on the configuration of the processor's page tables and, for IA-32, segment registers. Most IA software uses only privilege levels 0 and 3, as Figure la illustrates. For an Os to control the CPU, some of its components must run with privilege level 0. Beca use a VMM cannot a llow a guest OS such control, a guest OS cannot execute at privilege level 0. Thus, IA-based V MMs must use ring deprivileging, a technique that runs all guest oftware at a privilege level greater than 0. A VM could deprivilege a guest OS Ning it either at privilege level 1(the 0/1 3 model) or at privilege level 3 (the 0/3/3 model Figures 1b and lc illustrate thcse choices. Although thc 0/1/3 modcl sup ports simpler VMMs, it cannot be used on IA-32 processors for guests in 64-bit mode. The 64-bit mode is part of Intel's EM64T(Extended Memory 64 Tech nology), the 64-bit extension to IA-32. Ring deprivileging causes numerous virtualization challenges. Intel virtual techllology extensions (vt-x) solv tualization challenges in part by allowing guest software to run at its intended privilege level. Guest software is constrained, not by privilege level, but be causc-for VT-x it runs in VMX non-root opcration. Figurc 1d illustratcs this usage l.l.l Ring aliasing Ring aliasing refers to problems that arise when software is run at a privilege level other than the level for which it was written. An example in IA-32 is the PUSH instruction(which pushes its operand on the stack)when executed with the CS register(part of which is the current privilege level). a guest OS could casily dctcrminc that it is not running at privilege lcvcl 0 1.1.2 Addrcss-spacc comprcssion Operating syst ems expect to have access to the processor's fulll virtual address space, known as the linear-address space in IA-32. A VMM must reserve for itself some portion of the guests virtual-address space. The VMM could run ntirely within the guest's virtual-address space, which allows it easy access to guest data, although the VMM's instructions and data structures might use a substantial amount of the gucst's virtual-address spacc. Alternatively, the VMM could run in a scparatc address spacc, but cven in that casc the vml must usc a minimal amount of the guest's virtual-address space for the control structures 3 3 Applications 3 Guest applications 1 Guest operating syster 0: Operating system 01 VM monitor 3i Guest applicati Guest operating systeIn o Guest operating system 0: WM monitor 0: VM monitor (d) Figure 1: rings rings rings that manage transitions between guest software and the VMM. For IA-32. these structurcs includc the idt and thc gdt. which reside in thc lincar-addrcss space. Thc VMM must prevent gucst access to thosc portions of the guest's virtual-address space that the VMM is using. Otherwise, the VMl's integrity could be compromised if the guest can write to those portions, or the guest could detect that it is running in a virtual machine if it can read them. guest attempts to access these portions of the address space inust generate transitiOns to the VMM, which can emulate or otherwise support them. The term address space compression refers to the challenges of protecting these portions of the virtual-address space and supporting guest accesses to them 1.1. 3 Nonfaulting access to privileged state Privilege-based protection prevents unprivileged soft ware from accessing certain components of CPU state. In most cases, attempted accesses result in faults allowing a vMm to emulate the desired guest instruction. However, the IA 32 architecture includes instructiOns that access privileged state anld do not fault when executed with insufficient privilege. For example, the IA-32 regis ters GDTR, IDTR, LDTR, and TR contain pointers to data structures that control CPU operation. Software can execute the instructions that write to, or load. these registers (LGDT, LIDT, LL.DT; and TTR) only at privilege level 0 Ilowever. software can execute the instructions tha.t, read. or store. from these registers (SGDT, SIDT, SLDT, and STR)at any privilege level. If the VMM Inlaintails these registers with unexpected values, a guest OS using the latter instructions could determine that it does not have full control of the cpu 1.1.4 Adverse impacts on gucst transitions Ring deprivileging can interfere with the effectiveness of facilities in the IA-32 architecture that accelerate the delivery and handling of transitions to Os sof ware. The IA-32 SYSENTER and SYSEXIT instructions support low-latency system calls. SYSENTER always effects a transition to privilege level 0, and SYSEXIT Will fault if executed outside that privilege level. Ring deprivileging thus has the following implic Executions of SYSENTER by a guest application will cause a transition to the VMM and not to the guest OS. The VMM must thus emulate every guest execution of SYSENTER Execution of SYseXIt by a guest os will cause a fault to the VmM. Thus, the VMM must emulate every guest execution of SYSEXIT 1.1.5 Interrupt virtualization Providing support for external interrupt s, especially regarding interrupt mask- ing, presents some specific challenges to VMM design. The IA-32 architecture provides mechanisms for masking external interrupts, preventing their deliv ery when the Os is not ready for them. IA-32 uses the interrupt Hag(IF)in the eFlags register to control interrupt Illasking A VMM will likely illaI age external interrupts and deny guest software the ability to control interrupt masking. Existing protcction mcchanisms allow such denial of control by cnsur ing that guest attempts to control interrupt masking will fault in the context of ring deprivileging. Such faulting can cause problems because some opera.t- ing systems frequently mask and unmask interrupts. Intercepting every guest attempt to do so could significantly affect system performance. Even if it were possible to prevent guest ModificationS of interrupt Illaskiug without intercepting each attempt, challenges would remain when a vMM has a virtual interrupt"to deliver to a guest. A virtual interrupt should be delivered only when the guest has unmasked interrupts. To deliver virtual interrupts in a timely way, a VMM should intercept some, but not all, attempts by a guest to modify interrupt masking. Doing so could signicantly complicate the design of a Vmm 1.1.6 Ring compression Ring deprivileging uses translation privilege-based mechanisms to protect the VMM from guest software. IA-32 includes two such mechanisms: segment limits and paging Bccausc segment limits do not apply in 64-bit modc, paging must be used in this mode. Because IA-32 paging does not distinguish privilege levels 0-2, the guest OS must run at privilege level 3. Thus, the guest OS will run at the same privilege level as guest applications and will not be protected from them. This problem is called ring compression 1.1.7 Access to hidden state Some components of IA-32 CPU state are not represented in any software accessible register. Examples include the hidden descriptor caches for the seg Inelt registers. A seginent-register load copies a referenced descriptor(froin the GDT or LDT) into this cache, which is not modified if software later writes to the descriptor tables. IA-32 does not provide mcchanisms for saving and restoring these hidden components of a guest context when changing VMs or for preserving them while the VMM is running 1.2 Addressing virtualization challenges in software To address the virtualization challenges that the Ia-32 architecture presents VMM designers have developed creative solutions that modify guest software (source or binary ). There are examples of VMMs that use sourcelevel mod- ifiations ill a teclmique called paravirtualizatiOll. Developers of these VMMs Modify a guest-os kernel and its device drivers to create all interface that is easier to virtualize. Paravirtualization offers high performance and does not rcquirc making changes to gucst applications. A disadvantagc of paravirtual ization is that it limits the range of supported operating systems. For example, Xen cannot currently support an opera ting system t hat, its developers have not modified, such as Microsoft Windows A VMM can support legacy operating systems by making modifications di rectly to guest-OS binaries. VMMs that use such binary translation techniques include those developed by vMware as well as Virtual PC and Virtual Server from Microsoft. Such VMMs support a broader range of operating systems, albeit with higher performance overheads, than VMMs that usc paravirtualiza A central design goal for Intel Virtualization 'Technology is to eliminate the need for CPU paravirtualization and binary translation techniques and thereby enable the implementation of VMMs that can support a broad range of unmod ified guest operating systells while Maintaining high levels of perforimlallce 1.3 Intel Virtualization Technology This section describes the basics of virtual machine architecture and an overview of the virtual-machine extensions(VMX)that support virtualization of proces sor hardware for multiple software environments 1.3.1 Virtual machine Architecture Virtual-machine extensions define processor-level support for virtual machines on IA-32 processors 'Two principal classes of software are supported. machines Virtual-machinc monitors (VMM): A VMM acts as a host and has full con trol of the processor(s) and other platform hardware. A VMM presents guest software(see next paragraph) with an abstraction of a virtual pro- cessor and allows it to execute directly on a logical processor. A VMM is able to retain selective control of processor resources, physical memory, interrupt lllanagelnlent. and I/ o 6 Guest software: Each virtual machine(VM)is a guest software environ ment that supports a stack consist ing of operating system(Os) and ap plication software. Fach operates independent ly of ot her virtual machines and uses on the same interface to processor(s), memory, storage, graphics and I/o provided by a physical platform. The software stack acts as if it were running on a platform with no VMM. Software executing in a virtual machine must operate with reduced privilege so that the vMM can retain control of platform rcsourccs 1.3.2 Introduction to VMX operation Processor support for virtua lization is provided by a form of processor operation called VMX operation. There are two kinds of VMX operation: VMX root op eration and VMX lOll-root operation. In general, a VMM will run il VMX root operation and guest software will run in VMX non-root operation. Transitions between VMX root operation and vMX non-root operation are called VMX transitions. There are two kinds of VMX transitions. Transitions into VmX non-root opcration arc called VM entries. Transitions from VMX non-root op eration to VMX root operation are called vM exits Processor behavior in VMX root operation is very much as it is outside VMX operation. The principal differences are that a set of new instructions (the VMX instructions) is available and that the values that can be loaded into certain control registers are linited Processor behavior in VMX non-root operation is restricted and modified to facilitate virtualization. Instcad of thcir ordinary opcration, ccrtain instructions (including the new VMCALL instruction) and events cause VM exits to the VMM. BecauIse these VM exits replace ordinary behavior, the functionality of software in vMx non-root operation is limited. It is this limitation that allows the VMM to retain control of processor resources. There is no software visible bit whose setting indicates whether a logical processor is iI VMX loLl root operation. This fact may allow a vmm to prevent guest software from ning that it BecauseⅤMXop placcs restrictions cvcn on softwarc running with currcnt privilege lcvcl(CPL)O guest software can run at the privilege level for which it was originally designed This capability may simplify the development of a VMM 1.3.3 Life Cycle of vMM software Figure 2 illustrates the life cvcle of a VmM and its guest software as well as the interactions between them. The following items summarize that life cycle: Software enters VMX operation by executing a. VMXON instruction Using VM entries. a VMM can then enter guests into virtual machines(one at a time). The VMM effects a VM entry using instructions VMLAUNCII and VMRESUME; it regains control using VM exits VM exits transfer control to an entry point specified by the VMM. The VMM can take action appropriate to the cause of the VM exit and can then return to the virtual Inlachine using a VM entry. Guest 0 Guest 1 /M EXit VM Entry VM EXIt VMXON VM Monitor VMXOFF Figure 2: Intera.ction of a Virtual-Machine Monitor and guests Eventually, thie VMM inlay decide to shiut itself down and leave VMX operation. It does so by executing the VMXOFF instruction 1.3. 4 Virtual machine Control structure VMX non-root operation and VMX transitions are controlled by a data struc ture called a virtual-ImachiIle control structure(VMCS). Access to the VMCs is managed through a component of processor state called the vmCS pointer(one per logical processor). The value of the VMCS pointer is the 64-bit address VMPTRST and VMPTRTD. The VMM configures a. VMOS using the vl of the VMCS. The VMCs pointer is rcad and writtcn using the instructio RFAD. VMWRITE. and mclear instructions. A VMm could use a, differ- ent vMos for each virtual machine that it supports. For a virtual machine with multiple logical processors(virtual processors), the VMM could use a different VMCS for each virtual processor 1.3.5 Restrictions ol VMX operation VMX operation places restrictions on processor operation. These are detailed below In VMX operation, processors Illay fix certain bits in Cro and CR4 to specific values and not support other values. VMXON fails if any of these bits contains an unsupported valuc. Any attcmpt to sct onc of these bits to an unsupported valuc whilc in VMX opcration(including VMX root operation)using any of the CLTS, LMSW or MOV CR instructions causes a general-protection exception. VM entry or VM exit cannot set any of these bits to an unsupported value. (2) NOTE The first proccssors to support VMX opcration rcquirc that the following bits be l in VMX operation: CRO PE, CRONE, CRO PG, and CRA.VMXE. The restrictions on CRO PE and cro Pg imply that vmx operation is supported only in paged protected mode (including IA-32e mode). Therefore. guest software cannot be run in unpaged protected mode or in real-address mode natively. But there are techniques to support these kind of guests with vt-X VMXON fails if a logical processor is in A20M mode. Once the processo is in vMX operation, A20M interrupts are blocked. Thus, it is impossible to be in A20M mode in VMX operation The INIT signal is blocked whenever a logical processor is in VMX root operation. It is not blocked in VMX non-root operation. Instead, INITs cause Vm exits 2 Virtual machine Control structure 2.1 Overview The virtual-machine control data structure(VMCS) is defined for VMX opera tion. A VMOS manages transitions in and out of VMX non-root operation(VM entries and VM exits)as well as processor behavior in VMX non-root operation This structure is manipulated by the new instructions VMCLEAR, VMPTRLD Ⅴ MREAD. and VMWritE A VMM can usc a diffcrcnt VMCS for cach virtual machinc that it supports For a virtual machine with multiple logical processors(virtual processors), the VMM can use a different VMOS for each virtual processor. Each logical pro- cessor associates a region in memory with each VMCS. This region is called the VMCS region. Software references a specific VMoS by using the 64-bit physical address of the region; such an address is called a VMCS pOinter. VMCS pOint ers must be aligned on a 4-KByte boundary(bits 11: 0 must be zero). A logical processor may maintain any number of active VMCSs. At any given time, one is the currentⅤMCS: Software makes a VMCS active by executing VMPTRLD with the address of the vmcs. The processor may optimize VMX operation by maintain ing the state of an active Vmcs in memory, on the processor, or both. Software should not make a VmCs active on more than one logical pro ccssor. Softwarc makcs a VMCS inactive by cxccuting VMCLEAR with thc address of the VMCS. A logical processor docs not usc an inactive VMCS or maintain its state on the processor Software Inakes a VMCS current by executing VMPtRLD with the ad dress of the VMCS; that address is loaded into the current -VMCS pointer VMX instructionsⅤ MLAUNCH,Ⅴ MPTRST,Ⅴ MREAD, VMRESUME and vmwrite operate on the current VMCS. a VMCS remains current until either software executes VMPTRld with the address of a different VMCS which then becomes the current vmoS or software executes VM CLEAR with the address of the current VMCS (after which there is no VMCS NOTE: This document uscs thc notation RAX. RIP. RSP RFLags. ctc for processor registers because most processors that support VMX operation For processors that do t intel 64 architecture, this notation refers to the 32-bit forms of those registers (EAX EIP. ESP EFLAGS