2016基礎(chǔ)學(xué)習(xí)第二課intel手冊(cè)全集64ia32architectures software developer vol3c part3manual

1、Intel® 64 and IA-32 Architectures Software Developers ManualVolume 3C:System ProgramGuide, Part 3NOTE: The Intel® 64 and IA-32 Architectures Software Developer's Manual consists of eight volumes: Basic Architecture, Order Number 253665; Instruction Set Reference A-M, Order Number 25366

2、6; Instruction Set Reference N-Z, Order Number 253667; Instruction Set Reference, Order Number326018; System ProgramGuide, Part 1, Order Number 253668; System ProgramGuide, Part2, Order Number 253669; System ProgramGuide, Part 3, Order Number 326019; SystemProgramdesign needs.Guide, Part 4, Order Nu

3、mber 332831. Refer to all eight volumes when evaluating yourOrder Number: 326019-058USApril 2016Intel technologies features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Learn more at , or from the OEM or retailer.No computer system ca

4、n be absolutely secure. Intel does not assume any liability for lost or stolen data or systems or any damages resulting from such losses.You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You

5、agree to gr ntel a non-exclusive, royalty- license to any patent claim thereafter drafted which includes subject matter dis d herein.No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.The products described may contain design def

6、ects or errors known as errata which may cause the product to deviate from published specifica- tions. Current characterized errata are available on request.This document contains information on products, services and/or processes in development. All information provided here is subject to change wi

7、thout notice. Contact your Intel representative to obtain the latest Intel product specifications and roadmapsCopies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-, or by visiting.Intel, the Intel logo, Intel Atom

8、, Intel Core, Intel SpeedStep, MMX, Pentium, VTune, and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries.*Other names and brands may be claimed as the property of others.Copyright © 1997-2016, Intel Corporation.CHAPTER 23 INTRODUCTION TO VIRTUAL MACHINE EXTENSIONS23.1

9、OVERVIEWThis chapter describes the basics of virtual machine architecture and an overview of the virtual-machine extensions (VMX) that support virtualization of processor hardware for multiple software environments.Information about VMX instructions is provided in Intel® 64 and IA-32 Architectu

10、res Software Developers Manual,Volume 2B. Other aspects of VMX and system programconsiderations are described in chapters of Intel® 64and IA-32 Architectures Software Developers Manual, Volume 3B.23.2VIRTUAL MACHINE ARCHITECTUREVirtual-machine extensions define processor-level support for virtu

11、al machines on IA-32 processors. Two principal classes of software are supported:Virtual-machine monitors (VMM) A VMM acts as a host and has full control of the processor(s) and other platform hardware. A VMM presents guest software (see next paragraph) with an abstraction of a virtual processor and

12、 allows it to execute directly on a logical processor. A VMM is able to retain selective control of processor resources, physical memory, interrupt management, and I/O.Guest software Each virtual machine (VM) is a guest software environment that supports a stack consisting of operating system (OS) a

13、nd application software. Each operates independently of other 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

14、machine must operate with reduced privilege so that the VMM can retain control of platform resources.23.3INTRODUCTION TO VMX OPERATIONProcessor support for virtualization is provided by a form of processor operation called VMX operation. There are two kinds of VMX operation: VMX root operation and V

15、MX non-root operation. In general, a VMM will run in 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 operation

16、 are called VM entries. Transitions from VMX non-root operation 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 th

17、e values that can be loaded into certain control registers are limited (see Section 23.8).Processor behavior in VMX non-root operation is restricted and modified to facilitate virtualization. Instead of their ordinary operation, certain instructions (including the new VMCALL instruction) and events

18、cause VM exits to the VMM. Because 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 logic

19、al processor is in VMX non-root operation. This fact may allow a VMM to prevent guest software from determining that it is running in a virtual machine.Because VMX operation places restrictions even on software running with current privilege level (CPL) 0, guest software can run at the privilege lev

20、el for which it was originally designed. This capability may simplify the devel- opment of a VMM.Vol. 3C 23-1INTRODUCTION TO VIRTUAL MACHINE EXTENSIONS23.4LIFE CYCLE OF VMM SOFTWAREFigure 23-1 illustrates the life cycle of a VMM and its guest software as well as the interactions between them. The fo

21、llowing 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 VMLAUNCH and VMRESUME; it regains control using VM exits.VM exits

22、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 machine using a VM entry.Eventually, the VMM may decide to shut itself down and leave VMX operation. It does so by executing the VMXOFF instruct

23、ion.Figure 23-1. Interaction of a Virtual-Machine Monitor and Guests23.5VIRTUAL-MACHINE CONTROL STRUCTUREVMX non-root operation and VMX transitions are controlled by a data structure called a virtual-machine control structure (VMCS).Access to the VMCS is managed through a component of processor stat

