Errata
38 Specification Update
AZ42. Using Memory Type Aliasing with Cacheable and WC Memory Types May
Lead to Memory Ordering Violations
Problem: Memory type aliasing occurs when a single physical page is mapped to two or more
different linear addresses, each with different memory types. Memory type aliasing with
a cacheable memory type and WC (write combining) may cause the processor to perform
incorrect operations leading to memory ordering violations for WC operations.
Implication: Software that uses aliasing between cacheable and WC memory types may observe
memory ordering errors within WC memory operations. Intel has not observed this
erratum with any commercially-available software.
Workaround: None identified. Intel does not support the use of cacheable and WC memory type
aliasing, and WC operations are defined as weakly ordered.
Status: For the steppings affected, see the Summary Tables of Changes.
AZ43. VM Exit Caused by a SIPI Results in Zero Being Saved to the Guest RIP
Field in the VMCS
Problem: If a logical processor is in VMX non-root operation and in the wait-for-SIPI state, an
occurrence of a start-up IPI (SIPI) causes a VM exit. Due to this erratum, such VM exits
always save zero into the RIP field of the guest-state area of the virtual-machine control
structure (VMCS) instead of the value of RIP before the SIPI was received.
Implication: In the absence of virtualization, a SIPI received by a logical processor in the wait-for-
SIPI state results in the logical processor starting execution from the vector sent in the
SIPI regardless of the value of RIP before the SIPI was received. A virtual-machine
monitor (VMM) responding to a SIPI-induced VM exit can emulate this behavior because
the SIPI vector is saved in the lower 8 bits of the exit qualification field in the VMCS.
Such a VMM should be unaffected by this erratum. A VMM that does not emulate this
behavior may need to recover the old value of RIP through alternative means. Intel has
not observed this erratum with any commercially-available software.
Workaround: VMM software that may respond to SIPI-induced VM exits by resuming the interrupt
guest context without emulating the non-virtualized SIPI response should (1) save from
the VMCS (using VMREAD) the value of RIP before any VM entry to the wait-for SIPI
state; and (2) restore to the VMCS (using VMWRITE) that value before the next VM entry
that resumes the guest in any state other than wait-for-SIPI.
Status: For the steppings affected, see the Summary Tables of Changes.
To Next Page
Loading...
