MSR Accesses

The behavior of instructions that access MSRs might differ from the behavior of the same instructions on a logical processor. This fact is the result of the hypervisor's processor-intercept mechanism.

The following pseudo-code defines the different behaviors that can result from an access by a virtual processor to MSRs.

if the MSR is virtualized by the hypervisor AND
 the partition possesses the privilege required by the MSR {
 Access is emulated
}
else if the MSR intercept is installed {
 Suspend VP and send message to parent (MSR intercept)
}
else {
 Generate #GP fault within the guest
}

The hypervisor might virtualize MSRs as part of its interface with the guest. For a summary of these MSRs, see Hypervisor Synthetic MSRs and Hypervisor Handling of Architectural MSRs.

For those MSRs that are not virtualized by the hypervisor, internal security policy might require that certain fields within certain MSRs remain unmodified and are explicitly set for or hidden from the guest. In these cases, the access will appear to succeed from the guest's perspective, but the value actually written or read might not match the underlying physical MSR value. The tables in Hypervisor Synthetic MSRs and Hypervisor Handling of Architectural MSRs outline the policy for those MSRs whose contents are modified by the hypervisor.

Modified MSR Behavior

The hypervisor intercepts certain MSR accesses. The behavior of MSR accesses by the root guest might differ from accesses by other guests. These MSR accesses are described in Hypervisor Synthetic MSRs and Hypervisor Handling of Architectural MSRs.

Send comments about this topic to Microsoft

Build date: 11/16/2013