Volume 3B System Programming Guide_ Part 2 (794104), страница 59
Текст из файла (страница 59)
For this reason, suchSMM VM exits do not load processor state as described in Section 23.5. Instead,state is set to fixed values or loaded based on the content of the MSEG header (seeTable 24-9):•CR0 is set to as follows:— PG, NE, ET, MP, and PE are all set to 1.— CD and NW are left unchanged.— All other bits are cleared to 0.•CR3 is set as follows:— Bits 63:32 are cleared on processors that supports IA-32e mode.— Bits 31:12 are set to bits 31:12 of the sum of the MSEG base address and theCR3-offset field in the MSEG header.— Bits 11:5 and bits 2:0 are cleared (the corresponding bits in the CR3-offsetfield in the MSEG header are ignored).— Bits 4:3 are set to bits 4:3 of the CR3-offset field in the MSEG header.•CR4 is set as follows:— MCE and PGE are cleared.— PAE is set to the value of the IA-32e mode SMM feature bit.24-36 Vol.
3SYSTEM MANAGEMENT— If the IA-32e mode SMM feature bit is clear, PSE is set to 1 if supported by theprocessor; if the bit is set, PSE is cleared.— All other bits are unchanged.•••DR7 is set to 400H.The IA32_DEBUGCTL MSR is cleared to 00000000_00000000H.The registers CS, SS, DS, ES, FS, and GS are loaded as follows:— All registers are usable.— CS.selector is loaded from the corresponding fields in the MSEG header (thehigh 16 bits are ignored), with bits 2:0 cleared to 0. If the result is 0000H,CS.selector is set to 0008H.— The selectors for SS, DS, ES, FS, and GS are set to CS.selector+0008H. If theresult is 0000H (if the CS selector was 0xFFF8), these selectors are insteadset to 0008H.— The base addresses of all registers are cleared to zero.— The segment limits for all registers are set to FFFFFFFFH.— The AR bytes for the registers are set as follows:•CS.Type is set to 11 (execute/read, accessed, non-conforming codesegment).•For SS, DS, FS, and GS, the Type is set to 3 (read/write, accessed,expand-up data segment).••••The S bits for all registers are set to 1.The DPL for each register is set to 0.The P bits for all registers are set to 1.On processors that support Intel 64 architecture, CS.L is loaded with thevalue of the IA-32e mode SMM feature bit.•CS.D is loaded with the inverse of the value of the IA-32e mode SMMfeature bit.••For each of SS, DS, FS, and GS, the D/B bit is set to 1.The G bits for all registers are set to 1.•LDTR is unusable.
The LDTR selector is cleared to 0000H, and the register isotherwise undefined (although the base address is always canonical)•GDTR.base is set to the sum of the MSEG base address and the GDTR base-offsetfield in the MSEG header (bits 63:32 are always cleared on processors thatsupports IA-32e mode). GDTR.limit is set to the corresponding field in the MSEGheader (the high 16 bits are ignored).•IDTR.base is unchanged. IDTR.limit is cleared to 0000H.Vol. 3 24-37SYSTEM MANAGEMENT•RIP is set to the sum of the MSEG base address and the value of the RIP-offsetfield in the MSEG header (bits 63:32 are always cleared on logical processorsthat support IA-32e mode).•RSP is set to the sum of the MSEG base address and the value of the RSP-offsetfield in the MSEG header (bits 63:32 are always cleared on logical processor thatsupports IA-32e mode).•••RFLAGS is cleared, except bit 1, which is always set.The logical processor is left in the active state.Event blocking after the SMM VM exit is as follows:— There is no blocking by STI or by MOV SS.— There is blocking by non-maskable interrupts (NMIs) and by SMIs.••There are no pending debug exceptions after the SMM VM exit.For processors that support IA-32e mode, the IA32_EFER MSR is modified so thatLME and LMA both contain the value of the IA-32e mode SMM feature bit.If any of CR3[63:5], CR4.PAE, CR4.PSE, or IA32_EFER.LMA is changing, the TLBs areupdated so that, after VM exit, the logical processor does not use translations thatwere cached before the transition.
This is not necessary for changes that would notaffect paging due to the settings of other bits (for example, changes to CR4.PSE ifIA32_EFER.LMA was 1 before and after the transition).24.16.6.5 Loading MSRsThe VM-exit MSR-load area is not used by SMM VM exits that activate the dualmonitor treatment. No MSRs are loaded from that area.24.16.7 Deactivating the Dual-Monitor TreatmentAn SMM monitor may deactivate the dual monitor treatment and return theprocessor to default treatment of SMIs and SMM (see Section 24.15).
It does this byexecuting a VM entry with the “deactivate dual-monitor treatment” VM-entry controlset to 1.As noted in Section 22.2.1.3 and Section 24.16.4.1, an attempt to deactivate thedual-monitor treatment fails in the following situations: (1) the processor is not inSMM; (2) the “entry to SMM” VM-entry control is 1; or (3) the executive-VMCSpointer does not contain the VMXON pointer (the VM entry is to VMX non-root operation).As noted in Section 24.16.4.7, VM entries that deactivate the dual-monitor treatment ignore the SMI bit in the interruptibility-state field of the guest-state area.Instead, such a VM entry unconditionally unmasks SMIs.24-38 Vol. 3CHAPTER 25VIRTUAL-MACHINE MONITOR PROGRAMMINGCONSIDERATIONS25.1VMX SYSTEM PROGRAMMING OVERVIEWThe Virtual Machine Monitor (VMM) is a software class used to manage virtualmachines (VM).
This chapter describes programming considerations for VMMs.Each VM behaves like a complete physical machine and can run operating system(OS) and applications. The VMM software layer runs at the most privileged level andhas complete ownership of the underlying system hardware. The VMM controlscreation of a VM, transfers control to a VM, and manages situations that can causetransitions between the guest VMs and host VMM. The VMM allows the VMs to sharethe underlying hardware and yet provides isolation between the VMs.
The guest software executing in a VM is unaware of any transitions that might have occurredbetween the VM and its host.25.2SUPPORTING PROCESSOR OPERATING MODES INGUEST ENVIRONMENTSTypically, VMMs transfer control to a VM using VMX transitions referred to as VMentries. The boundary conditions that define what a VM is allowed to execute in isolation are specified in a virtual-machine control structure (VMCS).As noted in Section 19.8, processors may fix certain bits in CR0 and CR4 to specificvalues and not support other values. The first processors to support VMX operationrequire that CR0.PE and CR0.PG be 1 in VMX operation.
Thus, a VM entry is allowedonly to guests with paging enabled that are in protected mode or in virtual-8086mode. Guest execution in other processor operating modes need to be speciallyhandled by the VMM.One example of such a condition is guest execution in real-mode. A VMM couldsupport guest real-mode execution using at least two approaches:•By using a fast instruction set emulator in the VMM.Vol.
3 25-1VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS•By using the similarity between real-mode and virtual-8086 mode to supportreal-mode guest execution in a virtual-8086 container. The virtual-8086container may be implemented as a virtual-8086 container task within a monitorthat emulates real-mode guest state and instructions, or by running the guest VMas the virtual-8086 container (by entering the guest with RFLAGS.VM1 set).Attempts by real-mode code to access privileged state outside the virtual-8086container would trap to the VMM and would also need to be emulated.Another example of such a condition is guest execution in protected mode withpaging disabled. A VMM could support such guest execution by using “identity” pagetables to emulate unpaged protected mode.25.2.1Emulating Guest ExecutionIn certain conditions, VMMs may resort to using a virtual-8086 container to supportguest execution in operating modes not supported by VMX.
But for other conditions,VMMs may need to resort to emulating guest execution.These are example conditions that require guest emulation in the VMM:•Programming conditions that are not allowed by the VMX consistency checks.Examples of this include transient conditions introduced when switching betweenreal-mode and protected mode (where some segment may not be consistent withthe operating mode).•Conditions of guest task switching. Task switches always cause VM exits.
Tocorrectly advance the guest state, the monitor needs to emulate the guest taskswitching behavior.•When a SMM monitor is configured, conditions where the SMRAM is relocated toan address above 1 MByte (HSEG).•When executing SMM code in a guest container by an SMM monitor. SMMprocessor operation allows address space ranges from 0-4 GBytes compared tothe 1 MByte address space in real-mode operation.
Also, the 64-KByte segmentlimit of real-mode is increased to 4 GBytes in SMM).25.3MANAGING VMCS REGIONS AND POINTERSA VMM must observe necessary procedures when working with a VMCS, the associated VMCS pointer, and the VMCS region. It must also not assume the state of persistency for VMCS regions in memory or cache.1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because mostprocessors that support VMX operation also support Intel 64 architecture.
For processors that donot support Intel 64 architecture, this notation refers to the 32-bit forms of those registers(EAX, EIP, ESP, EFLAGS, etc.).25-2 Vol. 3VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSBefore entering VMX operation, the host VMM allocates a VMXON region. A VMM canhost several virtual machines and have many VMCSs active under its management.A unique VMCS region is required for each virtual machine; a VMXON region isrequired for the VMM itself.A VMM determines the VMCS region size by reading IA32_VMX_BASIC MSR; itcreates VMCS regions of this size using a 4-KByte-aligned area of physical memory.Each VMCS region needs to be initialized with a VMCS revision identifier (at byteoffset 0) identical to the revision reported by the processor in the VMX capabilityMSR.NOTESoftware must not read or write directly to the VMCS data region asthe format is not architecturally defined.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
