Volume 3B System Programming Guide_ Part 2 (794104), страница 56
Текст из файла (страница 56)
(Also, for the Pentium and Intel486processors, the SMBASE address must be located on a 32-KByte boundary.) Codeand static data can be shared among processors. Overlapping SMRAM spaces canbe done more efficiently with the P6 family processors because they do notrequire that the SMBASE address be on a 32-KByte boundary.••The SMI handler will need to initialize the SMBASE for each processor.••Two or more processors can be executing in SMM at the same time.Each processor needs its own SMRAM space.
This space can be in systemmemory or in a separate RAM.Processors can respond to local SMIs through their SMI# pins or to SMIs receivedthrough the APIC interface. The APIC interface can distribute SMIs to differentprocessors.When operating Pentium processors in dual processing (DP) mode, the SMIACT#pin is driven only by the MRM processor and should be sampled with ADS#. Foradditional details, see Chapter 14 of the Pentium Processor Family User’s Manual,Volume 1.SMM is not re-entrant, because the SMRAM State Save Map is fixed relative to theSMBASE.
If there is a need to support two or more processors in SMM mode at the24-22 Vol. 3SYSTEM MANAGEMENTsame time then each processor should have dedicated SMRAM spaces. This can bedone by using the SMBASE Relocation feature (see Section 24.12).24.15DEFAULT TREATMENT OF SMIS AND SMM WITH VMXUnder the default treatment, the interactions of VMX with SMIs and SMM are few.This section details those interactions.24.15.1 Default Treatment of SMI DeliveryOrdinary SMI delivery saves processor state into SMRAM and then loads state basedon architectural definitions. Under the default treatment, processors that supportVMX operation perform SMI delivery as follows:Enter SMM;save the following internal to the processor:CR4.VMXEan indication of whether the logical processor was in VMX operation (root or non-root)IF the logical processor is in VMX operationTHENsave current VMCS pointer internal to the processor;leave VMX operation;save VMX-critical state defined below;FI;CR4.VMXE ← 0;perform ordinary SMI delivery:save processor state in SMRAM;set processor state to standard SMM values;1The pseudocode above makes reference to the saving of VMX-critical state.
Thisstate consists of the following: (1) SS.DPL (the current privilege level);(2) RFLAGS.VM2; (3) the state of blocking by STI and by MOV SS (see Table 20-3 inSection 20.4.2); and (4) the state of virtual-NMI blocking (only if the processor is inVMX non-root operation and the “virtual NMIs” VM-execution control is 1). Thesedata may be saved internal to the processor or in the VMCS region of the currentVMCS. Note that processors that do not support SMI recognition while there isblocking by STI or by MOV SS need not save the state of such blocking.1. This causes the logical processor to block INIT signals, NMIs, and SMIs.2. Section 24.15 and Section 24.16 use the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX operation also support Intel 64 architecture.For processors that do not support Intel 64 architecture, this notation refers to the 32-bit formsof these registers (EAX, EIP, ESP, EFLAGS, etc.).
In a few places, notation such as EAX is used torefer specifically to the lower 32 bits of the register.Vol. 3 24-23SYSTEM MANAGEMENTBecause SMI delivery causes a logical processor to leave VMX operation, all thecontrols associated with VMX non-root operation are disabled in SMM and thuscannot cause VM exits.24.15.2 Default Treatment of RSMOrdinary execution of RSM restores processor state from SMRAM. Under the defaulttreatment, processors that support VMX operation perform RSM as follows:IF VMXE = 1 in CR4 image in SMRAMTHEN fail and enter shutdown state;ELSErestore state normally from SMRAM;CR4.VMXE ← value stored internally;IF internal storage indicates that the logical processorhad been in VMX operation (root or non-root)THENenter VMX operation (root or non-root);restore VMX-critical state as defined in Section 24.15.1;set CR0.PE, CR0.NE, and CR0.PG to 1;IF RFLAGS.VM = 0THENCS.RPL ← SS.DPL;SS.RPL ← SS.DPL;FI;restore current VMCS pointer;FI;Leave SMM;IF logical processor will be in VMX operation after RSMTHEN block A20M and leave A20M mode;FI;FI;RSM unblocks SMIs.
It restores the state of blocking by NMI (see Table 20-3 inSection 20.4.2) as follows:•If the RSM is not to VMX non-root operation or if the “virtual NMIs” VM-executioncontrol will be 0, the state of NMI blocking is restored normally.•If the RSM is to VMX non-root operation and the “virtual NMIs” VM-executioncontrol will be 1, NMIs are not blocked after RSM.
The state of virtual-NMIblocking is restored as part of VMX-critical state.INIT signals are blocked after RSM if and only if the logical processor will be in VMXroot operation.24-24 Vol. 3SYSTEM MANAGEMENTIf RSM returns a logical processor to VMX non-root operation, it re-establishes thecontrols associated with the current VMCS. If the “interrupt-window exiting”VM-execution control is 1, a VM exit occurs immediately after RSM if the enablingconditions apply. The same is true for the “NMI-window exiting” VM-executioncontrol. Such VM exits occur with their normal priority. See Section 21.3.24.15.3 Protection of CR4.VMXE in SMMUnder the default treatment, CR4.VMXE is treated as a reserved bit while a logicalprocessor is in SMM.
Any attempt by software running in SMM to set this bit causes ageneral-protection exception. In addition, software cannot use VMX instructions orenter VMX operation while in SMM.24.16DUAL-MONITOR TREATMENT OF SMIs AND SMMDual-monitor treatment is activated through the cooperation of the executivemonitor (the VMM that operates outside of SMM to provide basic virtualization) andthe SMM monitor (the VMM that operates inside SMM—while in VMX operation—tosupport system-management functions). Control is transferred to the SMM monitorthrough VM exits; VM entries are used to return from SMM.The dual-monitor treatment may not be supported by all processors. Software shouldconsult the VMX capability MSR IA32_VMX_BASIC (see Appendix G.1) to determinewhether it is supported.24.16.1 Dual-Monitor Treatment OverviewThe dual-monitor treatment uses an executive monitor and an SMM monitor.
Transitions from the executive monitor or its guests to the SMM monitor are called SMMVM exits and are discussed in Section 24.16.2. SMM VM exits are caused by SMIs aswell as executions of VMCALL in VMX root operation. The latter allow the executivemonitor to call the SMM monitor for service.The SMM monitor runs in VMX root operation and uses VMX instructions to establisha VMCS and perform VM entries to its own guests. This is done all inside SMM (seeSection 24.16.3). The SMM monitor returns from SMM, not by using the RSM instruction, but by using a VM entry that returns from SMM. Such VM entries are describedin Section 24.16.4.Initially, there is no SMM monitor and the default treatment (Section 24.15) is used.The dual-monitor treatment is not used until it is enabled and activated. The steps todo this are described in Section 24.16.5 and Section 24.16.6.It is not possible to leave VMX operation under the dual-monitor treatment; VMXOFFwill fail if executed.
The dual-monitor treatment must be deactivated first. The SMMmonitor deactivates dual-monitor treatment using a VM entry that returns from SMMVol. 3 24-25SYSTEM MANAGEMENTwith the “deactivate dual-monitor treatment” VM-entry control set to 1 (see Section24.16.7).The executive monitor configures any VMCS that it uses for VM exits to the executivemonitor. SMM VM exits, which transfer control to the SMM monitor, use a differentVMCS. Under the dual-monitor treatment, each logical processor uses a separateVMCS called the SMM-transfer VMCS. When the dual-monitor treatment is active,the logical processor maintains another VMCS pointer called the SMM-transferVMCS pointer.
The SMM-transfer VMCS pointer is established when the dualmonitor treatment is activated.24.16.2 SMM VM ExitsAn SMM VM exit is a VM exit that begins outside SMM and that ends in SMM.Unlike other VM exits, SMM VM exits can begin in VMX root operation. SMM VM exitsresult from the arrival of an SMI outside SMM or from execution of VMCALL in VMXroot operation outside SMM. Execution of VMCALL in VMX root operation causes anSMM VM exit only if the valid bit is set in the IA32_SMM_MONITOR_CTL MSR (seeSection 24.16.5).Execution of VMCALL in VMX root operation causes an SMM VM exit even under thedefault treatment. This SMM VM exit activates the dual-monitor treatment (seeSection 24.16.6).Differences between SMM VM exits and other VM exits are detailed in Sections24.16.2.1 through 24.16.2.5.
Differences between SMM VM exits that activate thedual-monitor treatment and other SMM VM exits are described in Section 24.16.6.24.16.2.1 Architectural State Before a VM ExitSystem-management interrupts (SMIs) that cause SMM VM exits always do sodirectly. They do not save state to SMRAM as they do under the default treatment.24.16.2.2 Updating the Current-VMCS and Executive-VMCS PointersSMM VM exits begin by performing the following steps:1. The executive-VMCS pointer field in the SMM-transfer VMCS is loaded as follows:— If the SMM VM exit commenced in VMX non-root operation, it receives thecurrent-VMCS pointer.— If the SMM VM exit commenced in VMX root operation, it receives the VMXONpointer.2.
The current-VMCS pointer is loaded with the value of the SMM-transfer VMCSpointer.24-26 Vol. 3SYSTEM MANAGEMENTThe last step ensures that the current VMCS is the SMM-transfer VMCS. State issaved into the guest-state area of that VMCS. The VM-exit controls and host-statearea of that VMCS determine how the VM exit operates.24.16.2.3 Recording VM-Exit InformationSMM VM exits differ from other VM exit with regard to the way they record VM-exitinformation.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