24、e called the VMCS pointer (one per logicalprocessor). The value of the VMCS pointer is the 64-bit address of the VMCS. The VMCS pointer isand writtenusing the instructions VMPTRST and VMPTRLD. The VMM configures a VMCS using the VM VMCLEAR instructions., VMWRITE, andA VMM could use a different VMCS

25、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.23.6DISCOVERING SUPPORT FOR VMXBefore system software enters into VMX operation, it must discover the presence of VMX

26、support in the processor. System software can determine whether a processor supports VMX operation using CPUID. If CPUID.1:ECX.VMXbit 5 = 1, then VMX operation is supported. See Chapter 3, “Instruction Set Reference, A-M” of Intel® 64 and IA-32 Architectures Software Developers Manual, Volume 2

27、A.The VMX architecture is designed to be extensible so that future processors in VMX operation can support addi- tional features not present in first-generation implementations of the VMX architecture. The availability of exten- sible VMX features is reported to software using a set of VMX capabilit

28、y MSRs (see Appendix A, “VMX Capability Reporting Facility”).23-2 Vol. 3CVM ExitVM EntryVM ExitVMXONVMXOFFVM MonitorGuest 1Guest 0INTRODUCTION TO VIRTUAL MACHINE EXTENSIONS23.7ENABLING AND ENTERING VMX OPERATIONBefore system software can enter VMX operation, it enables VMX by setting CR4.VMXEbit 13

