Volume 3B System Programming Guide_ Part 2 (794104), страница 68
Текст из файла (страница 68)
If the PDE refers to a 4-MByte page (PS = 1), thenset P = 0 in the PDE.2. If the PDE is marked present and refers to a page table (PS = 0), locate therelevant active PTE using the next 10 bits of the operand address (bits 21–12)and the page-table base address in the PDE. Set P = 0 in the PTE. Examine allPTEs in the page table; if they are now all marked not-present, de-allocate thepage table and set P = 0 in the PDE (this step may be optional).26.3.5.4Response to CR3 WritesA guest operating system may attempt to write to CR3. Any write to CR3 implies aTLB flush and a possible page table change.
The following steps are performed:1. The VMM notes the new CR3 value (used later to walk guest page tables) andemulates the write.2. The VMM allocates a new PD page, with all invalid entries.3. The VMM sets actual processor CR3 register to point to the new PD page.The VMM may, at this point, speculatively fill in VTLB mappings for performancereasons.26.4MICROCODE UPDATE FACILITYThe microcode code update facility may be invoked at various points during the operation of a platform.
Typically, the BIOS invokes the facility on all processors duringVol. 3 26-11VIRTUALIZATION OF SYSTEM RESOURCESthe BIOS boot process. This is sufficient to boot the BIOS and operating system. As amicrocode update more current than the system BIOS may be available, system software should provide another mechanism for invoking the microcode update facility.The implications of the microcode update mechanism on the design of the VMM aredescribed in this section.NOTEMicrocode updates must not be performed during VMX non-rootoperation.
Updates performed in VMX non-root operation may resultin unpredictable system behavior.26.4.1Early Load of Microcode UpdatesThe microcode update facility may be invoked early in the VMM or guest OS bootprocess. Loading the microcode update early provides the opportunity to correcterrata affecting the boot process but the technique generally requires a reboot of thesoftware.A microcode update may be loaded from the OS or VMM image loader. Typically, suchimage loaders do not run on every logical processor, so this method effects only onelogical processor. Later in the VMM or OS boot process, after bringing all applicationprocessors on-line, the VMM or OS needs to invoke the microcode update facility forall application processors.Depending on the order of the VMM and the guest OS boot, the microcode updatefacility may be invoked by the VMM or the guest OS.
For example, if the guest OSboots first and then loads the VMM, the guest OS may invoke the microcode updatefacility on all the logical processors. If a VMM boots before its guests, then the VMMmay invoke the microcode update facility during its boot process. In both cases, theVMM or OS should invoke the microcode update facilities soon after performing themultiprocessor startup.In the early load scenario, microcode updates may be contained in the VMM or OSimage or, the VMM or OS may manage a separate database or file of microcodeupdates. Maintaining a separate microcode update image database has the advantage of reducing the number of required VMM or OS releases as a result of microcodeupdate releases.26.4.2Late Load of Microcode UpdatesA microcode update may be loaded during normal system operation.
This allowssystem software to activate the microcode update at anytime without requiring asystem reboot. This scenario does not allow the microcode update to correct erratawhich affect the processor’s boot process but does allow high-availability systems toactivate microcode updates without interrupting the availability of the system. In thislate load scenario, either the VMM or a designated guest may load the microcodeupdate. If the guest is loading the microcode update, the VMM must make sure that26-12 Vol. 3VIRTUALIZATION OF SYSTEM RESOURCESthe entire guest memory buffer (which contains the microcode update image) will notcause a page fault when accessed.If the VMM loads the microcode update, then the VMM must have access to thecurrent set of microcode updates. These updates could be part of the VMM image orcould be contained in a separate microcode update image database (for example: adatabase file on disk or in memory).
Again, maintaining a separate microcode updateimage database has the advantage of reducing the number of required VMM or OSreleases as a result of microcode update releases.The VMM may wish to prevent a guest from loading a microcode update or may wishto support the microcode update requested by a guest using emulation (withoutactually loading the microcode update). To prevent microcode update loading, theVMM may return a microcode update signature value greater than the value ofIA32_BISO_SIGN_ID MSR.
A well behaved guest will not attempt to load an oldermicrocode update. The VMM may also drop the guest attempts to write toIA32_BIOS_UPDT_TRIG MSR, preventing the guest from loading any microcodeupdates. Later, when the guest queries IA32_BIOS_SIGN_ID MSR, the VMM couldemulate the microcode update signature that the guest expects.In general, loading a microcode update later will limit guest software’s visibility offeatures that may be enhanced by a microcode update.Vol. 3 26-13VIRTUALIZATION OF SYSTEM RESOURCES26-14 Vol.
3CHAPTER 27HANDLING BOUNDARY CONDITIONS IN A VIRTUALMACHINE MONITOR27.1OVERVIEWThis chapter describes what a VMM must consider when handling exceptions, interrupts, error conditions, and transitions between activity states.27.2INTERRUPT HANDLING IN VMX OPERATIONThe following bullets summarize VMX support for handling interrupts:•Control of Processor Exceptions.
The VMM can get control on specific guestexceptions through the exception-bitmap in the guest controlling-VMCS. Theexception bitmap is a 32-bit field that allows the VMM to specify processorbehavior on specific exceptions (including traps, faults and aborts). Setting aspecific bit in the exception bitmap implies VM exits will be generated when thecorresponding exception occurs.
Any exceptions that are programmed not tocause VM exits are delivered directly to the guest through the guest IDT. Theexception bitmap also controls execution of relevant instructions such as BOUND,INTO and INT3. VM exits on page-faults are treated in such a way the page-faulterror-code is qualified through the page fault error-code mask and match fields inthe VMCS.•Control over Triple-faults. If a fault occurs while attempting to call a doublefault handler in the guest and that fault is not configured to cause a VM exit in theexception bitmap, the resulting triple fault causes a VM exit.•Control of External-Interrupts. VMX allows both host and guest control ofexternal interrupts through the “external-interrupt exiting” VM execution control.With guest control (external-interrupt exiting set to 0), external-interrupts do notcause VM exits and the interrupt delivery is masked by the guest programmedRFLAGS.IF value.1 With host control (external-interrupt exiting set to 1),external-interrupts causes VM exits and are not masked by RFLAGS.IF.
The VMMcan identify VM exits due to external interrupts by checking the exit-reason for an‘external-interrupt’ (value = 1).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.).Vol. 3 27-1HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR•Control of Other Events.
There is a pin-based VM-execution control thatcontrols system behavior (exit or no-exit) for NMI events. Most VMM usages willneed handling of NMI external events in the VMM and hence will specify hostcontrol of these events.Some processors also support a pin-based VM-execution control called “virtualNMIs.” When this control is set, NMIs cause VM exits, but the processor tracksguest readiness for virtual NMIs.
This control interacts with the “NMI-windowexiting” VM-execution control (see below).INIT and SIPI events always cause VM exits.•Acknowledge-Interrupt-On-Exit. The acknowledge-interrupt-on-exit bit inthe VM-exit control field in the controlling-VMCS controls processor behavior forexternal interrupt acknowledgement.
If the control bit is set, the processoracknowledges the interrupt controller to acquire the interrupt vector upon VMexit, and stores the vector in the VM-exit interruption-information field. If thecontrol bit is clear, the external interrupt is not acknowledged during VM exit.Since RFLAGS.IF is automatically cleared on VM exits due to external interrupts,VMM re-enabling of interrupts (setting RFLAGS.IF = 1) initiates the externalinterrupt acknowledgement and vectoring of the external interrupt through themonitor/host IDT.•Event Masking Support.
VMX captures the masking conditions of specificevents while in VMX non-root operation through the interruptibility-state field inthe guest-state area of the VMCS.This feature allows proper virtualization of various interrupt blocking states, suchas: (a) blocking of external interrupts for the instruction following STI; (b)blocking of interrupts for the instruction following a MOV-SS or POP-SSinstruction; (c) SMI blocking of subsequent SMIs until the next execution of RSM;and (d) NMI/SMI blocking of NMIs until the next execution of IRET or RSM.INIT and SIPI events are treated specially. INIT assertions are always blocked inVMX root operation and while in SMM, and unblocked otherwise. SIPI events arealways blocked in VMX root operation.The interruptibility state is loaded from the VMCS guest-state area on everyVM entry and saved into the VMCS on every VM exit.•Event injection.
VMX operation allows injecting interruptions to a guest virtualmachine through the use of VM-entry interrupt-information field in VMCS.Injectable interruptions include external interrupts, NMI, processor exceptions,software generated interrupts, and software traps. If the interrupt-informationfield indicates a valid interrupt, exception or trap event upon the next VM entry;the processor will use the information in the field to vector a virtual interruptionthrough the guest IDT after all guest state and MSRs are loaded. Deliverythrough the guest IDT emulates vectoring in non-VMX operation by doing thenormal privilege checks and pushing appropriate entries to the guest stack(entries may include RFLAGS, EIP and exception error code).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
