32-8 Vol. 3C

VIRTUALIZATION OF SYSTEM RESOURCES

Examine all PTEs in the page table; if they are now all marked not-present, de-allocate the page table and set 
P = 0 in the PDE (this step may be optional).

32.3.5.4   Response to CR3 Writes

A guest operating system may attempt to write to CR3. Any write to CR3 implies a TLB 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) and emulates 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 performance reasons.

32.4 

MICROCODE UPDATE FACILITY

The 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 during the BIOS boot process. This is sufficient to boot the BIOS and 
operating system. As a microcode 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 are described in this section.

NOTE

Microcode updates must not be performed during VMX non-root operation. Updates performed in 
VMX non-root operation may result in unpredictable system behavior.

32.4.1 

Early Load of Microcode Updates

The microcode update facility may be invoked early in the VMM or guest OS boot process. Loading the microcode 
update early provides the opportunity to correct errata affecting the boot process but the technique generally 
requires a reboot of the software.
A microcode update may be loaded from the OS or VMM image loader. Typically, such image loaders do not run on 
every logical processor, so this method effects only one logical processor. Later in the VMM or OS boot process, 
after bringing all application processors on-line, the VMM or OS needs to invoke the microcode update facility for all 
application processors.
Depending on the order of the VMM and the guest OS boot, the microcode update facility may be invoked by the 
VMM or the guest OS. For example, if the guest OS boots first and then loads the VMM, the guest OS may invoke 
the microcode update facility on all the logical processors. If a VMM boots before its guests, then the VMM may 
invoke the microcode update facility during its boot process. In both cases, the VMM or OS should invoke the micro-
code update facilities soon after performing the multiprocessor startup.
In the early load scenario, microcode updates may be contained in the VMM or OS image or, the VMM or OS may 
manage a separate database or file of microcode updates. Maintaining a separate microcode update image data-
base has the advantage of reducing the number of required VMM or OS releases as a result of microcode update 
releases.

32.4.2 

Late Load of Microcode Updates

A microcode update may be loaded during normal system operation. This allows system software to activate the 
microcode update at anytime without requiring a system reboot. This scenario does not allow the microcode update 
to correct errata which affect the processor’s boot process but does allow high-availability systems to activate 
microcode updates without interrupting the availability of the system. In this late load scenario, either the VMM or 
a designated guest may load the microcode update. If the guest is loading the microcode update, the VMM must