Specification Update
Table Of Contents

Errata
Specification Update 77
W108. Unsynchronized Cross-Modifying Code Operations Can
Cause Unexpected Instruction Execution Results
Problem: The act of one processor, or system bus master, writing data into a
currently executing code segment of a second processor with the intent
of having the second processor execute that data as code is called
cross-modifying code (XMC). XMC that does not force the second
processor to execute a synchronizing instruction, prior to execution of
the new code, is called unsynchronized XMC. Software using
unsynchronized XMC to modify the instruction byte stream of a
processor can see unexpected or unpredictable execution behavior from
the processor that is executing the modified code.
Implication: In this case, the phrase "unexpected or unpredictable execution
behavior" encompasses the generation of most of the exceptions listed
in the Intel® 64 and IA-32 Architecture Software Developer’s Manual
Volume 3: System Programming Guide, including a General Protection
Fault (GPF) or other unexpected behaviors. In the event that
unpredictable execution causes a GPF the application executing the
unsynchronized XMC operation would be terminated by the operating
system.
Workaround: In order to avoid this erratum, programmers should use the XMC synchronization
algorithm as detailed in the Intel® 64 and IA-32 Architecture Software
Developer’s Manual, Volume 3: System Programming Guide, Section:
Handling Self- and Cross-Modifying Code.
Status: For the steppings affected, see the Summary Tables of Changes.
W109. Split Locked Stores May Not Trigger the Monitoring
Hardware
Problem: Logical processors normally resume program execution following the
MWAIT, when another logical processor performs a write access to a
WB cacheable address within the address range used to perform the
MONITOR operation. Due to this erratum, a logical processor may not
resume execution until the next targeted interrupt event or O/S timer
tick following a locked store that spans across cache lines within the
monitored address range.
Implication: The logical processor that executed the MWAIT instruction may not
resume execution until the next targeted interrupt event or O/S timer
tick in the case where the monitored address is written by a locked
store which is split across cache lines.
Workaround: Do not use locked stores that span cache lines in the monitored address range.
Status: For the steppings affected, see the Summary Tables of Changes.