Intel Xeon Processor LV and ULV Specification Update

Errata
Specification Update 19
AF4. REP MOVS/STOS Executing with Fast Strings Enabled and Crossing
Page Boundaries with Inconsistent Memory Types may use an
Incorrect Data Size or Lead to Memory-Ordering Violation
Problem: Under certain conditions as described in the Software Developers Manual section ―Out-
of-Order Stores For String Operations in Pentium 4, Intel Xeon, and P6 Family
Processors‖ the processor performs REP MOVS or REP STOS as fast strings. Due to
this erratum fast string REP MOVS/REP STOS instructions that cross page boundaries
from WB/WC memory types to UC/WP/WT memory types, may start using an incorrect
data size or may observe memory ordering violations.
Implication: Implication: Upon crossing the page boundary the following may occur, dependent
on the new page memory type:
• UC the data size of each write will now always be 8 bytes, as opposed to the
original data size.
• WP the data size of each write will now always be 8 bytes, as opposed to the
original data size and there may be a memory ordering violation.
• WT there may be a memory ordering violation.
Status: For the steppings affected, see the Summary Tables of Changes.
AF5. Memory Aliasing with Inconsistent A and D Bits May Cause Processor
Deadlock
Problem: In the event that software implements memory aliasing by having two Page Directory
Entries (PDEs) point to a common Page Table Entry (PTE) and the Accessed and Dirty
bits for the two PDEs are allowed to become inconsistent the processor may become
deadlocked.
Implication: This erratum has not been observed with commercially available software.
Workaround: Software that needs to implement memory aliasing in this way should manage the
consistency of the Accessed and Dirty bits.
Status: For the steppings affected, see the Summary Tables of Changes.
AF6. VM Bit is Cleared on Second Fault Handled by Task Switch from
Virtual-8086
Problem: Following a task switch to any fault handler that was initiated while the processor was
in VM86 mode, if there is an additional fault while servicing the original task switch
then the VM bit will be incorrectly cleared in EFLAGS, data segments will not be
pushed and the processor will not return to the correct mode upon completion of the
second fault handler via IRET.
Implication: When the OS recovers from the second fault handler, the processor will no longer be
in VM86 mode. Normally, operating systems should prevent interrupt task switches
from faulting, thus the scenario should not occur under normal circumstances.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.