Intel E6320 Specification Update - Page 53

VM Exits Due to NMI-Window Exiting May Not Occur Following a VM

Page 53 highlights

 Implication: Due to this erratum, some undefined instruction encodings may produce a #NM instead of a #UD exception. Workaround: Software should always set the vvvv field of the VEX prefix to 1111b for instances of the VAESIMC and VAESKEYGENASSIST instructions. Status: For the steppings affected, see the Summary Tables of Changes. BJ108. Unexpected #UD on VZEROALL/VZEROUPPER Problem: Execution of the VZEROALL or VZEROUPPER instructions in 64-bit mode with VEX.W set to 1 may erroneously cause a #UD (invalid-opcode exception). Implication: The affected instructions may produce unexpected invalid-opcode exceptions in 64-bit mode. Workaround: Compilers should encode VEX.W = 0 for the VZEROALL and VZEROUPPER instructions. Status: For the steppings affected, see the Summary Tables of Changes. BJ109. Successive Fixed Counter Overflows May be Discarded Problem: Under specific internal conditions, when using Freeze PerfMon on PMI feature (bit 12 in IA32_DEBUGCTL.Freeze_PerfMon_on_PMI, MSR 1D9H), if two or more PerfMon Fixed Counters overflow very closely to each other, the overflow may be mishandled for some of them. This means that the counter's overflow status bit (in MSR_PERF_GLOBAL_STATUS, MSR 38EH) may not be updated properly; additionally, PMI interrupt may be missed if software programs a counter in Sampling-Mode (PMI bit is set on counter configuration). Implication: Successive Fixed Counter overflows may be discarded when Freeze PerfMon on PMI is used. Workaround: Software can avoid this by: •Avoid using Freeze PerfMon on PMI bit •Enable only one fixed counter at a time when using Freeze PerfMon on PMI Status: For the steppings affected, see the Summary Tables of Changes. BJ110. Execution of FXSAVE or FXRSTOR With the VEX Prefix May Produce a #NM Exception Problem: Attempt to use FXSAVE or FXRSTOR with a VEX prefix should produce a #UD (InvalidOpcode) exception. If either the TS or EM flag bits in CR0 are set, a #NM (device-notavailable) exception will be raised instead of #UD exception. Implication: Due to this erratum a #NM exception may be signaled instead of a #UD exception on an FXSAVE or an FXRSTOR with a VEX prefix. Workaround: Software should not use FXSAVE or FXRSTOR with the VEX prefix. Status: For the steppings affected, see the Summary Tables of Changes. BJ111. Problem: Implication: VM Exits Due to "NMI-Window Exiting" May Not Occur Following a VM Entry to the Shutdown State If VM entry is made with the "virtual NMIs" and "NMI-window exiting", VM-execution controls set to 1, and if there is no virtual-NMI blocking after VM entry, a VM exit with exit reason "NMI window" should occur immediately after VM entry unless the VM entry put the logical processor in the wait-for SIPI state. Due to this erratum, such VM exits do not occur if the VM entry put the processor in the shutdown state. A VMM may fail to deliver a virtual NMI to a virtual machine in the shutdown state. Specification Update 53

  • 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

Specification Update
53
Implication:
Due to this erratum, some undefined instruction encodings may produce a #NM instead
of a #UD exception.
Workaround:
Software should always set the vvvv field of the VEX prefix to 1111b for instances of
the VAESIMC and VAESKEYGENASSIST instructions.
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ108.
Unexpected #UD on VZEROALL/VZEROUPPER
Problem:
Execution of the VZEROALL or VZEROUPPER instructions in 64-bit mode with VEX.W set
to 1 may erroneously cause a #UD (invalid-opcode exception).
Implication:
The affected instructions may produce unexpected invalid-opcode exceptions in 64-bit
mode.
Workaround:
Compilers should encode VEX.W = 0 for the VZEROALL and VZEROUPPER instructions.
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ109.
Successive Fixed Counter Overflows May be Discarded
Problem:
Under specific internal conditions, when using Freeze PerfMon on PMI feature (bit 12 in
IA32_DEBUGCTL.Freeze_PerfMon_on_PMI, MSR 1D9H), if two or more PerfMon Fixed
Counters overflow very closely to each other, the overflow may be mishandled for some
of them. This means that the counter’s overflow status bit (in
MSR_PERF_GLOBAL_STATUS, MSR 38EH) may not be updated properly; additionally,
PMI interrupt may be missed if software programs a counter in Sampling-Mode (PMI bit
is set on counter configuration).
Implication:
Successive Fixed Counter overflows may be discarded when Freeze PerfMon on PMI is
used.
Workaround:
Software can avoid this by:
Avoid using Freeze PerfMon on PMI bit
Enable only one fixed counter at a time when using Freeze PerfMon on PMI
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ110.
Execution of FXSAVE or FXRSTOR With the VEX Prefix May Produce a
#NM Exception
Problem:
Attempt to use FXSAVE or FXRSTOR with a VEX prefix should produce a #UD (Invalid-
Opcode) exception. If either the TS or EM flag bits in CR0 are set, a #NM (device-not-
available) exception will be raised instead of #UD exception.
Implication:
Due to this erratum a #NM exception may be signaled instead of a #UD exception on
an FXSAVE or an FXRSTOR with a VEX prefix.
Workaround:
Software should not use FXSAVE or FXRSTOR with the VEX prefix.
Status:
For the steppings affected, see the Summary Tables of Changes.
BJ111.
VM Exits Due to “NMI-Window Exiting” May Not Occur Following a VM
Entry to the Shutdown State
Problem:
If VM entry is made with the “virtual NMIs” and “NMI-window exiting”, VM-execution
controls set to 1, and if there is no virtual-NMI blocking after VM entry, a VM exit with
exit reason “NMI window” should occur immediately after VM entry unless the VM entry
put the logical processor in the wait-for SIPI state. Due to this erratum, such VM exits
do not occur if the VM entry put the processor in the shutdown state.
Implication:
A VMM may fail to deliver a virtual NMI to a virtual machine in the shutdown state.