Intel E6320 Specification Update - Page 24

FREEZE_WHILE_SMM Does Not Prevent Event From Pending PEBS

Page 24 highlights

BJ12. Problem: Faulting MMX Instruction May Incorrectly Update x87 FPU Tag Word Under a specific set of conditions, MMX stores (MOVD, MOVQ, MOVNTQ, MASKMOVQ) which cause memory access faults (#GP, #SS, #PF, or #AC), may incorrectly update the x87 FPU tag word register. This erratum will occur when the following additional conditions are also met: •The MMX store instruction must be the first MMX instruction to operate on x87 FPU state (i.e. the x87 FP tag word is not already set to 0x0000). •For MOVD, MOVQ, MOVNTQ stores, the instruction must use an addressing mode that uses an index register (this condition does not apply to MASKMOVQ). Implication: If the erratum conditions are met, the x87 FPU tag word register may be incorrectly set to a 0x0000 value when it should not have been modified. Workaround: None identified Status: For the steppings affected, see the Summary Tables of Changes. BJ13. Problem: FREEZE_WHILE_SMM Does Not Prevent Event From Pending PEBS During SMM In general, a PEBS record should be generated on the first count of the event after the counter has overflowed. However, IA32_DEBUGCTL_MSR.FREEZE_WHILE_SMM (MSR 1D9H, bit [14]) prevents performance counters from counting during SMM (System Management Mode). Due to this erratum, if: 1. A performance counter overflowed before an SMI. 2. A PEBS record has not yet been generated because another count of the event has not occurred. 3. The monitored event occurs during SMM then a PEBS record will be saved after the next RSM instruction. When FREEZE_WHILE_SMM is set, a PEBS should not be generated until the event occurs outside of SMM. Implication: A PEBS record may be saved after an RSM instruction due to the associated performance counter detecting the monitored event during SMM; even when FREEZE_WHILE_SMM is set. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. BJ14. General Protection Fault (#GP) for Instructions Greater than 15 Bytes May be Preempted Problem: When the processor encounters an instruction that is greater than 15 bytes in length, a #GP is signaled when the instruction is decoded. Under some circumstances, the #GP fault may be preempted by another lower priority fault (e.g. Page Fault (#PF)). However, if the preempting lower priority faults are resolved by the operating system and the instruction retried, a #GP fault will occur. Implication: Software may observe a lower-priority fault occurring before or in lieu of a #GP fault. Instructions of greater than 15 bytes in length can only occur if redundant prefixes are placed before the instruction. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. 24 Specification Update

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64

24
Specification Update
BJ12.
Faulting MMX Instruction May Incorrectly Update x87 FPU Tag Word
Problem:
Under a specific set of conditions, MMX stores (MOVD, MOVQ, MOVNTQ, MASKMOVQ)
which cause memory access faults (#GP, #SS, #PF, or #AC), may incorrectly update
the x87 FPU tag word register.
This erratum will occur when the following additional conditions are also met:
The MMX store instruction must be the first MMX instruction to operate on x87 FPU
state (i.e. the x87 FP tag word is not already set to 0x0000).
For MOVD, MOVQ, MOVNTQ stores, the instruction must use an addressing mode that
uses an index register (this condition does not apply to MASKMOVQ).
Implication:
If the erratum conditions are met, the x87 FPU tag word register may be incorrectly set
to a 0x0000 value when it should not have been modified.
Workaround:
None identified
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ13.
FREEZE_WHILE_SMM Does Not Prevent Event From Pending PEBS
During SMM
Problem:
In general, a PEBS record should be generated on the first count of the event after the
counter has overflowed. However, IA32_DEBUGCTL_MSR.FREEZE_WHILE_SMM (MSR
1D9H, bit [14]) prevents performance counters from counting during SMM (System
Management Mode). Due to this erratum, if:
1.
A performance counter overflowed before an SMI.
2.
A PEBS record has not yet been generated because another count of the event has
not occurred.
3.
The monitored event occurs during SMM then a PEBS record will be saved after the
next RSM instruction.
When FREEZE_WHILE_SMM is set, a PEBS should not be generated until the event
occurs outside of SMM.
Implication:
A PEBS record may be saved after an RSM instruction due to the associated
performance counter detecting the monitored event during SMM; even when
FREEZE_WHILE_SMM is set.
Workaround:
None identified.
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ14.
General Protection Fault (#GP) for Instructions Greater than 15 Bytes
May be Preempted
Problem:
When the processor encounters an instruction that is greater than 15 bytes in length, a
#GP is signaled when the instruction is decoded. Under some circumstances, the #GP
fault may be preempted by another lower priority fault (e.g. Page Fault (#PF)).
However, if the preempting lower priority faults are resolved by the operating system
and the instruction retried, a #GP fault will occur.
Implication:
Software may observe a lower-priority fault occurring before or in lieu of a #GP fault.
Instructions of greater than 15 bytes in length can only occur if redundant prefixes are
placed before the instruction.
Workaround:
None identified.
Status:
For the steppings affected, see the Summary Tables of Changes.