Intel E5405 - Cpu Xeon Quad Core 2.00Ghz Fsb1333Mhz 12M Lga771 Tray Specification page 30

AX42. 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
AX43. 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
AX44. NMIs May Not Be Blocked by a VM-Entry Failure
Problem: The Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B:
System Programming Guide, Part 2 specifies that, following a VM-entry failure during or
after loading guest state, "the state of blocking by NMI is what it was before VM entry."
If non-maskable interrupts (NMIs) are blocked and the "virtual NMIs" VM-execution
control set to 1, this erratum may result in NMIs not being blocked after a VM-entry
failure during or after loading guest state.
Implication: VM-entry failures that cause NMIs to become unblocked may cause the processor to
deliver an NMI to software that is not prepared for it.
Workaround: VMM software should configure the virtual-machine control structure (VMCS) so that
VM-entry failures do not occur.
Status: For the steppings affected, see the
Intel® Xeon® Processor 5400 Series
Specification Update
Summary Tables of Changes.
Summary Tables of Changes.
Summary Tables of Changes.
30