29、= 1. VMX operation is then entered by executing the VMXON instruction. VMXON causes an invalid-opcode exception (#UD) if executed with CR4.VMXE = 0. Once in VMX operation, it is not possible to clear CR4.VMXE (see Section 23.8). System soft- ware leaves VMX operation by executing the VMXOFF instruct

30、ion. CR4.VMXE can be cleared outside of VMX opera- tion after executing of VMXOFF.VMXON is also controlled by the IA32_FEATURE_CONTROL MSR (MSR address 3AH). This MSR is cleared to zero when a logical processor is reset. The relevant bits of the MSR are:Bit 0 is the lock bit. If this bit is clear, V

31、MXON causes a general-exception. If the lock bit is set,WRMSR to this MSR causes a general-exception; the MSR cannot be modified until a power-up resetcondition. System BIOS can use this bit to provide a setup option for BIOS to disable support for VMX. To enable VMX support in a platform, BIOS must

32、 set bit 1, bit 2, or both (see below), as well as the lock bit.Bit 1 enables VMXON in SMX operation. If this bit is clear, execution of VMXON in SMX operation causes ageneral-exception. Attempts to set this bit on logical processors that do not support both VMXoperation (see Section 23.6) and SMX o

33、peration (see Chapter 5, “Safer Mode Extensions Reference,” in Intel®64 and IA-32 Architectures Software Developers Manual, Volume 2B) cause general-exceptions.Bit 2 enables VMXON outside SMX operation. If this bit is clear, execution of VMXON outside SMXoperation causes a general-exception. At

34、tempts to set this bit on logical processors that do notsupport VMX operation (see Section 23.6) cause general-exceptions.NOTEA logical processor is in SMX operation if GETSECSEXIT has not been executed since the last execution of GETSECSENTER. A logical processor is outside SMX operation if GETSECS

35、ENTER has not been executed or if GETSECSEXIT was executed after the last execution of GETSECSENTER. See Chapter 5, “Safer Mode Extensions Reference,” in Intel® 64 and IA-32 Architectures Software Developers Manual, Volume 2B.Before executing VMXON, software should allocate a naturally aligned

36、4-KByte region of memory that a logical processor may use to support VMX operation.1 This region is called the VMXON region. The address of the VMXONregion (the VMXON pointer) is provided in an operand to VMXON. Section 24.11.5, “VMXON Region,” software should initialize and access the VMXON region.

37、s how23.8RESTRICTIONS ON VMX OPERATIONVMX operation places restrictions on processor operation. These areed below:In VMX operation, processors may fix certain bits in CR0 and CR4 to specific values and not support other values. VMXON fails if any of these bits contains an unsupported value (see “VMX

38、ONEnter VMX Operation” in Chapter 30). Any attempt to set one of these bits to an unsupported value while in VMX operation (including VMX root operation) using any of the CLTS, LMSW, or MOV CR instructions causes a general-exception. VM entry or VM exit cannot set any of these bits to an unsupported

39、 value. Software should consult the VMX capability MSRs IA32_VMX_CR0_FIXED0 and IA32_VMX_CR0_FIXED1 to determine how bits in CR0 are fixed (see Appendix A.7). For CR4, software should consult the VMX capability MSRs IA32_VMX_CR4_FIXED0 and IA32_VMX_CR4_FIXED1 (see Appendix A.8).NOTESThe first proces

40、sors to support VMX operation require that the following bits be 1 in VMX operation: CR0.PE, CR0.NE, CR0.PG, and CR4.VMXE. The restrictions on CR0.PE and CR0.PG imply that VMX operation is supported only in paged protected mode (including IA-32e mode). Therefore, guest software cannot be run in unpa

41、ged protected mode or in real-address mode. See Section 31.2,1.Future processors may require that a different amount of memory be VMX capability-reporting mechanism. If so, this fact is reported to software using theVol. 3C 23-3INTRODUCTION TO VIRTUAL MACHINE EXTENSIONS“Supporting Processor Operatin

42、g Modes in Guest Environments,” for a discussion of how a VMM might support guest software that expects to run in unpaged protected mode or in real-address mode.Later processors support a VM-execution control called “unrestricted guest” (see Section 24.6.2). If this control is 1, CR0.PE and CR0.PG m

43、ay be 0 in VMX non-root operation (even if the capability MSR IA32_VMX_CR0_FIXED0 reports otherwise).1 Such processors allow guest software to run in unpaged protected mode or in real-address mode.VMXON fails if a logical processor is in A20M mode (see “VMXONEnter VMX Operation” in Chapter 30). Once

44、 the processor 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 (see Section 25.2,

45、 “Other Causes of VM Exits”).Intel® Processor Trace (Intel PT) can be used in VMX operation only if IA32_VMX_MISC14 isas 1 (seeAppendix A.6). On processors that support Intel PT but which do not allow it to be used in VMX operation,execution of VMXON clears IA32_RTIT_CTL.TraceEn (see “VMXONEnte

46、r VMX Operation” in Chapter 30); any attempt to set that bit while in VMX operation (including VMX root operation) using the WRMSR instructioncauses a general-exception.1.“Unrestricted guest” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution c

47、ontrols is 0, VMX non-root operation functions as if the “unrestricted guest” VM-execution control were 0. See Section 3-4 Vol. 3CCHAPTER 24 VIRTUAL MACHINE CONTROL STRUCTURES24.1OVERVIEWA logical processor uses virtual-machine control data structures (VMCSs) while it is in VMX operation. Th

48、ese manage transitions into 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, VM, and VMWRITE.A VMM can use a different VMCS for each virtual machine that it sup

49、ports. For a virtual machine with multiple logical processors (virtual processors), the VMM can use a different VMCS for each virtual processor.A logical processor associates a region in memory with each VMCS. This region is called the VMCS region.1 Soft- ware references a specific VMCS using the 64

50、-bit physical address of the region (a VMCS pointer). VMCS pointers must be aligned on a 4-KByte boundary (bits 11:0 must be zero). These pointers must not set bits beyond the processors physical-address width.2,3A logical processor may maintain a number of VMCSs that are active. The processor may o

51、ptimize VMX operation by maintaining the state of an active VMCS in memory, on the processor, or both. At any given time, at most one of the active VMCSs is the current VMCS. (This document frequently uses the term “the VMCS” to refer to thecurrent VMCS.) The VMLAUNCH, VM VMCS., VMRESUME, and VMWRIT

52、E instructions operate only on the currentThe following items describe how a logical processor determines which VMCSs are active and which is current:The memory operand of the VMPTRLD instruction is the address of a VMCS. After execution of the instruction, that VMCS is both active and current on th

53、e logical processor. Any other VMCS that had been active remains so, but no other VMCS is current.The VMCS link pointer field in the current VMCS (see Section 24.4.2) is itself the address of a VMCS. If VM entry is performed successfully with the 1-setting of the “VMCS shadowing” VM-execution contro

54、l, the VMCSreferenced by the VMCS link pointer field become VMCS does not change.ive on the logical processor. The identity of the currentThe memory operand of the VMCLEAR instruction is also the address of a VMCS. After execution of the instruction, that VMCS is neither active nor current on the lo

55、gical processor. If the VMCS had been current on the logical processor, the logical processor no longer has a current VMCS.The VMPTRST instruction stores the address of the logical processors current VMCS into a specified memory loca- tion (it stores the value FFFFFFFF_FFFFFFFFH if there is no curre

56、nt VMCS).The launch state of a VMCS determines which VM-entry instruction should be used with that VMCS: the VMLAUNCH instruction requires a VMCS whose launch state is “clear”; the VMRESUME instruction requires a VMCS whose launch state is “l(fā)aunched”. A logical processor maintains a VMCSs launch sta

57、te in the corresponding VMCS region. The following items describe how a logical processor manages the launch state of a VMCS:If the launch state of the current VMCS is “clear”, successful execution of the VMLAUNCH instruction changes the launch state to “l(fā)aunched”.The memory operand of the VMCLEAR i

58、nstruction is the address of a VMCS. After execution of the instruction, the launch state of that VMCS is “clear”.There are no other ways to modify the launch state of a VMCS (it cannot be modified using VMWRITE) and thereis no direct way to discover it (it cannot beusing VM).1.The amount of memory required for a VMCS region is at most 4 KBytes. The exact size is implementation specific and can be deter- mined by consulting the VMX capability MSR IA32_VMX_BASIC to d