Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023)

MEMORY CACHE CONTROL

Table 12-7. Effective Page-Level Memory Types for Pentium III and More Recent Processor Families (Contd.)

MTRR Memory Type

PAT Entry Value

Effective Memory Type

UC²

UC-

WC³

WT³

NOTES:

1. The UC attribute comes from the MTRRs and the processors are not required to snoop their caches since the data could never have

been cached. This attribute is preferred for performance reasons.

2. The UC attribute came from the page-table or page-directory entry and processors are required to check their caches because the

data may be cached due to page aliasing, which is not recommended.

3. These combinations were specified as “undefined” in previous editions of the Intel^® 64 and IA-32 Architectures Software Devel-

oper’s Manual. However, all processors that support both the PAT and the MTRRs determine the effective page-level memory

types for these combinations as given.

12.5.2.3 Writing Values Across Pages with Different Memory Types

If two adjoining pages in memory have different memory types, and a word or longer operand is written to a

memory location that crosses the page boundary between those two pages, the operand might be written to

memory twice. This action does not present a problem for writes to actual memory; however, if a device is mapped

to the memory space assigned to the pages, the device might malfunction.

12.5.3 Preventing Caching

To disable the L1, L2, and L3 caches after they have been enabled and have received cache fills, perform the

following steps:

1. Enter the no-fill cache mode. (Set the CD flag in control register CR0 to 1 and the NW flag to 0.

2. Flush all caches using the WBINVD instruction.

3. Disable the MTRRs and set the default memory type to uncached or set all MTRRs for the uncached memory

type (see the discussion of the discussion of the TYPE field and the E flag in Section 12.11.2.1, “IA32_MTR-

R_DEF_TYPE MSR”).

The caches must be flushed (step 2) after the CD flag is set to ensure system memory coherency. If the caches are

not flushed, cache hits on reads will still occur and data will be read from valid cache lines.

The intent of the three separate steps listed above address three distinct requirements: (i) discontinue new data

replacing existing data in the cache (ii) ensure data already in the cache are evicted to memory, (iii) ensure subse-

quent memory references observe UC memory type semantics. Different processor implementation of caching

control hardware may allow some variation of software implementation of these three requirements. See note

below.

NOTES

Setting the CD flag in control register CR0 modifies the processor’s caching behavior as indicated in

Table 12-5, but setting the CD flag alone may not be sufficient across all processor families to force

the effective memory type for all physical memory to be UC nor does it force strict memory

ordering, due to hardware implementation variations across different processor families. To force

the UC memory type and strict memory ordering on all of physical memory, it is sufficient to either

program the MTRRs for all physical memory to be UC memory type or disable all MTRRs.

For the Pentium 4 and Intel Xeon processors, after the sequence of steps given above has been

executed, the cache lines containing the code between the end of the WBINVD instruction and

before the MTRRS have actually been disabled may be retained in the cache hierarchy. Here, to

12-16

Vol. 3A

MEMORY CACHE CONTROL

remove code from the cache completely, a second WBINVD instruction must be executed after the

MTRRs have been disabled.

For Intel Atom processors, setting the CD flag forces all physical memory to observe UC semantics

(without requiring memory type of physical memory to be set explicitly). Consequently, software

does not need to issue a second WBINVD as some other processor generations might require.

12.5.4 Disabling and Enabling the L3 Cache

On processors based on Intel NetBurst microarchitecture, the third-level cache can be disabled by bit 6 of the

IA32_MISC_ENABLE MSR. The third-level cache disable flag (bit 6 of the IA32_MISC_ENABLE MSR) allows the L3

cache to be disabled and enabled, independently of the L1 and L2 caches. Prior to using this control to disable or

enable the L3 cache, software should disable and flush all the processor caches, as described earlier in Section

12.5.3, “Preventing Caching,” to prevent of loss of information stored in the L3 cache. After the L3 cache has been

disabled or enabled, caching for the whole processor can be restored.

Newer Intel 64 processor with L3 do not support IA32_MISC_ENABLE[bit 6], the procedure described in Section

12.5.3, “Preventing Caching,” apply to the entire cache hierarchy.

12.5.5 Cache Management Instructions

The Intel 64 and IA-32 architectures provide several instructions for managing the L1, L2, and L3 caches. The INVD

and WBINVD instructions are privileged instructions and operate on the L1, L2, and L3 caches as a whole. The

PREFETCHh, CLFLUSH, and CLFLUSHOPT instructions and the non-temporal move instructions (MOVNTI, MOVNTQ,

MOVNTDQ, MOVNTPS, and MOVNTPD) offer more granular control over caching, and are available to all privileged

levels.

The INVD and WBINVD instructions are used to invalidate the contents of the L1, L2, and L3 caches. The INVD

instruction invalidates all internal cache entries, then generates a special-function bus cycle that indicates that

external caches also should be invalidated. The INVD instruction should be used with care. It does not force a

write-back of modified cache lines; therefore, data stored in the caches and not written back to system memory

will be lost. Unless there is a specific requirement or benefit to invalidating the caches without writing back the

modified lines (such as, during testing or fault recovery where cache coherency with main memory is not a

concern), software should use the WBINVD instruction.

The WBINVD instruction first writes back any modified lines in all the internal caches, then invalidates the contents

of the L1, L2, and L3 caches. It ensures that cache coherency with main memory is maintained regardless of the

write policy in effect (that is, write-through or write-back). Following this operation, the WBINVD instruction gener-

ates one (P6 family processors) or two (Pentium and Intel486 processors) special-function bus cycles to indicate to

external cache controllers that write-back of modified data followed by invalidation of external caches should occur.

The amount of time or cycles for WBINVD to complete will vary due to the size of different cache hierarchies and

other factors. As a consequence, the use of the WBINVD instruction can have an impact on interrupt/event

response time.

The PREFETCHh instructions allow a program to suggest to the processor that a cache line from a specified location

in system memory be prefetched into the cache hierarchy (see Section 12.8, “Explicit Caching”).

The CLFLUSH and CLFLUSHOPT instructions allow selected cache lines to be flushed from memory. These instruc-

tions give a program the ability to explicitly free up cache space, when it is known that cached section of system

memory will not be accessed in the near future.

The non-temporal move instructions (MOVNTI, MOVNTQ, MOVNTDQ, MOVNTPS, and MOVNTPD) allow data to be

moved from the processor’s registers directly into system memory without being also written into the L1, L2,

and/or L3 caches. These instructions can be used to prevent cache pollution when operating on data that is going

to be modified only once before being stored back into system memory. These instructions operate on data in the

general-purpose, MMX, and XMM registers.

Vol. 3A

12-17

MEMORY CACHE CONTROL

12.5.6 L1 Data Cache Context Mode

L1 data cache context mode is a feature of processors based on the Intel NetBurst microarchitecture that support

Intel Hyper-Threading Technology. When CPUID.1:ECX[bit 10] = 1, the processor supports setting L1 data cache

context mode using the L1 data cache context mode flag ( IA32_MISC_ENABLE[bit 24] ). Selectable modes are

adaptive mode (default) and shared mode.

The BIOS is responsible for configuring the L1 data cache context mode.

12.5.6.1 Adaptive Mode

Adaptive mode facilitates L1 data cache sharing between logical processors. When running in adaptive mode, the

L1 data cache is shared across logical processors in the same core if:

• CR3 control registers for logical processors sharing the cache are identical.

• The same paging mode is used by logical processors sharing the cache.

In this situation, the entire L1 data cache is available to each logical processor (instead of being competitively

shared).

If CR3 values are different for the logical processors sharing an L1 data cache or the logical processors use different

paging modes, processors compete for cache resources. This reduces the effective size of the cache for each logical

processor. Aliasing of the cache is not allowed (which prevents data thrashing).

12.5.6.2 Shared Mode

In shared mode, the L1 data cache is competitively shared between logical processors. This is true even if the

logical processors use identical CR3 registers and paging modes.

In shared mode, linear addresses in the L1 data cache can be aliased, meaning that one linear address in the cache

can point to different physical locations. The mechanism for resolving aliasing can lead to thrashing. For this

reason, IA32_MISC_ENABLE[bit 24] = 0 is the preferred configuration for processors based on the Intel NetBurst

microarchitecture that support Intel Hyper-Threading Technology.

12.6

SELF-MODIFYING CODE

A write to a memory location in a code segment that is currently cached in the processor causes the associated

cache line (or lines) to be invalidated. This check is based on the physical address of the instruction. In addition,

the P6 family and Pentium processors check whether a write to a code segment may modify an instruction that has

been prefetched for execution. If the write affects a prefetched instruction, the prefetch queue is invalidated. This

latter check is based on the linear address of the instruction. For the Pentium 4 and Intel Xeon processors, a write

or a snoop of an instruction in a code segment, where the target instruction is already decoded and resident in the

trace cache, invalidates the entire trace cache. The latter behavior means that programs that self-modify code can

cause severe degradation of performance when run on the Pentium 4 and Intel Xeon processors.

In practice, the check on linear addresses should not create compatibility problems among IA-32 processors. Appli-

cations that include self-modifying code use the same linear address for modifying and fetching the instruction.

Systems software, such as a debugger, that might possibly modify an instruction using a different linear address

than that used to fetch the instruction, will execute a serializing operation, such as a CPUID instruction, before the

modified instruction is executed, which will automatically resynchronize the instruction cache and prefetch queue.

(See Section 9.1.3, “Handling Self- and Cross-Modifying Code,” for more information about the use of self-modi-

fying code.)

For Intel486 processors, a write to an instruction in the cache will modify it in both the cache and memory, but if

the instruction was prefetched before the write, the old version of the instruction could be the one executed. To

prevent the old instruction from being executed, flush the instruction prefetch unit by coding a jump instruction

immediately after any write that modifies an instruction.

12-18

Vol. 3A

MEMORY CACHE CONTROL

12.7

IMPLICIT CACHING (PENTIUM 4, INTEL® XEON®, AND P6 FAMILY

PROCESSORS)

Implicit caching occurs when a memory element is made potentially cacheable, although the element may never

have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent

processor families due to aggressive prefetching, branch prediction, and TLB miss handling. Implicit caching is an

extension of the behavior of existing Intel386, Intel486, and Pentium processor systems, since software running

on these processor families also has not been able to deterministically predict the behavior of instruction prefetch.

To avoid problems related to implicit caching, the operating system must explicitly invalidate the cache when

changes are made to cacheable data that the cache coherency mechanism does not automatically handle. This

includes writes to dual-ported or physically aliased memory boards that are not detected by the snooping mecha-

nisms of the processor, and changes to page- table entries in memory.

The code in Example 12-1 shows the effect of implicit caching on page-table entries. The linear address F000H

points to physical location B000H (the page-table entry for F000H contains the value B000H), and the page-table

entry for linear address F000 is PTE_F000.

Example 12-1. Effect of Implicit Caching on Page-Table Entries

mov EAX, CR3; Invalidate the TLB

mov CR3, EAX; by copying CR3 to itself

mov PTE_F000, A000H; Change F000H to point to A000H

mov EBX, [F000H];

Because of speculative execution in the P6 and more recent processor families, the last MOV instruction performed

would place the value at physical location B000H into EBX, rather than the value at the new physical address

A000H. This situation is remedied by placing a TLB invalidation between the load and the store.

12.8

EXPLICIT CACHING

The Pentium III processor introduced four new instructions, the PREFETCHh instructions, that provide software with

explicit control over the caching of data. These instructions provide “hints” to the processor that the data requested

by a PREFETCHh instruction should be read into cache hierarchy now or as soon as possible, in anticipation of its

use. The instructions provide different variations of the hint that allow selection of the cache level into which data

will be read.

The PREFETCHh instructions can help reduce the long latency typically associated with reading data from memory

and thus help prevent processor “stalls.” However, these instructions should be used judiciously. Overuse can lead

to resource conflicts and hence reduce the performance of an application. Also, these instructions should only be

used to prefetch data from memory; they should not be used to prefetch instructions. For more detailed informa-

tion on the proper use of the prefetch instruction, refer to Chapter 7, “Optimizing Cache Usage,” in the Intel® 64

and IA-32 Architectures Optimization Reference Manual.

12.9

INVALIDATING THE TRANSLATION LOOKASIDE BUFFERS (TLBS)

The processor updates its address translation caches (TLBs) transparently to software. Several mechanisms are

available, however, that allow software and hardware to invalidate the TLBs either explicitly or as a side effect of

another operation. Most details are given in Section 4.10.4, “Invalidation of TLBs and Paging-Structure Caches.” In

addition, the following operations invalidate all TLB entries, irrespective of the setting of the G flag:

• Asserting or de-asserting the FLUSH# pin.

• (Pentium 4, Intel Xeon, and later processors only.) Writing to an MTRR (with a WRMSR instruction).

• Writing to control register CR0 to modify the PG or PE flag.

Vol. 3A

12-19

MEMORY CACHE CONTROL

• (Pentium 4, Intel Xeon, and later processors only.) Writing to control register CR4 to modify the PSE, PGE, or

PAE flag.

• Writing to control register CR4 to change the PCIDE flag from 1 to 0.

See Section 4.10, “Caching Translation Information,” for additional information about the TLBs.

12.10 STORE BUFFER

Intel 64 and IA-32 processors temporarily store each write (store) to memory in a store buffer. The store buffer

improves processor performance by allowing the processor to continue executing instructions without having to

wait until a write to memory and/or to a cache is complete. It also allows writes to be delayed for more efficient use

of memory-access bus cycles.

In general, the existence of the store buffer is transparent to software, even in systems that use multiple proces-

sors. The processor ensures that write operations are always carried out in program order. It also ensures that the

contents of the store buffer are always drained to memory in the following situations:

• When an exception or interrupt is generated.

• (P6 and more recent processor families only) When a serializing instruction is executed.

• When an I/O instruction is executed.

• When a LOCK operation is performed.

• (P6 and more recent processor families only) When a BINIT operation is performed.

• (Pentium III, and more recent processor families only) When using an SFENCE instruction to order stores.

• (Pentium 4 and more recent processor families only) When using an MFENCE instruction to order stores.

The discussion of write ordering in Section 9.2, “Memory Ordering,” gives a detailed description of the operation of

the store buffer.

12.11 MEMORY TYPE RANGE REGISTERS (MTRRS)

The following section pertains only to the P6 and more recent processor families.

The memory type range registers (MTRRs) provide a mechanism for associating the memory types (see Section

12.3, “Methods of Caching Available”) with physical-address ranges in system memory. They allow the processor to

optimize operations for different types of memory such as RAM, ROM, frame-buffer memory, and memory-mapped

I/O devices. They also simplify system hardware design by eliminating the memory control pins used for this func-

tion on earlier IA-32 processors and the external logic needed to drive them.

The MTRR mechanism allows multiple ranges to be defined in physical memory, and it defines a set of model-

specific registers (MSRs) for specifying the type of memory that is contained in each range. Table 12-8 shows the

memory types that can be specified and their properties; Figure 12-4 shows the mapping of physical memory with

MTRRs. See Section 12.3, “Methods of Caching Available,” for a more detailed description of each memory type.

Following a hardware reset, the P6 and more recent processor families disable all the fixed and variable MTRRs,

which in effect makes all of physical memory uncacheable. Initialization software should then set the MTRRs to a

specific, system-defined memory map. Typically, the BIOS (basic input/output system) software configures the

MTRRs. The operating system or executive is then free to modify the memory map using the normal page-level

cacheability attributes.

In a multiprocessor system using a processor in the P6 family or a more recent family, each processor MUST use

the identical MTRR memory map so that software will have a consistent view of memory.

NOTE

In multiple processor systems, the operating system must maintain MTRR consistency between all

the processors in the system (that is, all processors must use the same MTRR values). The P6 and

more recent processor families provide no hardware support for maintaining this consistency.

12-20

Vol. 3A

MEMORY CACHE CONTROL

Table 12-8. Memory Types That Can Be Encoded in MTRRs

Memory Type and Mnemonic

Encoding in MTRR

Uncacheable (UC)

00H

Write Combining (WC)

01H

Reserved*

02H

Reserved*

03H

Write-through (WT)

04H

Write-protected (WP)

05H

Writeback (WB)

06H

Reserved*

7H through FFH

NOTE:

* Use of these encodings results in a general-protection exception (#GP).

Physical Memory

FFFFFFFFH

Address ranges not

mapped by an MTRR

are set to a default type

Variable ranges

(from 4 KBytes to

maximum size of

physical memory)

100000H

64 fixed ranges

FFFFFH

256 KBytes

(4 KBytes each)

C0000H

16 fixed ranges

BFFFFH

256 KBytes

(16 KBytes each)

80000H

7FFFFH

8 fixed ranges

512 KBytes

(64-KBytes each)

Figure 12-4. Mapping Physical Memory With MTRRs

12.11.1 MTRR Feature Identification

The availability of the MTRR feature is model-specific. Software can determine if MTRRs are supported on a

processor by executing the CPUID instruction and reading the state of the MTRR flag (bit 12) in the feature infor-

mation register (EDX).

If the MTRR flag is set (indicating that the processor implements MTRRs), additional information about MTRRs can

be obtained from the 64-bit IA32_MTRRCAP MSR (named MTRRcap MSR for the P6 family processors). The

IA32_MTRRCAP MSR is a read-only MSR that can be read with the RDMSR instruction. Figure 12-5 shows the

contents of the IA32_MTRRCAP MSR. The functions of the flags and field in this register are as follows:

Vol. 3A

12-21

MEMORY CACHE CONTROL

• VCNT (variable range registers count) field, bits 0 through 7 - Indicates the number of variable ranges

implemented on the processor.

• FIX (fixed range registers supported) flag, bit 8 - Fixed range MTRRs (IA32_MTRR_FIX64K_00000

through IA32_MTRR_FIX4K_0F8000) are supported when set; no fixed range registers are supported when

clear.

• WC (write combining) flag, bit 10 - The write-combining (WC) memory type is supported when set; the

WC type is not supported when clear.

• SMRR (System-Management Range Register) flag, bit 11 - The system-management range register

(SMRR) interface is supported when bit 11 is set; the SMRR interface is not supported when clear.

Bit 9 and bits 12 through 63 in the IA32_MTRRCAP MSR are reserved. If software attempts to write to the

IA32_MTRRCAP MSR, a general-protection exception (#GP) is generated.

Software must read IA32_MTRRCAP VCNT field to determine the number of variable MTRRs and query other

feature bits in IA32_MTRRCAP to determine additional capabilities that are supported in a processor. For example,

some processors may report a value of ‘8’ in the VCNT field, other processors may report VCNT with different

values.

Reserved

VCNT

SMRR - SMRR interface supported

WC - Write-combining memory type supported

FIX - Fixed range registers supported

VCNT - Number of variable range registers

Reserved

Figure 12-5. IA32_MTRRCAP Register

12.11.2 Setting Memory Ranges with MTRRs

The memory ranges and the types of memory specified in each range are set by three groups of registers: the

IA32_MTRR_DEF_TYPE MSR, the fixed-range MTRRs, and the variable range MTRRs. These registers can be read

and written to using the RDMSR and WRMSR instructions, respectively. The IA32_MTRRCAP MSR indicates the

availability of these registers on the processor (see Section 12.11.1, “MTRR Feature Identification”).

12.11.2.1 IA32_MTRR_DEF_TYPE MSR

The IA32_MTRR_DEF_TYPE MSR (named MTRRdefType MSR for the P6 family processors) sets the default proper-

ties of the regions of physical memory that are not encompassed by MTRRs. The functions of the flags and field in

this register are as follows:

• Type field, bits 0 through 7 - Indicates the default memory type used for those physical memory address

ranges that do not have a memory type specified for them by an MTRR (see Table 12-8 for the encoding of this

field). The legal values for this field are 0, 1, 4, 5, and 6. All other values result in a general-protection

exception (#GP) being generated.

Intel recommends the use of the UC (uncached) memory type for all physical memory addresses where

memory does not exist. To assign the UC type to nonexistent memory locations, it can either be specified as the

default type in the Type field or be explicitly assigned with the fixed and variable MTRRs.

12-22

Vol. 3A

MEMORY CACHE CONTROL

1211

Reserved

Type

E - MTRR enable/disable

FE - Fixed-range MTRRs enable/disable

Type - Default memory type

Reserved

Figure 12-6. IA32_MTRR_DEF_TYPE MSR

• FE (fixed MTRRs enabled) flag, bit 10 - Fixed-range MTRRs are enabled when set; fixed-range MTRRs are

disabled when clear. When the fixed-range MTRRs are enabled, they take priority over the variable-range

MTRRs when overlaps in ranges occur. If the fixed-range MTRRs are disabled, the variable-range MTRRs can

still be used and can map the range ordinarily covered by the fixed-range MTRRs.

• E (MTRRs enabled) flag, bit 11 - MTRRs are enabled when set; all MTRRs are disabled when clear, and the

UC memory type is applied to all of physical memory. When this flag is set, the FE flag can disable the fixed-

range MTRRs; when the flag is clear, the FE flag has no affect. When the E flag is set, the type specified in the

default memory type field is used for areas of memory not already mapped by either a fixed or variable MTRR.

Bits 8 and 9, and bits 12 through 63, in the IA32_MTRR_DEF_TYPE MSR are reserved; the processor generates a

general-protection exception (#GP) if software attempts to write nonzero values to them.

12.11.2.2 Fixed Range MTRRs

The fixed memory ranges are mapped with 11 fixed-range registers of 64 bits each. Each of these registers is

divided into 8-bit fields that are used to specify the memory type for each of the sub-ranges the register controls:

• Register IA32_MTRR_FIX64K_00000 - Maps the 512-KByte address range from 0H to 7FFFFH. This range

is divided into eight 64-KByte sub-ranges.

• Registers IA32_MTRR_FIX16K_80000 and IA32_MTRR_FIX16K_A0000 - Maps the two 128-KByte

address ranges from 80000H to BFFFFH. This range is divided into sixteen 16-KByte sub-ranges, 8 ranges per

• Registers IA32_MTRR_FIX4K_C0000 through IA32_MTRR_FIX4K_F8000 - Maps eight 32-KByte

address ranges from C0000H to FFFFFH. This range is divided into sixty-four 4-KByte sub-ranges, 8 ranges per

Table 12-9 shows the relationship between the fixed physical-address ranges and the corresponding fields of the

fixed-range MTRRs; Table 12-8 shows memory type encoding for MTRRs.

For the P6 family processors, the prefix for the fixed range MTRRs is MTRRfix.

12.11.2.3 Variable Range MTRRs

The Pentium 4, Intel Xeon, and P6 family processors permit software to specify the memory type for m variable-

size address ranges, using a pair of MTRRs for each range. The number m of ranges supported is given in bits 7:0

of the IA32_MTRRCAP MSR (see Figure 12-5 in Section 12.11.1).

The first entry in each pair (IA32_MTRR_PHYSBASEn) defines the base address and memory type for the range;

the second entry (IA32_MTRR_PHYSMASKn) contains a mask used to determine the address range. The “n” suffix

is in the range 0 through m-1 and identifies a specific register pair.

For P6 family processors, the prefixes for these variable range MTRRs are MTRRphysBase and MTRRphysMask.

Vol. 3A

12-23

MEMORY CACHE CONTROL

Table 12-9. Address Mapping for Fixed-Range MTRRs

Address Range (hexadecimal)

MTRR

70000-

60000-

50000-

40000-

30000-

20000-

10000-

00000-

IA32_MTRR_

7FFFF

6FFFF

5FFFF

4FFFF

3FFFF

2FFFF

1FFFF

0FFFF

FIX64K_00000

9C000

98000-

94000-

90000-

8C000-

88000-

84000-

80000-

IA32_MTRR_

9FFFF

9BFFF

97FFF

93FFF

8FFFF

8BFFF

87FFF

83FFF

FIX16K_80000

BC000

B8000-

B4000-

B0000-

AC000-

A8000-

A4000-

A0000-

IA32_MTRR_

BFFFF

BBFFF

B7FFF

B3FFF

AFFFF

ABFFF

A7FFF

A3FFF

FIX16K_A0000

C7000

C6000-

C5000-

C4000-

C3000-

C2000-

C1000-

C0000-

IA32_MTRR_

C7FFF

C6FFF

C5FFF

C4FFF

C3FFF

C2FFF

C1FFF

C0FFF

FIX4K_C0000

CF000

CE000-

CD000-

CC000-

CB000-

CA000-

C9000-

C8000-

IA32_MTRR_

CFFFF

CEFFF

CDFFF

CCFFF

CBFFF

CAFFF

C9FFF

C8FFF

FIX4K_C8000

D7000

D6000-

D5000-

D4000-

D3000-

D2000-

D1000-

D0000-

IA32_MTRR_

D7FFF

D6FFF

D5FFF

D4FFF

D3FFF

D2FFF

D1FFF

D0FFF

FIX4K_D0000

DF000

DE000-

DD000-

DC000-

DB000-

DA000-

D9000-

D8000-

IA32_MTRR_

DFFFF

DEFFF

DDFFF

DCFFF

DBFFF

DAFFF

D9FFF

D8FFF

FIX4K_D8000

E7000

E6000-

E5000-

E4000-

E3000-

E2000-

E1000-

E0000-

IA32_MTRR_

E7FFF

E6FFF

E5FFF

E4FFF

E3FFF

E2FFF

E1FFF

E0FFF

FIX4K_E0000

EF000

EE000-

ED000-

EC000-

EB000-

EA000-

E9000-

E8000-

IA32_MTRR_

EFFFF

EEFFF

EDFFF

ECFFF

EBFFF

EAFFF

E9FFF

E8FFF

FIX4K_E8000

F7000

F6000-

F5000-

F4000-

F3000-

F2000-

F1000-

F0000-

IA32_MTRR_

F7FFF

F6FFF

F5FFF

F4FFF

F3FFF

F2FFF

F1FFF

F0FFF

FIX4K_F0000

FF000

FE000-

FD000-

FC000-

FB000-

FA000-

F9000-

F8000-

IA32_MTRR_

FFFFF

FEFFF

FDFFF

FCFFF

FBFFF

FAFFF

F9FFF

F8FFF

FIX4K_F8000

Figure 12-7 shows flags and fields in these registers. The functions of these flags and fields are:

• Type field, bits 0 through 7 - Specifies the memory type for the range (see Table 12-8 for the encoding of

this field).

• PhysBase field, bits 12 through (MAXPHYADDR-1) - Specifies the base address of the address range.

This 24-bit value, in the case where MAXPHYADDR is 36 bits, is extended by 12 bits at the low end to form the

base address (this automatically aligns the address on a 4-KByte boundary).

• PhysMask field, bits 12 through (MAXPHYADDR-1) - Specifies a mask (24 bits if the maximum physical

address size is 36 bits, 28 bits if the maximum physical address size is 40 bits). The mask determines the range

of the region being mapped, according to the following relationships:

- Address_Within_Range AND PhysMask = PhysBase AND PhysMask

- This value is extended by 12 bits at the low end to form the mask value. For more information: see Section

12.11.3, “Example Base and Mask Calculations.”

- The width of the PhysMask field depends on the maximum physical address size supported by the

processor.

CPUID.80000008H reports the maximum physical address size supported by the processor. If

CPUID.80000008H is not available, software may assume that the processor supports a 36-bit physical

address size (then PhysMask is 24 bits wide and the upper 28 bits of IA32_MTRR_PHYSMASKn are

reserved). See the Note below.

• V (valid) flag, bit 11 - Enables the register pair when set; disables register pair when clear.

12-24

Vol. 3A

MEMORY CACHE CONTROL

IA32_MTRR_PHYSBASEn Register

MAXPHYADDR

1211

Reserved

PhysBase

Type

PhysBase - Base address of range

Type - Memory type for range

IA32_MTRR_PHYSMASKn Register

MAXPHYADDR

121110

Reserved

PhysMask

Reserved

PhysMask - Sets range mask

V - Valid

Reserved

MAXPHYADDR: The bit position indicated by MAXPHYADDR depends on the maximum

physical address range supported by the processor. It is reported by CPUID leaf

function 80000008H. If CPUID does not support leaf 80000008H, the processor

supports 36-bit physical address size, then bit PhysMask consists of bits 35:12, and

bits 63:36 are reserved.

Figure 12-7. IA32_MTRR_PHYSBASEn and IA32_MTRR_PHYSMASKn Variable-Range Register Pair

All other bits in the IA32_MTRR_PHYSBASEn and IA32_MTRR_PHYSMASKn registers are reserved; the processor

generates a general-protection exception (#GP) if software attempts to write to them.

Some mask values can result in ranges that are not continuous. In such ranges, the area not mapped by the mask

value is set to the default memory type, unless some other MTRR specifies a type for that range. Intel does not

encourage the use of “discontinuous” ranges.

NOTE

It is possible for software to parse the memory descriptions that BIOS provides by using the

ACPI/INT15 e820 interface mechanism. This information then can be used to determine how

MTRRs are initialized (for example: allowing the BIOS to define valid memory ranges and the

maximum memory range supported by the platform, including the processor).

See Section 12.11.4.1, “MTRR Precedences,” for information on overlapping variable MTRR ranges.

12.11.2.4 System-Management Range Register Interface

If IA32_MTRRCAP[bit 11] is set, the processor supports the SMRR interface to restrict access to a specified

memory address range used by system-management mode (SMM) software (see Section 32.4.2.1). If the SMRR

interface is supported, SMM software is strongly encouraged to use it to protect the SMI code and data stored by

SMI handler in the SMRAM region.

The system-management range registers consist of a pair of MSRs (see Figure 12-8). The IA32_SMRR_PHYSBASE

MSR defines the base address for the SMRAM memory range and the memory type used to access it in SMM. The

IA32_SMRR_PHYSMASK MSR contains a valid bit and a mask that determines the SMRAM address range protected

by the SMRR interface. These MSRs may be written only in SMM; an attempt to write them outside of SMM causes

a general-protection exception.¹

Figure 12-8 shows flags and fields in these registers. The functions of these flags and fields are the following:

1. For some processor models, these MSRs can be accessed by RDMSR and WRMSR only if the SMRR interface has been enabled using

a model-specific bit in the IA32_FEATURE_CONTROL MSR.

Vol. 3A

12-25

MEMORY CACHE CONTROL

• Type field, bits 0 through 7 - Specifies the memory type for the range (see Table 12-8 for the encoding of

this field).

• PhysBase field, bits 12 through 31 - Specifies the base address of the address range. The address must be

less than 4 GBytes and is automatically aligned on a 4-KByte boundary.

• PhysMask field, bits 12 through 31 - Specifies a mask that determines the range of the region being

mapped, according to the following relationships:

- Address_Within_Range AND PhysMask = PhysBase AND PhysMask

- This value is extended by 12 bits at the low end to form the mask value. For more information: see Section

12.11.3, “Example Base and Mask Calculations.”

• V (valid) flag, bit 11 - Enables the register pair when set; disables register pair when clear.

Before attempting to access these SMRR registers, software must test bit 11 in the IA32_MTRRCAP register. If

SMRR is not supported, reads from or writes to registers cause general-protection exceptions.

When the valid flag in the IA32_SMRR_PHYSMASK MSR is 1, accesses to the specified address range are treated as

follows:

• If the logical processor is in SMM, accesses uses the memory type in the IA32_SMRR_PHYSBASE MSR.

• If the logical processor is not in SMM, write accesses are ignored and read accesses return a fixed value for each

byte. The uncacheable memory type (UC) is used in this case.

The above items apply even if the address range specified overlaps with a range specified by the MTRRs.

IA32_SMRR_PHYSBASE Register

1211

Reserved

PhysBase

Type

PhysBase - Base address of range

Type - Memory type for range

IA32_SMRR_PHYSMASK Register

121110

Reserved

PhysMask

Reserved

PhysMask - Sets range mask

V - Valid

Reserved

Figure 12-8. IA32_SMRR_PHYSBASE and IA32_SMRR_PHYSMASK SMRR Pair

12.11.3 Example Base and Mask Calculations

The examples in this section apply to processors that support a maximum physical address size of 36 bits. The base

and mask values entered in variable-range MTRR pairs are 24-bit values that the processor extends to 36-bits.

For example, to enter a base address of 2 MBytes (200000H) in the IA32_MTRR_PHYSBASE3 register, the 12 least-

significant bits are truncated and the value 000200H is entered in the PhysBase field. The same operation must be

performed on mask values. For example, to map the address range from 200000H to 3FFFFFH (2 MBytes to 4

MBytes), a mask value of FFFE00000H is required. Again, the 12 least-significant bits of this mask value are trun-

cated, so that the value entered in the PhysMask field of IA32_MTRR_PHYSMASK3 is FFFE00H. This mask is chosen

so that when any address in the 200000H to 3FFFFFH range is AND’d with the mask value, it will return the same

value as when the base address is AND’d with the mask value (which is 200000H).

12-26

Vol. 3A

MEMORY CACHE CONTROL

To map the address range from 400000H to 7FFFFFH (4 MBytes to 8 MBytes), a base value of 000400H is entered

in the PhysBase field and a mask value of FFFC00H is entered in the PhysMask field.

Example 12-2. Setting-Up Memory for a System

Here is an example of setting up the MTRRs for an system. Assume that the system has the following characteris-

tics:

•

96 MBytes of system memory is mapped as write-back memory (WB) for highest system performance.

• A custom 4-MByte I/O card is mapped to uncached memory (UC) at a base address of 64 MBytes. This

restriction forces the 96 MBytes of system memory to be addressed from 0 to 64 MBytes and from 68 MBytes

to 100 MBytes, leaving a 4-MByte hole for the I/O card.

• An 8-MByte graphics card is mapped to write-combining memory (WC) beginning at address A0000000H.

• The BIOS area from 15 MBytes to 16 MBytes is mapped to UC memory.

The following settings for the MTRRs will yield the proper mapping of the physical address space for this system

configuration.

IA32_MTRR_PHYSBASE0 = 0000 0000 0000 0006H

IA32_MTRR_PHYSMASK0 = 0000 000F FC00 0800H

Caches 0-64 MByte as WB cache type.

IA32_MTRR_PHYSBASE1 = 0000 0000 0400 0006H

IA32_MTRR_PHYSMASK1 = 0000 000F FE00 0800H

Caches 64-96 MByte as WB cache type.

IA32_MTRR_PHYSBASE2 = 0000 0000 0600 0006H

IA32_MTRR_PHYSMASK2 = 0000 000F FFC0 0800H

Caches 96-100 MByte as WB cache type.

IA32_MTRR_PHYSBASE3 = 0000 0000 0400 0000H

IA32_MTRR_PHYSMASK3 = 0000 000F FFC0 0800H

Caches 64-68 MByte as UC cache type.

IA32_MTRR_PHYSBASE4 = 0000 0000 00F0 0000H

IA32_MTRR_PHYSMASK4 = 0000 000F FFF0 0800H

Caches 15-16 MByte as UC cache type.

IA32_MTRR_PHYSBASE5 = 0000 0000 A000 0001H

IA32_MTRR_PHYSMASK5 = 0000 000F FF80 0800H

Caches A0000000-A0800000 as WC type.

This MTRR setup uses the ability to overlap any two memory ranges (as long as the ranges are mapped to WB and

UC memory types) to minimize the number of MTRR registers that are required to configure the memory environ-

ment. This setup also fulfills the requirement that two register pairs are left for operating system usage.

12.11.3.1 Base and Mask Calculations for Greater-Than 36-bit Physical Address Support

For Intel 64 and IA-32 processors that support greater than 36 bits of physical address size, software should query

CPUID.80000008H to determine the maximum physical address. See the example.

Example 12-3. Setting-Up Memory for a System with a 40-Bit Address Size

If a processor supports 40-bits of physical address size, then the PhysMask field (in IA32_MTRR_PHYSMASKn

registers) is 28 bits instead of 24 bits. For this situation, Example 12-2 should be modified as follows:

IA32_MTRR_PHYSBASE0 = 0000 0000 0000 0006H

IA32_MTRR_PHYSMASK0 = 0000 00FF FC00 0800H

Caches 0-64 MByte as WB cache type.

Vol. 3A

12-27

MEMORY CACHE CONTROL

IA32_MTRR_PHYSBASE1 = 0000 0000 0400 0006H

IA32_MTRR_PHYSMASK1 = 0000 00FF FE00 0800H

Caches 64-96 MByte as WB cache type.

IA32_MTRR_PHYSBASE2 = 0000 0000 0600 0006H

IA32_MTRR_PHYSMASK2 = 0000 00FF FFC0 0800H

Caches 96-100 MByte as WB cache type.

IA32_MTRR_PHYSBASE3 = 0000 0000 0400 0000H

IA32_MTRR_PHYSMASK3 = 0000 00FF FFC0 0800H

Caches 64-68 MByte as UC cache type.

IA32_MTRR_PHYSBASE4 = 0000 0000 00F0 0000H

IA32_MTRR_PHYSMASK4 = 0000 00FF FFF0 0800H

Caches 15-16 MByte as UC cache type.

IA32_MTRR_PHYSBASE5 = 0000 0000 A000 0001H

IA32_MTRR_PHYSMASK5 = 0000 00FF FF80 0800H

Caches A0000000-A0800000 as WC type.

12.11.4 Range Size and Alignment Requirement

A range that is to be mapped to a variable-range MTRR must meet the following “power of 2” size and alignment

rules:

1. The minimum range size is 4 KBytes and the base address of the range must be on at least a 4-KByte

boundary.

2. For ranges greater than 4 KBytes, each range must be of length 2ⁿ and its base address must be aligned on a

2ⁿ boundary, where n is a value equal to or greater than 12. The base-address alignment value cannot be less

than its length. For example, an 8-KByte range cannot be aligned on a 4-KByte boundary. It must be aligned on

at least an 8-KByte boundary.

12.11.4.1 MTRR Precedences

If the MTRRs are not enabled (by setting the E flag in the IA32_MTRR_DEF_TYPE MSR), then all memory accesses

are of the UC memory type. If the MTRRs are enabled, then the memory type used for a memory access is deter-

mined as follows:

1. If the physical address falls within the first 1 MByte of physical memory and fixed MTRRs are enabled, the

processor uses the memory type stored for the appropriate fixed-range MTRR.

2. Otherwise, the processor attempts to match the physical address with a memory type set by the variable-range

MTRRs:

- If one variable memory range matches, the processor uses the memory type stored in the

IA32_MTRR_PHYSBASEn register for that range.

- If two or more variable memory ranges match and the memory types are identical, then that memory type

is used.

- If two or more variable memory ranges match and one of the memory types is UC, the UC memory type

used.

- If two or more variable memory ranges match and the memory types are WT and WB, the WT memory type

is used.

- For overlaps not defined by the above rules, processor behavior is undefined.

3. If no fixed or variable memory range matches, the processor uses the default memory type.

12-28

Vol. 3A

MEMORY CACHE CONTROL

12.11.5 MTRR Initialization

On a hardware reset, the P6 and more recent processors clear the valid flags in variable-range MTRRs and clear the

E flag in the IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the MTRRs are undefined.

Prior to initializing the MTRRs, software (normally the system BIOS) must initialize all fixed-range and variable-

range MTRR register fields to 0. Software can then initialize the MTRRs according to known types of memory,

including memory on devices that it auto-configures. Initialization is expected to occur prior to booting the oper-

ating system.

See Section 12.11.8, “MTRR Considerations in MP Systems,” for information on initializing MTRRs in MP (multiple-

processor) systems.

12.11.6 Remapping Memory Types

A system designer may re-map memory types to tune performance or because a future processor may not imple-

ment all memory types supported by the Pentium 4, Intel Xeon, and P6 family processors. The following rules

support coherent memory-type re-mappings:

1. A memory type should not be mapped into another memory type that has a weaker memory ordering model.

For example, the uncacheable type cannot be mapped into any other type, and the write-back, write-through,

and write-protected types cannot be mapped into the weakly ordered write-combining type.

2. A memory type that does not delay writes should not be mapped into a memory type that does delay writes,

because applications of such a memory type may rely on its write-through behavior. Accordingly, the write-

back type cannot be mapped into the write-through type.

3. A memory type that views write data as not necessarily stored and read back by a subsequent read, such as

the write-protected type, can only be mapped to another type with the same behavior (and there are no others

for the Pentium 4, Intel Xeon, and P6 family processors) or to the uncacheable type.

In many specific cases, a system designer can have additional information about how a memory type is used,

allowing additional mappings. For example, write-through memory with no associated write side effects can be

mapped into write-back memory.

12.11.7 MTRR Maintenance Programming Interface

The operating system maintains the MTRRs after booting and sets up or changes the memory types for memory-

mapped devices. The operating system should provide a driver and application programming interface (API) to

access and set the MTRRs. The function calls MemTypeGet() and MemTypeSet() define this interface.

12.11.7.1 MemTypeGet() Function

The MemTypeGet() function returns the memory type of the physical memory range specified by the parameters

base and size. The base address is the starting physical address and the size is the number of bytes for the memory

range. The function automatically aligns the base address and size to 4-KByte boundaries. Pseudocode for the

MemTypeGet() function is given in Example 12-4.

Vol. 3A

12-29

MEMORY CACHE CONTROL

Example 12-4. MemTypeGet() Pseudocode

#define MIXED_TYPES -1

/* 0 < MIXED_TYPES || MIXED_TYPES > 256 */

IF CPU_FEATURES.MTRR /* processor supports MTRRs */

THEN

Align BASE and SIZE to 4-KByte boundary;

IF (BASE + SIZE) wrap physical-address space

THEN return INVALID;

FI;

IF MTRRdefType.E = 0

THEN return UC;

FI;

FirstType := Get4KMemType (BASE);

/* Obtains memory type for first 4-KByte range. */

/* See Get4KMemType (4KByteRange) in Example 12-5. */

FOR each additional 4-KByte range specified in SIZE

NextType := Get4KMemType (4KByteRange);

IF NextType != FirstType

THEN return Mixed_Types;

FI;

ROF;

return FirstType;

ELSE return UNSUPPORTED;

FI;

If the processor does not support MTRRs, the function returns UNSUPPORTED. If the MTRRs are not enabled, then

the UC memory type is returned. If more than one memory type corresponds to the specified range, a status of

MIXED_TYPES is returned. Otherwise, the memory type defined for the range (UC, WC, WT, WB, or WP) is

returned.

The pseudocode for the Get4KMemType() function in Example 12-5 obtains the memory type for a single 4-KByte

range at a given physical address. The sample code determines whether an PHY_ADDRESS falls within a fixed

range by comparing the address with the known fixed ranges: 0 to 7FFFFH (64-KByte regions), 80000H to BFFFFH

(16-KByte regions), and C0000H to FFFFFH (4-KByte regions). If an address falls within one of these ranges, the

appropriate bits within one of its MTRRs determine the memory type.

Example 12-5. Get4KMemType() Pseudocode

IF IA32_MTRRCAP.FIX AND MTRRdefType.FE /* fixed registers enabled */

THEN IF PHY_ADDRESS is within a fixed range

return IA32_MTRR_FIX.Type;

FI;

FOR each variable-range MTRR in IA32_MTRRCAP.VCNT

IF IA32_MTRR_PHYSMASK.V = 0

THEN continue;

FI;

IF (PHY_ADDRESS AND IA32_MTRR_PHYSMASK.Mask) =

(IA32_MTRR_PHYSBASE.Base

AND IA32_MTRR_PHYSMASK.Mask)

THEN

return IA32_MTRR_PHYSBASE.Type;

FI;

ROF;

return MTRRdefType.Type;

12-30

Vol. 3A

MEMORY CACHE CONTROL

12.11.7.2 MemTypeSet() Function

The MemTypeSet() function in Example 12-6 sets a MTRR for the physical memory range specified by the parame-

ters base and size to the type specified by type. The base address and size are multiples of 4 KBytes and the size

is not 0.

Example 12-6. MemTypeSet Pseudocode

IF CPU_FEATURES.MTRR (* processor supports MTRRs *)

THEN

IF BASE and SIZE are not 4-KByte aligned or size is 0

THEN return INVALID;

FI;

IF (BASE + SIZE) wrap 4-GByte address space

THEN return INVALID;

FI;

IF TYPE is invalid for Pentium 4, Intel Xeon, and P6 family

processors

THEN return UNSUPPORTED;

FI;

IF TYPE is WC and not supported

THEN return UNSUPPORTED;

FI;

IF IA32_MTRRCAP.FIX is set AND range can be mapped using a

fixed-range MTRR

THEN

pre_mtrr_change();

update affected MTRR;

post_mtrr_change();

FI;

ELSE (* try to map using a variable MTRR pair *)

IF IA32_MTRRCAP.VCNT = 0

THEN return UNSUPPORTED;

FI;

IF conflicts with current variable ranges

THEN return RANGE_OVERLAP;

FI;

IF no MTRRs available

THEN return VAR_NOT_AVAILABLE;

FI;

IF BASE and SIZE do not meet the power of 2 requirements for

variable MTRRs

THEN return INVALID_VAR_REQUEST;

FI;

pre_mtrr_change();

Update affected MTRRs;

post_mtrr_change();

FI;

pre_mtrr_change()

BEGIN

disable interrupts;

Save current value of CR4;

disable and flush caches;

Vol. 3A

12-31

MEMORY CACHE CONTROL

flush TLBs;

disable MTRRs;

IF multiprocessing

THEN maintain consistency through IPIs;

FI;

END

post_mtrr_change()

BEGIN

flush caches and TLBs;

enable MTRRs;

enable caches;

restore value of CR4;

enable interrupts;

END

The physical address to variable range mapping algorithm in the MemTypeSet function detects conflicts with

current variable range registers by cycling through them and determining whether the physical address in question

matches any of the current ranges. During this scan, the algorithm can detect whether any current variable ranges

overlap and can be concatenated into a single range.

The pre_mtrr_change() function disables interrupts prior to changing the MTRRs, to avoid executing code with a

partially valid MTRR setup. The algorithm disables caching by setting the CD flag and clearing the NW flag in control

by clearing the page-global enable (PGE) flag in control register CR4 (if PGE was already set) or by updating control

IA32_MTRR_DEF_TYPE MSR.

After the memory type is updated, the post_mtrr_change() function re-enables the MTRRs and again invalidates

the caches and TLBs. This second invalidation is required because of the processor's aggressive prefetch of both

instructions and data. The algorithm restores interrupts and re-enables caching by setting the CD flag.

An operating system can batch multiple MTRR updates so that only a single pair of cache invalidations occur.

12.11.8 MTRR Considerations in MP Systems

In MP (multiple-processor) systems, the operating systems must maintain MTRR consistency between all the

processors in the system. The Pentium 4, Intel Xeon, and P6 family processors provide no hardware support to

maintain this consistency. In general, all processors must have the same MTRR values.

This requirement implies that when the operating system initializes an MP system, it must load the MTRRs of the

boot processor while the E flag in register MTRRdefType is 0. The operating system then directs other processors to

load their MTRRs with the same memory map. After all the processors have loaded their MTRRs, the operating

system signals them to enable their MTRRs. Barrier synchronization is used to prevent further memory accesses

until all processors indicate that the MTRRs are enabled. This synchronization is likely to be a shoot-down style

algorithm, with shared variables and interprocessor interrupts.

Any change to the value of the MTRRs in an MP system requires the operating system to repeat the loading and

enabling process to maintain consistency, using the following procedure:

1. Broadcast to all processors to execute the following code sequence.

2. Disable interrupts.

3. Wait for all processors to reach this point.

4. Enter the no-fill cache mode. (Set the CD flag in control register CR0 to 1 and the NW flag to 0.)

5. Flush all caches using the WBINVD instructions. On a processor that supports self-snooping (enumerating

CPUID.01H:EDX.SS[bit 27] as 1), this step may be unnecessary. However, if there are changes for which self-

snooping behavior would be problematic (e.g., changing the memory type of a cache line from WB to UC for

memory-mapped I/O), execution of WBINVD would still be required.

12-32

Vol. 3A

MEMORY CACHE CONTROL

6. If either the PGE or PCIDE flag is set in control register CR4, flush all TLBs by clearing one or both of these flags.

7. If the PGE and PCIDE flags are both clear in control register CR4, flush all TLBs by executing a MOV from control

8. Disable all range registers (by clearing the E flag in register MTRRdefType). If only variable ranges are being

modified, software may clear the valid bits for the affected register pairs instead.

9. Update the MTRRs.

10. Enable all range registers (by setting the E flag in register MTRRdefType). If only variable-range registers were

modified and their individual valid bits were cleared, then set the valid bits for the affected ranges instead.

11. Flush all caches and all TLBs a second time. (The TLB flush is required for Pentium 4, Intel Xeon, and P6 family

processors. Executing the WBINVD instruction is not needed when using Pentium 4, Intel Xeon, and P6 family

processors, but it may be needed in future systems.)

12. Enter the normal cache mode to re-enable caching. (Set the CD and NW flags in control register CR0 to 0.)

13. Restore the values of the PGE and/or PCIDE flags in control register CR4, if cleared in Step 6 (above).

14. Wait for all processors to reach this point.

15. Enable interrupts.

12.11.9 Large Page Size Considerations

The MTRRs provide memory typing for a limited number of regions that have a 4 KByte granularity (the same gran-

ularity as 4-KByte pages). The memory type for a given page is cached in the processor’s TLBs. When using large

pages (2 MBytes, 4 MBytes, or 1 GBytes), a single page-table entry covers multiple 4-KByte granules, each with a

single memory type. Because the memory type for a large page is cached in the TLB, the processor can behave in

an undefined manner if a large page is mapped to a region of memory that MTRRs have mapped with multiple

memory types.

Undefined behavior can be avoided by ensuring that all MTRR memory-type ranges within a large page are of the

same type. If a large page maps to a region of memory containing different MTRR-defined memory types, the PCD

and PWT flags in the page-table entry should be set for the most conservative memory type for that range. For

example, a large page used for memory mapped I/O and regular memory is mapped as UC memory. Alternatively,

the operating system can map the region using multiple 4-KByte pages each with its own memory type.

The requirement that all 4-KByte ranges in a large page are of the same memory type implies that large pages with

different memory types may suffer a performance penalty, since they must be marked with the lowest common

denominator memory type. The same consideration apply to 1 GByte pages, each of which may consist of multiple

2-Mbyte ranges.

The Pentium 4, Intel Xeon, and P6 family processors provide special support for the physical memory range from 0

to 4 MBytes, which is potentially mapped by both the fixed and variable MTRRs. This support is invoked when a

Pentium 4, Intel Xeon, or P6 family processor detects a large page overlapping the first 1 MByte of this memory

range with a memory type that conflicts with the fixed MTRRs. Here, the processor maps the memory range as

multiple 4-KByte pages within the TLB. This operation ensures correct behavior at the cost of performance. To

avoid this performance penalty, operating-system software should reserve the large page option for regions of

memory at addresses greater than or equal to 4 MBytes.

12.12 PAGE ATTRIBUTE TABLE (PAT)

The Page Attribute Table (PAT) extends the IA-32 architecture’s page-table format to allow memory types to be

assigned to regions of physical memory based on linear address mappings. The PAT is a companion feature to the

MTRRs; that is, the MTRRs allow mapping of memory types to regions of the physical address space, where the PAT

allows mapping of memory types to pages within the linear address space. The MTRRs are useful for statically

describing memory types for physical ranges, and are typically set up by the system BIOS. The PAT extends the

functions of the PCD and PWT bits in page tables to allow all five of the memory types that can be assigned with the

MTRRs (plus one additional memory type) to also be assigned dynamically to pages of the linear address space.

Vol. 3A

12-33

MEMORY CACHE CONTROL

The PAT was introduced to IA-32 architecture on the Pentium III processor. It is also available in the Pentium 4 and

Intel Xeon processors.

12.12.1 Detecting Support for the PAT Feature

An operating system or executive can detect the availability of the PAT by executing the CPUID instruction with a

value of 1 in the EAX register. Support for the PAT is indicated by the PAT flag (bit 16 of the values returned to EDX

When memory types have been assigned to entries in the PAT, software can then use of the PAT-index bit (PAT) in

the page-table and page-directory entries along with the PCD and PWT bits to assign memory types from the PAT

to individual pages.

Note that there is no separate flag or control bit in any of the control registers that enables the PAT. The PAT is

always enabled on all processors that support it, and the table lookup always occurs whenever paging is enabled,

in all paging modes.

12.12.2 IA32_PAT MSR

The IA32_PAT MSR is located at MSR address 277H (see Chapter 2, “Model-Specific Registers (MSRs)‚” in the

Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4). Figure 12-9. shows the format of the

64-bit IA32_PAT MSR.

The IA32_PAT MSR contains eight page attribute fields: PA0 through PA7. The three low-order bits of each field are

used to specify a memory type. The five high-order bits of each field are reserved, and must be set to all 0s. Each

of the eight page attribute fields can contain any of the memory type encodings specified in Table 12-10.

Reserved

PA3

Reserved

PA2

Reserved

PA1

Reserved

PA0

Reserved

PA7

Reserved

PA6

Reserved

PA5

Reserved

PA4

Figure 12-9. IA32_PAT MSR

Note that for the P6 family processors, the IA32_PAT MSR is named the PAT MSR.

Table 12-10. Memory Types That Can Be Encoded With PAT

Encoding

Mnemonic

00H

Uncacheable (UC)

01H

Write Combining (WC)

02H

Reserved*

03H

Reserved*

04H

Write Through (WT)

05H

Write Protected (WP)

06H

Write Back (WB)

07H

Uncached (UC-)

08H - FFH

Reserved*

NOTE:

* Using these encodings will result in a general-protection exception (#GP).

12-34

Vol. 3A

MEMORY CACHE CONTROL

12.12.3 Selecting a Memory Type from the PAT

To select a memory type for a page from the PAT, a 3-bit index made up of the PAT, PCD, and PWT bits must be

encoded in the page-table or page-directory entry for the page. Table 12-11 shows the possible encodings of the

PAT, PCD, and PWT bits and the PAT entry selected with each encoding. The PAT bit is bit 7 in page-table entries that

point to 4-KByte pages and bit 12 in paging-structure entries that point to larger pages. The PCD and PWT bits are

bits 4 and 3, respectively, in paging-structure entries that point to pages of any size.

The PAT entry selected for a page is used in conjunction with the MTRR setting for the region of physical memory

in which the page is mapped to determine the effective memory type for the page, as shown in Table 12-7.

Table 12-11. Selection of PAT Entries with PAT, PCD, and PWT Flags

PAT

PCD

PWT

PAT Entry

PAT0

PAT1

PAT2

PAT3

PAT4

PAT5

PAT6

PAT7

12.12.4 Programming the PAT

Table 12-12 shows the default setting for each PAT entry following a power up or reset of the processor. The setting

remain unchanged following a soft reset (INIT reset).

Table 12-12. Memory Type Setting of PAT Entries Following a Power-up or Reset

PAT Entry

Memory Type Following Power-up or Reset

PAT0

PAT1

PAT2

UC-

PAT3

PAT4

PAT5

PAT6

UC-

PAT7

The values in all the entries of the PAT can be changed by writing to the IA32_PAT MSR using the WRMSR instruc-

tion. The IA32_PAT MSR is read and write accessible (use of the RDMSR and WRMSR instructions, respectively) to

software operating at a CPL of 0. Table 12-10 shows the allowable encoding of the entries in the PAT. Attempting to

write an undefined memory type encoding into the PAT causes a general-protection (#GP) exception to be gener-

ated.

The operating system (OS) is responsible for ensuring that changes to a PAT entry occur in a manner that main-

tains the consistency of the processor caches and translation lookaside buffers (TLB). It requires the OS to invali-

date all affected TLB entries (including global entries) and all entries in all paging-structure caches. It may also

require flushing of the processor caches in certain situations. This can be accomplished in various ways, including

the sequence below or by following the procedure specified in Section 12.11.8, “MTRR Considerations in MP

Systems.” (See Section 4.10.4, “Invalidation of TLBs and Paging-Structure Caches” for additional backg0round

information.) Also note that in a multi-processor environment, it is the software's responsibility to resolve differ-

ences in conflicting memory types across logical processors that may arise from changes to the PAT (e.g., if two

Vol. 3A

12-35

MEMORY CACHE CONTROL

logical processors map a linear address to the same physical address but have PATs that specify a different memory

type for that physical address).

Example of a sequence to invalidate the processor TLBs and caches (if necessary):

1. If the PCIDE or PGE flag is set in CR4, flush TLBs by clearing one of those flags (then restore the flag via a

subsequent CR4 write).

Otherwise, flush TLBs by executing a MOV from control register CR3 to another register and then a MOV from

that register back to CR3.

2. In the case that there are changes to memory-type mappings for which cache self-snooping behavior would be

problematic given the existing mappings (e.g., changing a cache line's memory type from WB to UC to be used

for memory-mapped I/O), then cache flushing is also required. This can be done by executing CLFLUSH

operations for all affected cache lines or by executing the WBINVD instruction (recommended only if there are

a large number of affected mappings or if it is unknown which mappings are affected).

The PAT allows any memory type to be specified in the page tables, and therefore it is possible to have a single

physical page mapped to two or more different linear addresses, each with different memory types. Intel does not

support this practice because it may lead to undefined operations that can result in a system failure. In particular,

a WC page must never be aliased to a cacheable page because WC writes may not check the processor caches.

When remapping a page that was previously mapped as a cacheable memory type to a WC page, an operating

system can avoid this type of aliasing by doing the following:

1. Remove the previous mapping to a cacheable memory type in the page tables; that is, make them not

present.

2. Flush the TLBs of processors that may have used the mapping, even speculatively.

3. Create a new mapping to the same physical address with a new memory type, for instance, WC.

4. Flush the caches on all processors that may have used the mapping previously. Note on processors that support

self-snooping, CPUID feature flag bit 27, this step is unnecessary.

Operating systems that use a page directory as a page table (to map large pages) and enable page size extensions

must carefully scrutinize the use of the PAT index bit for the 4-KByte page-table entries. The PAT index bit for a

page-table entry (bit 7) corresponds to the page size bit in a page-directory entry. Therefore, the operating system

can only use PAT entries PA0 through PA3 when setting the caching type for a page table that is also used as a page

directory. If the operating system attempts to use PAT entries PA4 through PA7 when using this memory as a page

table, it effectively sets the PS bit for the access to this memory as a page directory.

For compatibility with earlier IA-32 processors that do not support the PAT, care should be taken in selecting the

encodings for entries in the PAT (see Section 12.12.5, “PAT Compatibility with Earlier IA-32 Processors”).

12.12.5 PAT Compatibility with Earlier IA-32 Processors

For IA-32 processors that support the PAT, the IA32_PAT MSR is always active. That is, the PCD and PWT bits in

page-table entries and in page-directory entries (that point to pages) are always select a memory type for a page

indirectly by selecting an entry in the PAT. They never select the memory type for a page directly as they do in

earlier IA-32 processors that do not implement the PAT (see Table 12-6).

To allow compatibility for code written to run on earlier IA-32 processor that do not support the PAT, the PAT mech-

anism has been designed to allow backward compatibility to earlier processors. This compatibility is provided

through the ordering of the PAT, PCD, and PWT bits in the 3-bit PAT entry index. For processors that do not imple-

ment the PAT, the PAT index bit (bit 7 in the page-table entries and bit 12 in the page-directory entries) is reserved

and set to 0. With the PAT bit reserved, only the first four entries of the PAT can be selected with the PCD and PWT

bits. At power-up or reset (see Table 12-12), these first four entries are encoded to select the same memory types

as the PCD and PWT bits would normally select directly in an IA-32 processor that does not implement the PAT. So,

if encodings of the first four entries in the PAT are left unchanged following a power-up or reset, code written to run

on earlier IA-32 processors that do not implement the PAT will run correctly on IA-32 processors that do implement

the PAT.

12-36

Vol. 3A

CHAPTER 16

MACHINE-CHECK ARCHITECTURE

This chapter describes the machine-check architecture and machine-check exception mechanism found in the

Pentium 4, Intel Xeon, Intel Atom, and P6 family processors. See Chapter 6, “Interrupt 18-Machine-Check Excep-

tion (#MC),” for more information on machine-check exceptions. A brief description of the Pentium processor’s

machine check capability is also given.

Additionally, a signaling mechanism for software to respond to hardware corrected machine check error is covered.

16.1

MACHINE-CHECK ARCHITECTURE

The Pentium 4, Intel Xeon, Intel Atom, and P6 family processors implement a machine-check architecture that

provides a mechanism for detecting and reporting hardware (machine) errors, such as: system bus errors, ECC

errors, parity errors, cache errors, and TLB errors. It consists of a set of model-specific registers (MSRs) that are

used to set up machine checking and additional banks of MSRs used for recording errors that are detected.

The processor signals the detection of an uncorrected machine-check error by generating a machine-check excep-

tion (#MC), which is an abort class exception. The implementation of the machine-check architecture does not

ordinarily permit the processor to be restarted reliably after generating a machine-check exception. However, the

machine-check-exception handler can collect information about the machine-check error from the machine-check

MSRs.

Starting with 45 nm Intel 64 processor on which CPUID reports DisplayFamily_DisplayModel as 06H_1AH; see the

CPUID instruction in Chapter 3, “Instruction Set Reference, A-L,” in the Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 2A. The processor can report information on corrected machine-check errors and

deliver a programmable interrupt for software to respond to MC errors, referred to as corrected machine-check

error interrupt (CMCI). See Section 16.5 for details.

Intel 64 processors supporting machine-check architecture and CMCI may also support an additional enhance-

ment, namely, support for software recovery from certain uncorrected recoverable machine check errors. See

Section 16.6 for details.

16.2

COMPATIBILITY WITH PENTIUM PROCESSOR

The Pentium 4, Intel Xeon, Intel Atom, and P6 family processors support and extend the machine-check exception

mechanism introduced in the Pentium processor. The Pentium processor reports the following machine-check

errors:

• Data parity errors during read cycles.

• Unsuccessful completion of a bus cycle.

The above errors are reported using the P5_MC_TYPE and P5_MC_ADDR MSRs (implementation specific for the

Pentium processor). Use the RDMSR instruction to read these MSRs. See Chapter 2, “Model-Specific Registers

(MSRs)‚” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4, for the addresses.

The machine-check error reporting mechanism that Pentium processors use is similar to that used in Pentium 4,

Intel Xeon, Intel Atom, and P6 family processors. When an error is detected, it is recorded in P5_MC_TYPE and

P5_MC_ADDR; the processor then generates a machine-check exception (#MC).

See Section 16.3.3, “Mapping of the Pentium Processor Machine-Check Errors to the Machine-Check Architecture,”

and Section 16.10.2, “Pentium Processor Machine-Check Exception Handling,” for information on compatibility

between machine-check code written to run on the Pentium processors and code written to run on P6 family

processors.

Vol. 3B

16-1

MACHINE-CHECK ARCHITECTURE

16.3

MACHINE-CHECK MSRS

Machine check MSRs in the Pentium 4, Intel Atom, Intel Xeon, and P6 family processors consist of a set of global

control and status registers and several error-reporting register banks. See Figure 16-1.

Error-Reporting Bank Registers

Global Control MSRs

(One Set for Each Hardware Unit)

IA32_MCG_CAP MSR

IA32_MCi_CTL MSR

IA32_MCG_STATUS MSR

IA32_MCi_STATUS MSR

IA32_MCG_CTL MSR

IA32_MCi_ADDR MSR

IA32_MCG_EXT_CTL MSR

IA32_MCi_MISC MSR

IA32_MCi_CTL2 MSR

Figure 16-1. Machine-Check MSRs

Each error-reporting bank is associated with a specific hardware unit (or group of hardware units) in the processor.

Use RDMSR and WRMSR to read and to write these registers.

16.3.1 Machine-Check Global Control MSRs

The machine-check global control MSRs include the IA32_MCG_CAP, IA32_MCG_STATUS, and optionally IA32_MC-

G_CTL and IA32_MCG_EXT_CTL. See Chapter 2, “Model-Specific Registers (MSRs),” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 4, for the addresses of these registers.

16.3.1.1 IA32_MCG_CAP MSR

The IA32_MCG_CAP MSR is a read-only register that provides information about the machine-check architecture of

the processor. Figure 16-2 shows the layout of the register.

16-2

Vol. 3B

MACHINE-CHECK ARCHITECTURE

27 26

2423

1615

12 11

Count

Reserved

MCG_LMCE_P[27]

MCG_ELOG_P[26]

MCG_EMC_P[25]

MCG_SER_P[24]

MCG_EXT_CNT[23:16]

MCG_TES_P[11]

MCG_CMCI_P[10]

MCG_EXT_P[9]

MCG_CTL_P[8]

Figure 16-2. IA32_MCG_CAP Register

Where:

•

Count field, bits 7:0 - Indicates the number of hardware unit error-reporting banks available in a particular

processor implementation.

•

MCG_CTL_P (control MSR present) flag, bit 8 - Indicates that the processor implements the IA32_MC-

G_CTL MSR when set; this register is absent when clear.

•

MCG_EXT_P (extended MSRs present) flag, bit 9 - Indicates that the processor implements the extended

machine-check state registers found starting at MSR address 180H; these registers are absent when clear.

•

MCG_CMCI_P (Corrected MC error counting/signaling extension present) flag, bit 10 - Indicates

(when set) that extended state and associated MSRs necessary to support the reporting of an interrupt on a

corrected MC error event and/or count threshold of corrected MC errors, is present. When this bit is set, it does

not imply this feature is supported across all banks. Software should check the availability of the necessary

logic on a bank by bank basis when using this signaling capability (i.e., bit 30 settable in individual IA32_M-

Ci_CTL2 register).

•

MCG_TES_P (threshold-based error status present) flag, bit 11 - Indicates (when set) that bits 56:53

of the IA32_MCi_STATUS MSR are part of the architectural space. Bits 56:55 are reserved, and bits 54:53 are

used to report threshold-based error status. Note that when MCG_TES_P is not set, bits 56:53 of the IA32_M-

Ci_STATUS MSR are model-specific.

•

MCG_EXT_CNT, bits 23:16 - Indicates the number of extended machine-check state registers present. This

field is meaningful only when the MCG_EXT_P flag is set.

•

MCG_SER_P (software error recovery support present) flag, bit 24 - Indicates (when set) that the

processor supports software error recovery (see Section 16.6), and IA32_MCi_STATUS MSR bits 56:55 are

used to report the signaling of uncorrected recoverable errors and whether software must take recovery

actions for uncorrected errors. Note that when MCG_TES_P is not set, bits 56:53 of the IA32_MCi_STATUS MSR

are model-specific. If MCG_TES_P is set but MCG_SER_P is not set, bits 56:55 are reserved.

•

MCG_EMC_P (Enhanced Machine Check Capability) flag, bit 25 - Indicates (when set) that the

processor supports enhanced machine check capabilities for firmware first signaling.

•

MCG_ELOG_P (extended error logging) flag, bit 26 - Indicates (when set) that the processor allows

platform firmware to be invoked when an error is detected so that it may provide additional platform specific

information in an ACPI format “Generic Error Data Entry” that augments the data included in machine check

bank registers.

For additional information about extended error logging interface, see

https://cdrdv2.intel.com/v1/dl/getContent/671064.

•

MCG_LMCE_P (local machine check exception) flag, bit 27 - Indicates (when set) that the following

interfaces are present:

Vol. 3B

16-3

MACHINE-CHECK ARCHITECTURE

- an extended state LMCE_S (located in bit 3 of IA32_MCG_STATUS), and

- the IA32_MCG_EXT_CTL MSR, necessary to support Local Machine Check Exception (LMCE).

A non-zero MCG_LMCE_P indicates that, when LMCE is enabled as described in Section 16.3.1.5, some machine

check errors may be delivered to only a single logical processor.

The effect of writing to the IA32_MCG_CAP MSR is undefined.

16.3.1.2 IA32_MCG_STATUS MSR

The IA32_MCG_STATUS MSR describes the current state of the processor after a machine-check exception has

occurred (see Figure 16-3).

Reserved

LMCE_S-Local machine check exception signaled

MCIP-Machine check in progress flag

EIPV-Error IP valid flag

RIPV-Restart IP valid flag

Figure 16-3. IA32_MCG_STATUS Register

Where:

• RIPV (restart IP valid) flag, bit 0 - Indicates (when set) that program execution can be restarted reliably

at the instruction pointed to by the instruction pointer pushed on the stack when the machine-check exception

is generated. When clear, the program cannot be reliably restarted at the pushed instruction pointer.

• EIPV (error IP valid) flag, bit 1 - Indicates (when set) that the instruction pointed to by the instruction

pointer pushed onto the stack when the machine-check exception is generated is directly associated with the

error. When this flag is cleared, the instruction pointed to may not be associated with the error.

• MCIP (machine check in progress) flag, bit 2 - Indicates (when set) that a machine-check exception was

generated. Software can set or clear this flag. The occurrence of a second Machine-Check Event while MCIP is

set will cause the processor to enter a shutdown state. For information on processor behavior in the shutdown

state, please refer to the description in Chapter 6, “Interrupt and Exception Handling”: “Interrupt 8-Double

Fault Exception (#DF)”.

• LMCE_S (local machine check exception signaled), bit 3 - Indicates (when set) that a local machine-

check exception was generated. This indicates that the current machine-check event was delivered to only this

logical processor.

Bits 63:04 in the IA32_MCG_STATUS MSR are reserved. An attempt to write to the IA32_MCG_STATUS MSR’s

reserved bits with any value other than 0 results in #GP.

16.3.1.3 IA32_MCG_CTL MSR

The IA32_MCG_CTL MSR is present if the capability flag MCG_CTL_P is set in the IA32_MCG_CAP MSR.

IA32_MCG_CTL controls the reporting of machine-check exceptions. If present, writing 1s to this register enables

machine-check features and writing all 0s disables machine-check features. All other values are undefined and/or

implementation specific.

16.3.1.4 IA32_MCG_EXT_CTL MSR

The IA32_MCG_EXT_CTL MSR is present if the capability flag MCG_LMCE_P is set in the IA32_MCG_CAP MSR.

16-4

Vol. 3B

MACHINE-CHECK ARCHITECTURE

IA32_MCG_EXT_CTL.LMCE_EN (bit 0) allows the processor to signal some MCEs to only a single logical processor

in the system.

If MCG_LMCE_P is not set in IA32_MCG_CAP, or platform software has not enabled LMCE by setting IA32_FEA-

TURE_CONTROL.LMCE_ENABLED (bit 20), any attempt to write or read IA32_MCG_EXT_CTL will result in #GP.

The IA32_MCG_EXT_CTL MSR is cleared on RESET.

Figure 16-4 shows the layout of the IA32_MCG_EXT_CTL register

Reserved

LMCE_EN - system software control to enable/disable LMCE

Figure 16-4. IA32_MCG_EXT_CTL Register

where

• LMCE_EN (local machine check exception enable) flag, bit 0 - System software sets this to allow

hardware to signal some MCEs to only a single logical processor. System software can set LMCE_EN only if the

platform software has configured IA32_FEATURE_CONTROL as described in Section 16.3.1.5.

16.3.1.5 Enabling Local Machine Check

The intended usage of LMCE requires proper configuration by both platform software and system software. Plat-

form software can turn LMCE on by setting bit 20 (LMCE_ENABLED) in IA32_FEATURE_CONTROL MSR (MSR

address 3AH).

System software must ensure that both IA32_FEATURE_CONTROL.Lock (bit 0)and IA32_FEATURE_CON-

TROL.LMCE_ENABLED (bit 20) are set before attempting to set IA32_MCG_EXT_CTL.LMCE_EN (bit 0). When

system software has enabled LMCE, then hardware will determine if a particular error can be delivered only to a

single logical processor. Software should make no assumptions about the type of error that hardware can choose

to deliver as LMCE. The severity and override rules stay the same as described in Table 16-8 to determine the

recovery actions.

16.3.2 Error-Reporting Register Banks

Each error-reporting register bank can contain the IA32_MCi_CTL, IA32_MCi_STATUS, IA32_MCi_ADDR, and

IA32_MCi_MISC MSRs. The number of reporting banks is indicated by bits [7:0] of IA32_MCG_CAP MSR (address

0179H). The first error-reporting register (IA32_MC0_CTL) always starts at address 400H.

See Chapter 2, “Model-Specific Registers (MSRs),” in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 4, for addresses of the error-reporting registers in the Pentium 4, Intel Atom, and Intel Xeon

processors; and for addresses of the error-reporting registers P6 family processors.

16.3.2.1 IA32_MCi_CTL MSRs

The IA32_MCi_CTL MSR controls signaling of #MC for errors produced by a particular hardware unit (or group of

hardware units). Each of the 64 flags (EEj) represents a potential error. Setting an EEj flag enables signaling #MC

of the associated error and clearing it disables signaling of the error. Error logging happens regardless of the setting

of these bits. The processor drops writes to bits that are not implemented. Figure 16-5 shows the bit fields of

IA32_MCi_CTL.

Vol. 3B

16-5

MACHINE-CHECK ARCHITECTURE

62 61

3 2

EEj-Error reporting enable flag

(where j is 00 through 63)

Figure 16-5. IA32_MCi_CTL Register

NOTE

For P6 family processors, processors based on Intel Core microarchitecture (excluding those on

which CPUID reports DisplayFamily_DisplayModel as 06H_1AH and onward): the operating system

or executive software must not modify the contents of the IA32_MC0_CTL MSR. This MSR is

internally aliased to the EBL_CR_POWERON MSR and controls platform-specific error handling

features. System specific firmware (the BIOS) is responsible for the appropriate initialization of the

IA32_MC0_CTL MSR. P6 family processors only allow the writing of all 1s or all 0s to the IA32_M-

Ci_CTL MSR.

16.3.2.2 IA32_MCi_STATUS MSRS

Each IA32_MCi_STATUS MSR contains information related to a machine-check error if its VAL (valid) flag is set (see

Figure 16-6). Software is responsible for clearing IA32_MCi_STATUS MSRs by explicitly writing 0s to them; writing

1s to them causes a general-protection exception.

NOTE

Figure 16-6 depicts the IA32_MCi_STATUS MSR when IA32_MCG_CAP[24] = 1, IA32_MC-

G_CAP[11] = 1 and IA32_MCG_CAP[10] = 1. When IA32_MCG_CAP[24] = 0 and IA32_MC-

G_CAP[11] = 1, bits 56:55 is reserved and bits 54:53 for threshold-based error reporting. When

IA32_MCG_CAP[11] = 0, bits 56:53 are part of the “Other Information” field. The use of bits 54:53

for threshold-based error reporting began with Intel Core Duo processors, and is currently used for

cache memory. See Section 16.4, “Enhanced Cache Error reporting,” for more information. When

IA32_MCG_CAP[10] = 0, bits 52:38 are part of the “Other Information” field. The use of bits 52:38

for corrected MC error count is introduced with Intel 64 processor on which CPUID reports Display-

Family_DisplayModel as 06H_1AH.

Where:

• MCA (machine-check architecture) error code field, bits 15:0 - Specifies the machine-check archi-

tecture-defined error code for the machine-check error condition detected. The machine-check architecture-

defined error codes are guaranteed to be the same for all IA-32 processors that implement the machine-check

architecture. See Section 16.9, “Interpreting the MCA Error Codes,” and Chapter 17, “Interpreting Machine

Check Error Codes‚” for information on machine-check error codes.

• Model-specific error code field, bits 31:16 - Specifies the model-specific error code that uniquely

identifies the machine-check error condition detected. The model-specific error codes may differ among IA-32

processors for the same machine-check error condition. See Chapter 17, “Interpreting Machine Check Error

Codes‚” for information on model-specific error codes.

• Reserved, Error Status, and Other Information fields, bits 56:32 -

• If IA32_MCG_CAP.MCG_EMC_P[bit 25] is 0, bits 37:32 contain “Other Information” that is implemen-

tation-specific and is not part of the machine-check architecture.

• If IA32_MCG_CAP.MCG_EMC_P is 1, “Other Information” is in bits 36:32. If bit 37 is 0, system firmware

has not changed the contents of IA32_MCi_STATUS. If bit 37 is 1, system firmware may have edited the

contents of IA32_MCi_STATUS.

• If IA32_MCG_CAP.MCG_CMCI_P[bit 10] is 0, bits 52:38 also contain “Other Information” (in the same

sense as bits 37:32).

16-6

Vol. 3B

MACHINE-CHECK ARCHITECTURE

6362616059585756555453 52

3837

32 31

1615

Corrected Error

Other

MSCOD Model

MCA Error Code

Count

Info

Specific Error Code

Firmware updated error status indicator (37)*

Threshold-based error status (54:53)**

AR - Recovery action required for UCR error (55)***

S - Signaling an uncorrected recoverable (UCR) error (56)***

PCC - Processor context corrupted (57)

ADDRV - MCi_ADDR register valid (58)

MISCV - MCi_MISC register valid (59)

EN - Error reporting enabled (60)

UC - Uncorrected error (61)

OVER - Error overflow (62)

VAL - MCi_STATUS register valid (63)

* When IA32_MCG_CAP[25] (MCG_EMC_P) is set, bit 37 is not part of “Other Information”.

** When IA32_MCG_CAP[11] (MCG_TES_P) is not set, these bits are model-specific

(part of “Other Information”).

*** When IA32_MCG_CAP[11] or IA32_MCG_CAP[24] are not set, these bits are reserved, or

model-specific (part of “Other Information”).

Figure 16-6. IA32_MCi_STATUS Register

•

If IA32_MCG_CAP[10] is 1, bits 52:38 are architectural (not model-specific). In this case, bits 52:38

reports the value of a 15 bit counter that increments each time a corrected error is observed by the MCA

recording bank. This count value will continue to increment until cleared by software. The most

significant bit, 52, is a sticky count overflow bit.

•

If IA32_MCG_CAP[11] is 0, bits 56:53 also contain “Other Information” (in the same sense).

•

If IA32_MCG_CAP[11] is 1, bits 56:53 are architectural (not model-specific). In this case, bits 56:53

have the following functionality:

•

If IA32_MCG_CAP[24] is 0, bits 56:55 are reserved.

•

If IA32_MCG_CAP[24] is 1, bits 56:55 are defined as follows:

•

S (Signaling) flag, bit 56 - Signals the reporting of UCR errors in this MC bank. See Section 16.6.2

for additional details.

•

AR (Action Required) flag, bit 55 - Indicates (when set) that MCA error code specific recovery

action must be performed by system software at the time this error was signaled. See Section

16.6.2 for additional details.

•

If the UC bit (Figure 16-6) is 1, bits 54:53 are undefined.

•

If the UC bit (Figure 16-6) is 0, bits 54:53 indicate the status of the hardware structure that

reported the threshold-based error. See Table 16-1.

Table 16-1. Bits 54:53 in IA32_MCi_STATUS MSRs when IA32_MCG_CAP[11] = 1 and UC = 0

Bits 54:53

Meaning

No tracking - No hardware status tracking is provided for the structure reporting this event.

Green - Status tracking is provided for the structure posting the event; the current status is green (below threshold).

For more information, see Section 16.4, “Enhanced Cache Error reporting.”

Yellow - Status tracking is provided for the structure posting the event; the current status is yellow (above threshold).

For more information, see Section 16.4, “Enhanced Cache Error reporting.”

Reserved

Vol. 3B

16-7

MACHINE-CHECK ARCHITECTURE

• PCC (processor context corrupt) flag, bit 57 - Indicates (when set) that the state of the processor might

have been corrupted by the error condition detected and that reliable restarting of the processor may not be

possible. When clear, this flag indicates that the error did not affect the processor’s state, and software may be

able to restart. When system software supports recovery, consult Section 16.10.4, “Machine-Check Software

Handler Guidelines for Error Recovery,” for additional rules that apply.

• ADDRV (IA32_MCi_ADDR register valid) flag, bit 58 - Indicates (when set) that the IA32_MCi_ADDR

clear, this flag indicates that the IA32_MCi_ADDR register is either not implemented or does not contain the

address where the error occurred. Do not read these registers if they are not implemented in the processor.

• MISCV (IA32_MCi_MISC register valid) flag, bit 59 - Indicates (when set) that the IA32_MCi_MISC

Ci_MISC register is either not implemented or does not contain additional information regarding the error. Do

not read these registers if they are not implemented in the processor.

• EN (error enabled) flag, bit 60 - Indicates (when set) that the error was enabled by the associated EEj bit

of the IA32_MCi_CTL register.

• UC (error uncorrected) flag, bit 61 - Indicates (when set) that the processor did not or was not able to

correct the error condition. When clear, this flag indicates that the processor was able to correct the error

condition.

• OVER (machine check overflow) flag, bit 62 - Indicates (when set) that a machine-check error occurred

while the results of a previous error were still in the error-reporting register bank (that is, the VAL bit was

already set in the IA32_MCi_STATUS register). The processor sets the OVER flag and software is responsible for

clearing it. In general, enabled errors are written over disabled errors, and uncorrected errors are written over

corrected errors. Uncorrected errors are not written over previous valid uncorrected errors. When

MCG_CMCI_P is set, corrected errors may not set the OVER flag. Software can rely on corrected error count in

IA32_MCi_Status[52:38] to determine if any additional corrected errors may have occurred. For more infor-

mation, see Section 16.3.2.2.1, “Overwrite Rules for Machine Check Overflow.”

• VAL (IA32_MCi_STATUS register valid) flag, bit 63 - Indicates (when set) that the information within the

IA32_MCi_STATUS register is valid. When this flag is set, the processor follows the rules given for the OVER flag

in the IA32_MCi_STATUS register when overwriting previously valid entries. The processor sets the VAL flag

and software is responsible for clearing it.

16.3.2.2.1 Overwrite Rules for Machine Check Overflow

Table 16-2 shows the overwrite rules for how to treat a second event if the MC bank already contains a valid log

from an earlier event - that is, what to do if the valid bit for an MC bank already is set to 1. When more than one

structure posts events in a given bank, these rules specify whether a new event will overwrite a previous posting or

not. These rules define a priority for uncorrected (highest priority), yellow, and green/unmonitored (lowest

priority) status.

In Table 16-2, the values in the two left-most columns are IA32_MCi_STATUS[54:53].

Table 16-2. Overwrite Rules for Enabled Errors

First Event

Second Event

UC bit

Color

MCA Info

00/green

either

00/green

yellow

second error

yellow

00/green

yellow

first error

yellow

either

00/green/yellow

undefined

second

00/green/yellow

undefined

first

If a second event overwrites a previously posted event, the information (as guarded by individual valid bits) in the

MCi bank is entirely from the second event. Similarly, if a first event is retained, all of the information previously

posted for that event is retained. In general, when the logged error or the recent error is a corrected error, the

OVER bit (MCi_Status[62]) may be set to indicate an overflow. When MCG_CMCI_P is set in IA32_MCG_CAP,

system software should consult IA32_MCi_STATUS[52:38] to determine if additional corrected errors may have

16-8

Vol. 3B

MACHINE-CHECK ARCHITECTURE

occurred. Software may re-read IA32_MCi_STATUS, IA32_MCi_ADDR, and IA32_MCi_MISC appropriately to

ensure data collected represent the last error logged.

After software polls a posting and clears the register, the valid bit is no longer set and therefore the meaning of the

rest of the bits, including the yellow/green/00 status field in bits 54:53, is undefined. The yellow/green indication

will only be posted for events associated with monitored structures - otherwise the unmonitored (00) code will be

posted in IA32_MCi_STATUS[54:53].

16.3.2.3 IA32_MCi_ADDR MSRs

The IA32_MCi_ADDR MSR contains the address of the code or data memory location that produced the machine-

check error if the ADDRV flag in the IA32_MCi_STATUS register is set (see Section 16-7, “IA32_MCi_ADDR MSR”).

The IA32_MCi_ADDR register is either not implemented or contains no address if the ADDRV flag in the IA32_M-

Ci_STATUS register is clear. When not implemented in the processor, all reads and writes to this MSR will cause a

general protection exception.

The address returned is an offset into a segment, linear address, or physical address. This depends on the error

encountered. When these registers are implemented, these registers can be cleared by explicitly writing 0s to

these registers. Writing 1s to these registers will cause a general-protection exception. See Figure 16-7.

Processor Without Support For Intel 64 Architecture

36 35

Reserved

Address

Processor With Support for Intel 64 Architecture

Address^*

* Useful bits in this field depend on the address methodology in use when the

the register state is saved.

Figure 16-7. IA32_MCi_ADDR MSR

16.3.2.4 IA32_MCi_MISC MSRs

The IA32_MCi_MISC MSR contains additional information describing the machine-check error if the MISCV flag in

the IA32_MCi_STATUS register is set. The IA32_MCi_MISC_MSR is either not implemented or does not contain

additional information if the MISCV flag in the IA32_MCi_STATUS register is clear.

When not implemented in the processor, all reads and writes to this MSR will cause a general protection exception.

When implemented in a processor, these registers can be cleared by explicitly writing all 0s to them; writing 1s to

them causes a general-protection exception to be generated. This register is not implemented in any of the error-

reporting register banks for the P6 or Intel Atom family processors.

If both MISCV and IA32_MCG_CAP[24] are set, the IA32_MCi_MISC_MSR is defined according to Figure 16-8 to

support software recovery of uncorrected errors (see Section 16.6).

Vol. 3B

16-9

MACHINE-CHECK ARCHITECTURE

Model Specific Information

Address Mode

Recoverable Address LSB

Figure 16-8. UCR Support in IA32_MCi_MISC Register

• Recoverable Address LSB (bits 5:0): The lowest valid recoverable address bit. Indicates the position of the least

significant bit (LSB) of the recoverable error address. For example, if the processor logs bits [43:9] of the

address, the LSB sub-field in IA32_MCi_MISC is 01001b (9 decimal). For this example, bits [8:0] of the

recoverable error address in IA32_MCi_ADDR should be ignored.

• Address Mode (bits 8:6): Address mode for the address logged in IA32_MCi_ADDR. The supported address

modes are given in Table 16-3.

Table 16-3. Address Mode in IA32_MCi_MISC[8:6]

IA32_MCi_MISC[8:6] Encoding

Definition

000

Segment Offset

001

Linear Address

010

Physical Address

011

Memory Address

100 to 110

Reserved

111

Generic

• Model Specific Information (bits 63:9): Not architecturally defined.

16.3.2.4.2 IOMCA

Logging and Signaling of errors from PCI Express domain is governed by PCI Express Advanced Error Reporting

(AER) architecture. PCI Express architecture divides errors in two categories: Uncorrectable errors and Correctable

errors. Uncorrectable errors can further be classified as Fatal or Non-Fatal. Uncorrected IO errors are signaled to

the system software either as AER Message Signaled Interrupt (MSI) or via platform specific mechanisms such as

NMI. Generally, the signaling mechanism is controlled by BIOS and/or platform firmware. Certain processors

support an error handling mode, called IOMCA mode, where Uncorrected PCI Express errors are signaled in the

form of machine check exception and logged in machine check banks.

When a processor is in this mode, Uncorrected PCI Express errors are logged in the MCACOD field of the IA32_M-

Ci_STATUS register as Generic I/O error. The corresponding MCA error code is defined in Table 15-8. IA32_M-

Ci_Status [15:0] Simple Error Code Encoding. Machine check logging complements and does not replace AER

logging that occurs inside the PCI Express hierarchy. The PCI Express Root Complex and Endpoints continue to log

the error in accordance with PCI Express AER mechanism. In IOMCA mode, MCi_MISC register in the bank that

logged IOMCA can optionally contain information that link the Machine Check logs with the AER logs or proprietary

logs. In such a scenario, the machine check handler can utilize the contents of MCi_MISC to locate the next level of

error logs corresponding to the same error. Specifically, if MCi_Status.MISCV is 1 and MCACOD is 0x0E0B, MCi_-

MISC contains the PCI Express address of the Root Complex device containing the AER Logs. Software can consult

the header type and class code registers in the Root Complex device's PCIe Configuration space to determine what

type of device it is. This Root Complex device can either be a PCI Express Root Port, PCI Express Root Complex

Event Collector or a proprietary device.

16-10

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Errors that originate from PCI Express or Legacy Endpoints are logged in the corresponding Root Port in addition to

the generating device. If MISCV=1 and MCi_MISC contains the address of the Root Port or a Root Complex Event

collector, software can parse the AER logs to learn more about the error.

If MISCV=1 and MCi_MISC points to a device that is neither a Root Complex Event Collector not a Root Port, soft-

ware must consult the Vendor ID/Device ID and use device specific knowledge to locate and interpret the error log

registers. In some cases, the Root Complex device configuration space may not be accessible to the software and

both the Vendor and Device ID read as 0xFFFF.

• The format of MCi_MISC for IOMCA errors is shown in Table 16-4.

Table 16-4. Address Mode in IA32_MCi_MISC[8:6]

63:40

39:32

31:16

15:9

8:6

5:0

RSVD

PCI Express Segment

PCI Express

RSVD

ADDR MODE¹

RECOV ADDR LSB¹

number

Requestor ID

NOTES:

1. Not Applicable if ADDRV=0.

Refer to PCI Express Specification 3.0 for definition of PCI Express Requestor ID and AER architecture. Refer to PCI

Firmware Specification 3.0 for an explanation of PCI Ex-press Segment number and how software can access

configuration space of a PCI Ex-press device given the segment number and Requestor ID.

16.3.2.5 IA32_MCi_CTL2 MSRs

The IA32_MCi_CTL2 MSR provides the programming interface to use corrected MC error signaling capability that is

indicated by IA32_MCG_CAP[10] = 1. Software must check for the presence of IA32_MCi_CTL2 on a per-bank

basis.

When IA32_MCG_CAP[10] = 1, the IA32_MCi_CTL2 MSR for each bank exists, i.e., reads and writes to these MSR

are supported. However, signaling interface for corrected MC errors may not be supported in all banks.

The layout of IA32_MCi_CTL2 is shown in Figure 16-9.

3130

Reserved

CMCI_EN-Enable/disable CMCI

Corrected error count threshold

Figure 16-9. IA32_MCi_CTL2 Register

• Corrected error count threshold, bits 14:0 - Software must initialize this field. The value is compared with

the corrected error count field in IA32_MCi_STATUS, bits 38 through 52. An overflow event is signaled to the

CMCI LVT entry (see Table 11-1) in the APIC when the count value equals the threshold value. The new LVT

entry in the APIC is at 02F0H offset from the APIC_BASE. If CMCI interface is not supported for a particular

bank (but IA32_MCG_CAP[10] = 1), this field will always read 0.

• CMCI_EN (Corrected error interrupt enable/disable/indicator), bits 30 - Software sets this bit to

enable the generation of corrected machine-check error interrupt (CMCI). If CMCI interface is not supported for

a particular bank (but IA32_MCG_CAP[10] = 1), this bit is writeable but will always return 0 for that bank. This

bit also indicates CMCI is supported or not supported in the corresponding bank. See Section 16.5 for details of

software detection of CMCI facility.

Vol. 3B

16-11

MACHINE-CHECK ARCHITECTURE

Some microarchitectural sub-systems that are the source of corrected MC errors may be shared by more than one

logical processors. Consequently, the facilities for reporting MC errors and controlling mechanisms may be shared

by more than one logical processors. For example, the IA32_MCi_CTL2 MSR is shared between logical processors

sharing a processor core. Software is responsible to program IA32_MCi_CTL2 MSR in a consistent manner with

CMCI delivery and usage.

After processor reset, IA32_MCi_CTL2 MSRs are zeroed.

16.3.2.6 IA32_MCG Extended Machine Check State MSRs

The Pentium 4 and Intel Xeon processors implement a variable number of extended machine-check state MSRs.

The MCG_EXT_P flag in the IA32_MCG_CAP MSR indicates the presence of these extended registers, and the

MCG_EXT_CNT field indicates the number of these registers actually implemented. See Section 16.3.1.1,

“IA32_MCG_CAP MSR.” Also see Table 16-5.

Table 16-5. Extended Machine Check State MSRs in Processors Without Support for Intel® 64 Architecture

MSR

Address

Description

IA32_MCG_EAX

180H

Contains state of the EAX register at the time of the machine-check error.

IA32_MCG_EBX

181H

Contains state of the EBX register at the time of the machine-check error.

IA32_MCG_ECX

182H

Contains state of the ECX register at the time of the machine-check error.

IA32_MCG_EDX

183H

Contains state of the EDX register at the time of the machine-check error.

IA32_MCG_ESI

184H

Contains state of the ESI register at the time of the machine-check error.

IA32_MCG_EDI

185H

Contains state of the EDI register at the time of the machine-check error.

IA32_MCG_EBP

186H

Contains state of the EBP register at the time of the machine-check error.

IA32_MCG_ESP

187H

Contains state of the ESP register at the time of the machine-check error.

IA32_MCG_EFLAGS

188H

Contains state of the EFLAGS register at the time of the machine-check error.

IA32_MCG_EIP

189H

Contains state of the EIP register at the time of the machine-check error.

IA32_MCG_MISC

18AH

When set, indicates that a page assist or page fault occurred during DS normal

operation.

In processors with support for Intel 64 architecture, 64-bit machine check state MSRs are aliased to the legacy

MSRs. In addition, there may be registers beyond IA32_MCG_MISC. These may include up to five reserved MSRs

(IA32_MCG_RESERVED[1:5]) and save-state MSRs for registers introduced in 64-bit mode. See Table 16-6.

Table 16-6. Extended Machine Check State MSRs In Processors With Support for Intel® 64 Architecture

MSR

Address

Description

IA32_MCG_RAX

180H

Contains state of the RAX register at the time of the machine-check error.

IA32_MCG_RBX

181H

Contains state of the RBX register at the time of the machine-check error.

IA32_MCG_RCX

182H

Contains state of the RCX register at the time of the machine-check error.

IA32_MCG_RDX

183H

Contains state of the RDX register at the time of the machine-check error.

IA32_MCG_RSI

184H

Contains state of the RSI register at the time of the machine-check error.

IA32_MCG_RDI

185H

Contains state of the RDI register at the time of the machine-check error.

IA32_MCG_RBP

186H

Contains state of the RBP register at the time of the machine-check error.

IA32_MCG_RSP

187H

Contains state of the RSP register at the time of the machine-check error.

IA32_MCG_RFLAGS

188H

Contains state of the RFLAGS register at the time of the machine-check error.

IA32_MCG_RIP

189H

Contains state of the RIP register at the time of the machine-check error.

IA32_MCG_MISC

18AH

When set, indicates that a page assist or page fault occurred during DS normal

operation.

16-12

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Table 16-6. Extended Machine Check State MSRs In Processors With Support for Intel® 64 Architecture (Contd.)

MSR

Address

Description

IA32_MCG_

18BH-

These registers, if present, are reserved.

RSERVED[1:5]

18FH

IA32_MCG_R8

190H

Contains state of the R8 register at the time of the machine-check error.

IA32_MCG_R9

191H

Contains state of the R9 register at the time of the machine-check error.

IA32_MCG_R10

192H

Contains state of the R10 register at the time of the machine-check error.

IA32_MCG_R11

193H

Contains state of the R11 register at the time of the machine-check error.

IA32_MCG_R12

194H

Contains state of the R12 register at the time of the machine-check error.

IA32_MCG_R13

195H

Contains state of the R13 register at the time of the machine-check error.

IA32_MCG_R14

196H

Contains state of the R14 register at the time of the machine-check error.

IA32_MCG_R15

197H

Contains state of the R15 register at the time of the machine-check error.

When a machine-check error is detected on a Pentium 4 or Intel Xeon processor, the processor saves the state of

the general-purpose registers, the R/EFLAGS register, and the R/EIP in these extended machine-check state MSRs.

This information can be used by a debugger to analyze the error.

These registers are read/write to zero registers. This means software can read them; but if software writes to

them, only all zeros is allowed. If software attempts to write a non-zero value into one of these registers, a general-

protection (#GP) exception is generated. These registers are cleared on a hardware reset (power-up or RESET),

but maintain their contents following a soft reset (INIT reset).

16.3.3 Mapping of the Pentium Processor Machine-Check Errors to the Machine-Check

Architecture

The Pentium processor reports machine-check errors using two registers: P5_MC_TYPE and P5_MC_ADDR. The

Pentium 4, Intel Xeon, Intel Atom, and P6 family processors map these registers to the IA32_MCi_STATUS and

IA32_MCi_ADDR in the error-reporting register bank. This bank reports on the same type of external bus errors

reported in P5_MC_TYPE and P5_MC_ADDR.

The information in these registers can then be accessed in two ways:

• By reading the IA32_MCi_STATUS and IA32_MCi_ADDR registers as part of a general machine-check exception

handler written for Pentium 4, Intel Atom and P6 family processors.

• By reading the P5_MC_TYPE and P5_MC_ADDR registers using the RDMSR instruction.

The second capability permits a machine-check exception handler written to run on a Pentium processor to be run

on a Pentium 4, Intel Xeon, Intel Atom, or P6 family processor. There is a limitation in that information returned by

the Pentium 4, Intel Xeon, Intel Atom, and P6 family processors is encoded differently than information returned

by the Pentium processor. To run a Pentium processor machine-check exception handler on a Pentium 4, Intel

Xeon, Intel Atom, or P6 family processor; the handler must be written to interpret P5_MC_TYPE encodings

correctly.

16.4

ENHANCED CACHE ERROR REPORTING

Starting with Intel Core Duo processors, cache error reporting was enhanced. In earlier Intel processors, cache

status was based on the number of correction events that occurred in a cache. In the new paradigm, called

“threshold-based error status”, cache status is based on the number of lines (ECC blocks) in a cache that incur

repeated corrections. The threshold is chosen by Intel, based on various factors. If a processor supports threshold-

based error status, it sets IA32_MCG_CAP[11] (MCG_TES_P) to 1; if not, to 0.

A processor that supports enhanced cache error reporting contains hardware that tracks the operating status of

certain caches and provides an indicator of their “health”. The hardware reports a “green” status when the number

of lines that incur repeated corrections is at or below a pre-defined threshold, and a “yellow” status when the

Vol. 3B

16-13

MACHINE-CHECK ARCHITECTURE

number of affected lines exceeds the threshold. Yellow status means that the cache reporting the event is operating

correctly, but you should schedule the system for servicing within a few weeks.

Intel recommends that you rely on this mechanism for structures supported by threshold-base error reporting.

The CPU/system/platform response to a yellow event should be less severe than its response to an uncorrected

error. An uncorrected error means that a serious error has actually occurred, whereas the yellow condition is a

warning that the number of affected lines has exceeded the threshold but is not, in itself, a serious event: the error

was corrected and system state was not compromised.

The green/yellow status indicator is not a foolproof early warning for an uncorrected error resulting from the failure

of two bits in the same ECC block. Such a failure can occur and cause an uncorrected error before the yellow

threshold is reached. However, the chance of an uncorrected error increases as the number of affected lines

increases.

16.5

CORRECTED MACHINE CHECK ERROR INTERRUPT

Corrected machine-check error interrupt (CMCI) is an architectural enhancement to the machine-check architec-

ture. It provides capabilities beyond those of threshold-based error reporting (Section 16.4). With threshold-based

error reporting, software is limited to use periodic polling to query the status of hardware corrected MC errors.

CMCI provides a signaling mechanism to deliver a local interrupt based on threshold values that software can

program using the IA32_MCi_CTL2 MSRs.

CMCI is disabled by default. System software is required to enable CMCI for each IA32_MCi bank that support the

reporting of hardware corrected errors if IA32_MCG_CAP[10] = 1.

System software use IA32_MCi_CTL2 MSR to enable/disable the CMCI capability for each bank and program

threshold values into IA32_MCi_CTL2 MSR. CMCI is not affected by the CR4.MCE bit, and it is not affected by the

IA32_MCi_CTL MSRs.

To detect the existence of thresholding for a given bank, software writes only bits 14:0 with the threshold value. If

the bits persist, then thresholding is available (and CMCI is available). If the bits are all 0's, then no thresholding

exists. To detect that CMCI signaling exists, software writes a 1 to bit 30 of the MCi_CTL2 register. Upon subsequent

read, if bit 30 = 0, no CMCI is available for this bank and no corrected or UCNA errors will be reported on this bank.

If bit 30 = 1, then CMCI is available and enabled.

16.5.1 CMCI Local APIC Interface

The operation of CMCI is depicted in Figure 16-10.

Software write 1 to enable

31 30

MCi_CTL2

Error threshold

Count overflow threshold -> CMCI LVT in local APIC

APIC_BASE + 2F0H

MCi_STATUS

Error count

Figure 16-10. CMCI Behavior

CMCI interrupt delivery is configured by writing to the LVT CMCI register entry in the local APIC register space at

default address of APIC_BASE + 2F0H. A CMCI interrupt can be delivered to more than one logical processors if

multiple logical processors are affected by the associated MC errors. For example, if a corrected bit error in a cache

shared by two logical processors caused a CMCI, the interrupt will be delivered to both logical processors sharing

16-14

Vol. 3B

MACHINE-CHECK ARCHITECTURE

that microarchitectural sub-system. Similarly, package level errors may cause CMCI to be delivered to all logical

processors within the package. However, system level errors will not be handled by CMCI.

See Section 11.5.1, “Local Vector Table,” for details regarding the LVT CMCI register.

16.5.2 System Software Recommendation for Managing CMCI and Machine Check Resources

System software must enable and manage CMCI, set up interrupt handlers to service CMCI interrupts delivered to

affected logical processors, program CMCI LVT entry, and query machine check banks that are shared by more

than one logical processors.

This section describes techniques system software can implement to manage CMCI initialization, service CMCI

interrupts in a efficient manner to minimize contentions to access shared MSR resources.

16.5.2.1 CMCI Initialization

Although a CMCI interrupt may be delivered to more than one logical processors depending on the nature of the

corrected MC error, only one instance of the interrupt service routine needs to perform the necessary service and

make queries to the machine-check banks. The following steps describes a technique that limits the amount of

work the system has to do in response to a CMCI.

•

To provide maximum flexibility, system software should define per-thread data structure for each logical

processor to allow equal-opportunity and efficient response to interrupt delivery. Specifically, the per-thread

data structure should include a set of per-bank fields to track which machine check bank it needs to access in

response to a delivered CMCI interrupt. The number of banks that needs to be tracked is determined by

IA32_MCG_CAP[7:0].

•

Initialization of per-thread data structure. The initialization of per-thread data structure must be done serially

on each logical processor in the system. The sequencing order to start the per-thread initialization between

different logical processor is arbitrary. But it must observe the following specific detail to satisfy the shared

nature of specific MSR resources:

a. Each thread initializes its data structure to indicate that it does not own any MC bank registers.

b. Each thread examines IA32_MCi_CTL2[30] indicator for each bank to determine if another thread has

already claimed ownership of that bank.

• If IA32_MCi_CTL2[30] had been set by another thread. This thread can not own bank i and should

proceed to step b. and examine the next machine check bank until all of the machine check banks are

exhausted.

• If IA32_MCi_CTL2[30] = 0, proceed to step c.

c. Check whether writing a 1 into IA32_MCi_CTL2[30] can return with 1 on a subsequent read to determine

this bank can support CMCI.

• If IA32_MCi_CTL2[30] = 0, this bank does not support CMCI. This thread can not own bank i and should

proceed to step b. and examine the next machine check bank until all of the machine check banks are

exhausted.

• If IA32_MCi_CTL2[30] = 1, modify the per-thread data structure to indicate this thread claims

ownership to the MC bank; proceed to initialize the error threshold count (bits 15:0) of that bank as

described in Chapter 16, “CMCI Threshold Management”. Then proceed to step b. and examine the next

machine check bank until all of the machine check banks are exhausted.

•

After the thread has examined all of the machine check banks, it sees if it owns any MC banks to service CMCI.

If any bank has been claimed by this thread:

- Ensure that the CMCI interrupt handler has been set up as described in Chapter 16, “CMCI Interrupt

Handler”.

- Initialize the CMCI LVT entry, as described in Section 16.5.1, “CMCI Local APIC Interface.”

- Log and clear all of IA32_MCi_Status registers for the banks that this thread owns. This will allow new

errors to be logged.

Vol. 3B

16-15

MACHINE-CHECK ARCHITECTURE

16.5.2.2 CMCI Threshold Management

The Corrected MC error threshold field, IA32_MCi_CTL2[14:0], is architecturally defined. Specifically, all these bits

are writable by software, but different processor implementations may choose to implement less than 15 bits as

threshold for the overflow comparison with IA32_MCi_STATUS[52:38]. The following describes techniques that

software can manage CMCI threshold to be compatible with changes in implementation characteristics:

• Software can set the initial threshold value to 1 by writing 1 to IA32_MCi_CTL2[14:0]. This will cause overflow

condition on every corrected MC error and generates a CMCI interrupt.

• To increase the threshold and reduce the frequency of CMCI servicing:

a. Find the maximum threshold value a given processor implementation supports. The steps are:

• Write 7FFFH to IA32_MCi_CTL2[14:0],

• Read back IA32_MCi_CTL2[14:0]; these 15 bits (14:0) contain the maximum threshold supported by

the processor.

b. Increase the threshold to a value below the maximum value discovered using step a.

16.5.2.3 CMCI Interrupt Handler

The following describes techniques system software may consider to implement a CMCI service routine:

• The service routine examines its private per-thread data structure to check which set of MC banks it has

ownership. If the thread does not have ownership of a given MC bank, proceed to the next MC bank. Ownership

is determined at initialization time which is described in Section 16.5.2.1.

If the thread had claimed ownership to an MC bank, this technique will allow each logical processors to handle

corrected MC errors independently and requires no synchronization to access shared MSR resources. Consult

Example 16-5 for guidelines on logging when processing CMCI.

16.6

RECOVERY OF UNCORRECTED RECOVERABLE (UCR) ERRORS

Recovery of uncorrected recoverable machine check errors is an enhancement in machine-check architecture. The

first processor that supports this feature is 45 nm Intel 64 processor on which CPUID reports DisplayFamily_Dis-

playModel as 06H_2EH; see the CPUID instruction in Chapter 3, “Instruction Set Reference, A-L‚” in the Intel^® 64

and IA-32 Architectures Software Developer’s Manual, Volume 2A. This allows system software to perform recovery

action on a certain class of uncorrected errors and continue execution.

16.6.1 Detection of Software Error Recovery Support

Software must use bit 24 of IA32_MCG_CAP (MCG_SER_P) to detect the presence of software error recovery

support (see Figure 16-2). When IA32_MCG_CAP[24] is set, this indicates that the processor supports software

error recovery. When this bit is clear, this indicates that there is no support for error recovery from the processor

and the primary responsibility of the machine check handler is logging the machine check error information and

shutting down the system.

The new class of architectural MCA errors from which system software can attempt recovery is called Uncorrected

Recoverable (UCR) Errors. UCR errors are uncorrected errors that have been detected and signaled but have not

corrupted the processor context. For certain UCR errors, this means that once system software has performed a

certain recovery action, it is possible to continue execution on this processor. UCR error reporting provides an error

containment mechanism for data poisoning. The machine check handler will use the error log information from the

error reporting registers to analyze and implement specific error recovery actions for UCR errors.

16.6.2 UCR Error Reporting and Logging

IA32_MCi_STATUS MSR is used for reporting UCR errors and existing corrected or uncorrected errors. The defini-

tions of IA32_MCi_STATUS, including bit fields to identify UCR errors, is shown in Figure 16-6. UCR errors can be

16-16

Vol. 3B

MACHINE-CHECK ARCHITECTURE

signaled through either the corrected machine check interrupt (CMCI) or machine check exception (MCE) path

depending on the type of the UCR error.

When IA32_MCG_CAP[24] is set, a UCR error is indicated by the following bit settings in the IA32_MCi_STATUS

• Valid (bit 63) = 1

• UC (bit 61) = 1

• PCC (bit 57) = 0

Additional information from the IA32_MCi_MISC and the IA32_MCi_ADDR registers for the UCR error are available

when the ADDRV and the MISCV flags in the IA32_MCi_STATUS register are set (see Section 16.3.2.4). The MCA

error code field of the IA32_MCi_STATUS register indicates the type of UCR error. System software can interpret

the MCA error code field to analyze and identify the necessary recovery action for the given UCR error.

In addition, the IA32_MCi_STATUS register bit fields, bits 56:55, are defined (see Figure 16-6) to provide addi-

tional information to help system software to properly identify the necessary recovery action for the UCR error:

• S (Signaling) flag, bit 56 - Indicates (when set) that a machine check exception was generated for the UCR

error reported in this MC bank and system software needs to check the AR flag and the MCA error code fields in

the IA32_MCi_STATUS register to identify the necessary recovery action for this error. When the S flag in the

IA32_MCi_STATUS register is clear, this UCR error was not signaled via a machine check exception and instead

was reported as a corrected machine check (CMC). System software is not required to take any recovery action

when the S flag in the IA32_MCi_STATUS register is clear.

• AR (Action Required) flag, bit 55 - Indicates (when set) that MCA error code specific recovery action must be

performed by system software at the time this error was signaled. This recovery action must be completed

successfully before any additional work is scheduled for this processor. When the RIPV flag in the IA32_MC-

G_STATUS is clear, an alternative execution stream needs to be provided; when the MCA error code specific

recovery specific recovery action cannot be successfully completed, system software must shut down the

system. When the AR flag in the IA32_MCi_STATUS register is clear, system software may still take MCA error

code specific recovery action but this is optional; system software can safely resume program execution at the

instruction pointer saved on the stack from the machine check exception when the RIPV flag in the IA32_MC-

G_STATUS register is set.

Both the S and the AR flags in the IA32_MCi_STATUS register are defined to be sticky bits, which mean that once

set, the processor does not clear them. Only software and good power-on reset can clear the S and the AR-flags.

Both the S and the AR flags are only set when the processor reports the UCR errors (MCG_CAP[24] is set).

16.6.3 UCR Error Classification

With the S and AR flag encoding in the IA32_MCi_STATUS register, UCR errors can be classified as:

• Uncorrected no action required (UCNA) - is a UCR error that is not signaled via a machine check exception and,

instead, is reported to system software as a corrected machine check error. UCNA errors indicate that some

data in the system is corrupted, but the data has not been consumed and the processor state is valid and you

may continue execution on this processor. UCNA errors require no action from system software to continue

execution. A UCNA error is indicated with UC=1, PCC=0, S=0 and AR=0 in the IA32_MCi_STATUS register.

• Software recoverable action optional (SRAO) - a UCR error is signaled either via a machine check exception or

CMCI. System software recovery action is optional and not required to continue execution from this machine

check exception. SRAO errors indicate that some data in the system is corrupt, but the data has not been

consumed and the processor state is valid. SRAO errors provide the additional error information for system

software to perform a recovery action. An SRAO error when signaled as a machine check is indicated with

UC=1, PCC=0, S=1, EN=1 and AR=0 in the IA32_MCi_STATUS register. In cases when SRAO is signaled via

CMCI the error signature is indicated via UC=1, PCC=0, S=0. Recovery actions for SRAO errors are MCA error

code specific. The MISCV and the ADDRV flags in the IA32_MCi_STATUS register are set when the additional

error information is available from the IA32_MCi_MISC and the IA32_MCi_ADDR registers. System software

needs to inspect the MCA error code fields in the IA32_MCi_STATUS register to identify the specific recovery

action for a given SRAO error. If MISCV and ADDRV are not set, it is recommended that no system software

error recovery be performed however, system software can resume execution.

• Software recoverable action required (SRAR) - a UCR error that requires system software to take a recovery

action on this processor before scheduling another stream of execution on this processor. SRAR errors indicate

Vol. 3B

16-17

MACHINE-CHECK ARCHITECTURE

that the error was detected and raised at the point of the consumption in the execution flow. An SRAR error is

indicated with UC=1, PCC=0, S=1, EN=1 and AR=1 in the IA32_MCi_STATUS register. Recovery actions are

MCA error code specific. The MISCV and the ADDRV flags in the IA32_MCi_STATUS register are set when the

additional error information is available from the IA32_MCi_MISC and the IA32_MCi_ADDR registers. System

software needs to inspect the MCA error code fields in the IA32_MCi_STATUS register to identify the specific

recovery action for a given SRAR error. If MISCV and ADDRV are not set, it is recommended that system

software shutdown the system.

Table 16-7 summarizes UCR, corrected, and uncorrected errors.

Table 16-7. MC Error Classifications

Type of Error¹

PCC

Signaling

Software Action

Example

Uncorrected Error (UC)

MCE

If EN=1, reset the system, else log

and OK to keep the system running.

SRAR

MCE

For known MCACOD, take specific

Cache to processor load

recovery action;

error.

For unknown MCACOD, must

bugcheck.

If OVER=1, reset system, else take

specific recovery action.

SRAO

x²

MCE/CMC

For known MCACOD, take specific

Patrol scrub and explicit

recovery action;

writeback poison errors.

For unknown MCACOD, OK to keep

the system running.

UCNA

CMC

Log the error and Ok to keep the

Poison detection error.

system running.

Corrected Error (CE)

CMC

Log the error and no corrective

ECC in caches and

action required.

memory.

NOTES:

1. SRAR, SRAO and UCNA errors are supported by the processor only when IA32_MCG_CAP[24] (MCG_SER_P) is set.

2. EN=1, S=1 when signaled via MCE. EN=x, S=0 when signaled via CMC.

16.6.4 UCR Error Overwrite Rules

In general, the overwrite rules are as follows:

• UCR errors will overwrite corrected errors.

• Uncorrected (PCC=1) errors overwrite UCR (PCC=0) errors.

• UCR errors are not written over previous UCR errors.

• Corrected errors do not write over previous UCR errors.

Regardless of whether the 1st error is retained or the 2nd error is overwritten over the 1st error, the OVER flag in

the IA32_MCi_STATUS register will be set to indicate an overflow condition. As the S flag and AR flag in the

IA32_MCi_STATUS register are defined to be sticky flags, a second event cannot clear these 2 flags once set,

however the MC bank information may be filled in for the 2nd error. The table below shows the overwrite rules and

how to treat a second error if the first event is already logged in a MC bank along with the resulting bit setting of

the UC, PCC, and AR flags in the IA32_MCi_STATUS register. As UCNA and SRA0 errors do not require recovery

action from system software to continue program execution, a system reset by system software is not required

unless the AR flag or PCC flag is set for the UCR overflow case (OVER=1, VAL=1, UC=1, PCC=0).

Table 16-8 lists overwrite rules for uncorrected errors, corrected errors, and uncorrected recoverable errors.

Table 16-8. Overwrite Rules for UC, CE, and UCR Errors

First Event

Second Event

PCC

MCA Bank

Reset System

UCR

0 if UCNA, else 1

1 if SRAR, else 0

second

yes, if AR=1

UCR

0 if UCNA, else 1

1 if SRAR, else 0

first

yes, if AR=1

16-18

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Table 16-8. Overwrite Rules for UC, CE, and UCR Errors

First Event

Second Event

PCC

MCA Bank

Reset System

UCNA

first

UCNA

SRAO

first

UCNA

SRAR

first

yes

SRAO

UCNA

first

SRAO

first

SRAO

SRAR

first

yes

SRAR

UCNA

first

yes

SRAR

SRAO

first

yes

SRAR

first

yes

UCR

undefined

second

yes

UCR

undefined

first

yes

16.7

MACHINE-CHECK AVAILABILITY

The machine-check architecture and machine-check exception (#MC) are model-specific features. Software can

execute the CPUID instruction to determine whether a processor implements these features. Following the execu-

tion of the CPUID instruction, the settings of the MCA flag (bit 14) and MCE flag (bit 7) in EDX indicate whether the

processor implements the machine-check architecture and machine-check exception.

16.8

MACHINE-CHECK INITIALIZATION

To use the processors machine-check architecture, software must initialize the processor to activate the machine-

check exception and the error-reporting mechanism.

Example 16-1 gives pseudocode for performing this initialization. This pseudocode checks for the existence of the

machine-check architecture and exception; it then enables machine-check exception and the error-reporting

Pentium processors.

Following power up or power cycling, IA32_MCi_STATUS registers are not guaranteed to have valid data until after

they are initially cleared to zero by software (as shown in the initialization pseudocode in Example 16-1).

Example 16-1. Machine-Check Initialization Pseudocode

Check CPUID Feature Flags for MCE and MCA support

IF CPU supports MCE

THEN

IF CPU supports MCA

THEN

IF (IA32_MCG_CAP.MCG_CTL_P = 1)

(* IA32_MCG_CTL register is present *)

THEN

IA32_MCG_CTL ← FFFFFFFFFFFFFFFFH;

(* enables all MCA features *)

IF (IA32_MCG_CAP.MCG_LMCE_P = 1 and IA32_FEATURE_CONTROL.LOCK = 1 and IA32_FEATURE_CONTROL.LMCE_ENABLED = 1)

(* IA32_MCG_EXT_CTL register is present and platform has enabled LMCE to permit system software to use LMCE *)

THEN

IA32_MCG_EXT_CTL ← IA32_MCG_EXT_CTL | 01H;

(* System software enables LMCE capability for hardware to signal MCE to a single logical processor*)

Vol. 3B

16-19

MACHINE-CHECK ARCHITECTURE

(* Determine number of error-reporting banks supported *)

COUNT← IA32_MCG_CAP.Count;

MAX_BANK_NUMBER ← COUNT - 1;

IF (Processor Family is 6H and Processor EXTMODEL:MODEL is less than 1AH)

THEN

(* Enable logging of all errors except for MC0_CTL register *)

FOR error-reporting banks (1 through MAX_BANK_NUMBER)

IA32_MCi_CTL ← 0FFFFFFFFFFFFFFFFH;

ELSE

(* Enable logging of all errors including MC0_CTL register *)

FOR error-reporting banks (0 through MAX_BANK_NUMBER)

IA32_MCi_CTL ← 0FFFFFFFFFFFFFFFFH;

(* BIOS clears all errors only on power-on reset *)

IF (BIOS detects Power-on reset)

THEN

FOR error-reporting banks (0 through MAX_BANK_NUMBER)

IA32_MCi_STATUS ← 0;

ELSE

FOR error-reporting banks (0 through MAX_BANK_NUMBER)

(Optional for BIOS and OS) Log valid errors

(OS only) IA32_MCi_STATUS ← 0;

Setup the Machine Check Exception (#MC) handler for vector 18 in IDT

Set the MCE bit (bit 6) in CR4 register to enable Machine-Check Exceptions

16.9

INTERPRETING THE MCA ERROR CODES

When the processor detects a machine-check error condition, it writes a 16-bit error code to the MCA error code

field of one of the IA32_MCi_STATUS registers and sets the VAL (valid) flag in that register. The processor may also

write a 16-bit model-specific error code in the IA32_MCi_STATUS register depending on the implementation of the

machine-check architecture of the processor.

The MCA error codes are architecturally defined for Intel 64 and IA-32 processors. To determine the cause of a

machine-check exception, the machine-check exception handler must read the VAL flag for each IA32_M-

Ci_STATUS register. If the flag is set, the machine check-exception handler must then read the MCA error code field

of the register. It is the encoding of the MCA error code field [15:0] that determines the type of error being reported

and not the register bank reporting it.

There are two types of MCA error codes: simple error codes and compound error codes.

16.9.1 Simple Error Codes

Table 16-9 shows the simple error codes. These unique codes indicate global error information.

16-20

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Table 16-9. IA32_MCi_Status [15:0] Simple Error Code Encoding

Error Code

Binary Encoding

Meaning

No Error

0000 0000 0000 0000

No error has been reported to this bank of error-reporting

registers.

Unclassified

0000 0000 0000 0001

This error has not been classified into the MCA error classes.

Microcode ROM Parity Error

0000 0000 0000 0010

Parity error in internal microcode ROM

External Error

0000 0000 0000 0011

The BINIT# from another processor caused this processor to

enter machine check.¹

FRC Error

0000 0000 0000 0100

FRC (functional redundancy check) main/secondary error.

Internal Parity Error

0000 0000 0000 0101

Internal parity error.

SMM Handler Code Access

0000 0000 0000 0110

An attempt was made by the SMM Handler to execute

Violation

outside the ranges specified by SMRR.

Internal Timer Error

0000 0100 0000 0000

Internal timer error.

I/O Error

0000 1110 0000 1011

generic I/O error.

Internal Unclassified

0000 01xx xxxx xxxx

Internal unclassified errors. ²

NOTES:

1. BINIT# assertion will cause a machine check exception if the processor (or any processor on the same external bus) has BINIT#

observation enabled during power-on configuration (hardware strapping) and if machine check exceptions are enabled (by setting

CR4.MCE = 1).

2. At least one X must equal one. Internal unclassified errors have not been classified.

16.9.2 Compound Error Codes

Compound error codes describe errors related to the TLBs, memory, caches, bus and interconnect logic, and

internal timer. A set of sub-fields is common to all of compound errors. These sub-fields describe the type of

access, level in the cache hierarchy, and type of request. Table 16-10 shows the general form of the compound

error codes.

Table 16-10. IA32_MCi_Status [15:0] Compound Error Code Encoding

Type

Form

Interpretation

Generic Cache Hierarchy

000F 0000 0000 11LL

Generic cache hierarchy error

TLB Errors

000F 0000 0001 TTLL

{TT}TLB{LL}_ERR

Memory Controller Errors

000F 0000 1MMM CCCC

{MMM}_CHANNEL{CCCC}_ERR

Cache Hierarchy Errors

000F 0001 RRRR TTLL

{TT}CACHE{LL}_{RRRR}_ERR

Extended Memory Errors

000F 0010 1MMM CCCC

{MMM}_CHANNEL{CCCC}_ERR

Bus and Interconnect Errors

000F 1PPT RRRR IILL

BUS{LL}_{PP}_{RRRR}_{II}_{T}_ERR

The “Interpretation” column in the table indicates the name of a compound error. The name is constructed by

substituting mnemonics for the sub-field names given within curly braces. For example, the error code

ICACHEL1_RD_ERR is constructed from the form:

{TT}CACHE{LL}_{RRRR}_ERR,

where {TT} is replaced by I, {LL} is replaced by L1, and {RRRR} is replaced by RD.

For more information on the “Form” and “Interpretation” columns, see Section 16.9.2.1, “Correction Report

Filtering (F) Bit,” through Section 16.9.2.5, “Bus and Interconnect Errors.”

16.9.2.1 Correction Report Filtering (F) Bit

Starting with Intel Core Duo processors, bit 12 in the “Form” column in Table 16-10 is used to indicate that a partic-

ular posting to a log may be the last posting for corrections in that line/entry, at least for some time:

Vol. 3B

16-21

MACHINE-CHECK ARCHITECTURE

•

0 in bit 12 indicates “normal” filtering (original P6/Pentium4/Atom/Xeon processor meaning).

•

1 in bit 12 indicates “corrected” filtering (filtering is activated for the line/entry in the posting). Filtering means

that some or all of the subsequent corrections to this entry (in this structure) will not be posted. The enhanced

error reporting introduced with the Intel Core Duo processors is based on tracking the lines affected by

repeated corrections (see Section 16.4, “Enhanced Cache Error reporting”). This capability is indicated by

IA32_MCG_CAP[11]. Only the first few correction events for a line are posted; subsequent redundant

correction events to the same line are not posted. Uncorrected events are always posted.

The behavior of error filtering after crossing the yellow threshold is model-specific. Filtering has meaning only for

corrected errors (UC=0 in IA32_MCi_STATUS MSR). System software must ignore filtering bit (12) for uncorrected

errors.

16.9.2.2 Transaction Type (TT) Sub-Field

The 2-bit TT sub-field (Table 16-11) indicates the type of transaction (data, instruction, or generic). The sub-field

applies to the TLB, cache, and interconnect error conditions. Note that interconnect error conditions are primarily

associated with P6 family and Pentium processors, which utilize an external APIC bus separate from the system

bus. The generic type is reported when the processor cannot determine the transaction type.

Table 16-11. Encoding for TT (Transaction Type) Sub-Field

Transaction Type

Mnemonic

Binary Encoding

Instruction

Data

Generic

16.9.2.3 Level (LL) Sub-Field

The 2-bit LL sub-field (see Table 16-12) indicates the level in the memory hierarchy where the error occurred (level

0, level 1, level 2, or generic). The LL sub-field also applies to the TLB, cache, and interconnect error conditions.

The Pentium 4, Intel Xeon, Intel Atom, and P6 family processors support two levels in the cache hierarchy and one

level in the TLBs. Again, the generic type is reported when the processor cannot determine the hierarchy level.

Table 16-12. Level Encoding for LL (Memory Hierarchy Level) Sub-Field

Hierarchy Level

Mnemonic

Binary Encoding

Level 0

Level 1

Level 2

Generic

16.9.2.4 Request (RRRR) Sub-Field

The 4-bit RRRR sub-field (see Table 16-13) indicates the type of action associated with the error. Actions include

read and write operations, prefetches, cache evictions, and snoops. Generic error is returned when the type of

error cannot be determined. Generic read and generic write are returned when the processor cannot determine the

type of instruction or data request that caused the error. Eviction and snoop requests apply only to the caches. All

of the other requests apply to TLBs, caches, and interconnects.

16-22

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Table 16-13. Encoding of Request (RRRR) Sub-Field

Request Type

Mnemonic

Binary Encoding

Generic Error

ERR

0000

Generic Read

0001

Generic Write

0010

Data Read

DRD

0011

Data Write

DWR

0100

Instruction Fetch

IRD

0101

Prefetch

PREFETCH

0110

Eviction

EVICT

0111

Snoop

SNOOP

1000

16.9.2.5 Bus and Interconnect Errors

The bus and interconnect errors are defined with the 2-bit PP (participation), 1-bit T (time-out), and 2-bit II

(memory or I/O) sub-fields, in addition to the LL and RRRR sub-fields (see Table 16-14). The bus error conditions

are implementation dependent and related to the type of bus implemented by the processor. Likewise, the inter-

connect error conditions are predicated on a specific implementation-dependent interconnect model that describes

the connections between the different levels of the storage hierarchy. The type of bus is implementation depen-

dent, and as such is not specified in this document. A bus or interconnect transaction consists of a request involving

an address and a response.

Table 16-14. Encodings of PP, T, and II Sub-Fields

Sub-Field

Transaction

Mnemonic

Binary Encoding

PP (Participation)

Local processor* originated request

SRC

Local processor* responded to request

RES

Local processor* observed error as third party

OBS

Generic

T (Time-out)

Request timed out

TIMEOUT

Request did not time out

NOTIMEOUT

II (Memory or I/O)

Memory Access

Reserved

I/O

Other transaction

NOTE:

* Local processor differentiates the processor reporting the error from other system components (including the APIC, other proces-

sors, etc.).

Vol. 3B

16-23

MACHINE-CHECK ARCHITECTURE

16.9.2.6 Memory Controller and Extended Memory Errors

The memory controller errors are defined with the 3-bit MMM (memory transaction type), and 4-bit CCCC (channel)

sub-fields. The encodings for MMM and CCCC are defined in Table 16-15. Extended Memory errors use the same

encodings and are used to report errors in memory used as a cache.

Table 16-15. Encodings of MMM and CCCC Sub-Fields

Sub-Field

Transaction

Mnemonic

Binary Encoding

MMM

Generic undefined request

GEN

000

Memory read error

001

Memory write error

010

Address/Command Error

011

Memory Scrubbing Error

100

Reserved

101-111

CCCC

Channel number

CHN

0000-1110

Channel not specified

1111

Note that the CCCC channel number may be enumerated from zero separately by each memory controller on a

system. On a multi-socket system, or a system with multiple memory controllers per socket, it is necessary to also

consider which machine check bank logged the error. See Chapter 17 for details on specific implementations.

16.9.3 Architecturally Defined UCR Errors

Software recoverable compound error code are defined in this section.

16.9.3.1 Architecturally Defined SRAO Errors

The following two SRAO errors are architecturally defined.

• UCR Errors detected by memory controller scrubbing; and

• UCR Errors detected during L3 cache (L3) explicit writebacks.

The MCA error code encodings for these two architecturally-defined UCR errors corresponds to sub-classes of

compound MCA error codes (see Table 16-10). Their values and compound encoding format are given in Table

16-16.

Table 16-16. MCA Compound Error Code Encoding for SRAO Errors

Type

MCACOD Value

MCA Error Code Encoding¹

Memory Scrubbing

C0H - CFH

0000_0000_1100_CCCC

000F 0000 1MMM CCCC (Memory Controller Error), where

Memory subfield MMM = 100B (memory scrubbing)

Channel subfield CCCC = channel # or generic

L3 Explicit Writeback

17AH

0000_0001_0111_1010

000F 0001 RRRR TTLL (Cache Hierarchy Error) where

Request subfields RRRR = 0111B (Eviction)

Transaction Type subfields TT = 10B (Generic)

Level subfields LL = 10B

NOTES:

1. Note that for both of these errors the correction report filtering (F) bit (bit 12) of the MCA error must be ignored.

16-24

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Table 16-17 lists values of relevant bit fields of IA32_MCi_STATUS for architecturally defined SRAO errors.

Table 16-17. IA32_MCi_STATUS Values for SRAO Errors

SRAO Error

Valid

OVER

MISCV

ADDRV

PCC

MCACOD

Memory Scrubbing

x¹

C0H-CFH

L3 Explicit Writeback

x¹

17AH

NOTES:

1. When signaled as MCE, EN=1 and S=1. If error was signaled via CMC, then EN=x, and S=0.

For both the memory scrubbing and L3 explicit writeback errors, the ADDRV and MISCV flags in the IA32_M-

Ci_STATUS register are set to indicate that the offending physical address information is available from the

IA32_MCi_MISC and the IA32_MCi_ADDR registers. For the memory scrubbing and L3 explicit writeback errors,

the address mode in the IA32_MCi_MISC register should be set as physical address mode (010b) and the address

LSB information in the IA32_MCi_MISC register should indicate the lowest valid address bit in the address informa-

tion provided from the IA32_MCi_ADDR register.

MCE signal is broadcast to all logical processors as outlined in Section 16.10.4.1. If LMCE is supported and enabled,

some errors (not limited to UCR errors) may be delivered to only a single logical processor. System software should

consult IA32_MCG_STATUS.LMCE_S to determine if the MCE signaled is only to this logical processor.

IA32_MCi_STATUS banks can be shared by logical processors within a core or within the same package. So several

logical processors may find an SRAO error in the shared IA32_MCi_STATUS bank but other processors do not find

it in any of the IA32_MCi_STATUS banks. Table 16-18 shows the RIPV and EIPV flag indication in the IA32_MC-

G_STATUS register for the memory scrubbing and L3 explicit writeback errors on both the reporting and non-

reporting logical processors.

Table 16-18. IA32_MCG_STATUS Flag Indication for SRAO Errors

SRAO Type

Reporting Logical Processors

Non-reporting Logical Processors

RIPV

EIPV

RIPV

EIPV

Memory Scrubbing

L3 Explicit Writeback

16.9.3.2 Architecturally Defined SRAR Errors

The following two SRAR errors are architecturally defined.

• UCR Errors detected on data load; and

• UCR Errors detected on instruction fetch.

The MCA error code encodings for these two architecturally-defined UCR errors corresponds to sub-classes of

compound MCA error codes (see Table 16-10). Their values and compound encoding format are given in Table

16-19.

Table 16-19. MCA Compound Error Code Encoding for SRAR Errors

Type

MCACOD Value

MCA Error Code Encoding¹

Data Load

134H

0000_0001_0011_0100

000F 0001 RRRR TTLL (Cache Hierarchy Error), where

Request subfield RRRR = 0011B (Data Load)

Transaction Type subfield TT= 01B (Data)

Level subfield LL = 00B (Level 0)

Instruction Fetch

150H

0000_0001_0101_0000

000F 0001 RRRR TTLL (Cache Hierarchy Error), where

Request subfield RRRR = 0101B (Instruction Fetch)

Transaction Type subfield TT= 00B (Instruction)

Level subfield LL = 00B (Level 0)

Vol. 3B

16-25

MACHINE-CHECK ARCHITECTURE

NOTES:

1. Note that for both of these errors the correction report filtering (F) bit (bit 12) of the MCA error must be ignored.

Table 16-20 lists values of relevant bit fields of IA32_MCi_STATUS for architecturally defined SRAR errors.

Table 16-20. IA32_MCi_STATUS Values for SRAR Errors

SRAR Error

Valid

OVER

MISCV

ADDRV

PCC

MCACOD

Data Load

134H

Instruction Fetch

150H

For both the data load and instruction fetch errors, the ADDRV and MISCV flags in the IA32_MCi_STATUS register

are set to indicate that the offending physical address information is available from the IA32_MCi_MISC and the

IA32_MCi_ADDR registers. For the data load and instruction fetch errors, the address mode in the IA32_MCi_MISC

MCE signal is broadcast to all logical processors on the system on which the UCR errors are supported, except when

the processor supports LMCE and LMCE is enabled by system software (see Section 16.3.1.5). The IA32_MC-

G_STATUS MSR allows system software to distinguish the affected logical processor of an SRAR error amongst

logical processors that observed SRAR via MCi_STATUS bank.

Table 16-21 shows the RIPV and EIPV flag indication in the IA32_MCG_STATUS register for the data load and

instruction fetch errors on both the reporting and non-reporting logical processors. The recoverable SRAR error

reported by a processor may be continuable, where the system software can interpret the context of continuable

as follows: the error was isolated, contained. If software can rectify the error condition in the current instruction

stream, the execution context on that logical processor can be continued without loss of information.

Table 16-21. IA32_MCG_STATUS Flag Indication for SRAR Errors

SRAR Type

Affected Logical Processor

Non-Affected Logical Processors

RIPV

EIPV

Continuable

RIPV

EIPV

Continuable

Recoverable-

Yes¹

continuable

Yes

Recoverable-not-

continuable

NOTES:

1. see the definition of the context of “continuable” above and additional detail below.

SRAR Error And Affected Logical Processors

The affected logical processor is the one that has detected and raised an SRAR error at the point of the consump-

tion in the execution flow. The affected logical processor should find the Data Load or the Instruction Fetch error

information in the IA32_MCi_STATUS register that is reporting the SRAR error.

Table 16-21 list the actionable scenarios that system software can respond to an SRAR error on an affected logical

processor according to RIPV and EIPV values:

• Recoverable-Continuable SRAR Error (RIPV=1, EIPV=1):

For Recoverable-Continuable SRAR errors, the affected logical processor should find that both the IA32_MC-

G_STATUS.RIPV and the IA32_MCG_STATUS.EIPV flags are set, indicating that system software may be able to

restart execution from the interrupted context if it is able to rectify the error condition. If system software

cannot rectify the error condition then it must treat the error as a recoverable error where restarting execution

with the interrupted context is not possible. Restarting without rectifying the error condition will result in most

cases with another SRAR error on the same instruction.

16-26

Vol. 3B

MACHINE-CHECK ARCHITECTURE

• Recoverable-not-continuable SRAR Error (RIPV=0, EIPV=x):

For Recoverable-not-continuable errors, the affected logical processor should find that either

- IA32_MCG_STATUS.RIPV= 0, IA32_MCG_STATUS.EIPV=1, or

- IA32_MCG_STATUS.RIPV= 0, IA32_MCG_STATUS.EIPV=0.

In either case, this indicates that the error is detected at the instruction pointer saved on the stack for this

machine check exception and restarting execution with the interrupted context is not possible. System

software may take the following recovery actions for the affected logical processor:

• The current executing thread cannot be continued. System software must terminate the interrupted

stream of execution and provide a new stream of execution on return from the machine check handler

for the affected logical processor.

SRAR Error And Non-Affected Logical Processors

The logical processors that observed but not affected by an SRAR error should find that the RIPV flag in the

IA32_MCG_STATUS register is set and the EIPV flag in the IA32_MCG_STATUS register is cleared, indicating that it

is safe to restart the execution at the instruction saved on the stack for the machine check exception on these

processors after the recovery action is successfully taken by system software.

16.9.4 Multiple MCA Errors

When multiple MCA errors are detected within a certain detection window, the processor may aggregate the

reporting of these errors together as a single event, i.e., a single machine exception condition. If this occurs,

system software may find multiple MCA errors logged in different MC banks on one logical processor or find

multiple MCA errors logged across different processors for a single machine check broadcast event. In order to

handle multiple UCR errors reported from a single machine check event and possibly recover from multiple errors,

system software may consider the following:

• Whether it can recover from multiple errors is determined by the most severe error reported on the system. If

the most severe error is found to be an unrecoverable error (VAL=1, UC=1, PCC=1 and EN=1) after system

software examines the MC banks of all processors to which the MCA signal is broadcast, recovery from the

multiple errors is not possible and system software needs to reset the system.

• When multiple recoverable errors are reported and no other fatal condition (e.g., overflowed condition for SRAR

error) is found for the reported recoverable errors, it is possible for system software to recover from the

multiple recoverable errors by taking necessary recovery action for each individual recoverable error. However,

system software can no longer expect one to one relationship with the error information recorded in the

IA32_MCi_STATUS register and the states of the RIPV and EIPV flags in the IA32_MCG_STATUS register as the

states of the RIPV and the EIPV flags in the IA32_MCG_STATUS register may indicate the information for the

most severe error recorded on the processor. System software is required to use the RIPV flag indication in the

IA32_MCG_STATUS register to make a final decision of recoverability of the errors and find the restart-ability

requirement after examining each IA32_MCi_STATUS register error information in the MC banks.

In certain cases where system software observes more than one SRAR error logged for a single logical

processor, it can no longer rely on affected threads as specified in Table 15-20 above. System software is

recommended to reset the system if this condition is observed.

16.9.5 Machine-Check Error Codes Interpretation

Chapter 17, “Interpreting Machine Check Error Codes,” provides information on interpreting the MCA error code,

model-specific error code, and other information error code fields. For P6 family processors, information has been

included on decoding external bus errors. For Pentium 4 and Intel Xeon processors; information is included on

external bus, internal timer and cache hierarchy errors.

Vol. 3B

16-27

MACHINE-CHECK ARCHITECTURE

16.10 GUIDELINES FOR WRITING MACHINE-CHECK SOFTWARE

The machine-check architecture and error logging can be used in three different ways:

• To detect machine errors during normal instruction execution, using the machine-check exception (#MC).

• To periodically check and log machine errors.

• To examine recoverable UCR errors, determine software recoverability and perform recovery actions via a

machine-check exception handler or a corrected machine-check interrupt handler.

To use the machine-check exception, the operating system or executive software must provide a machine-check

exception handler. This handler may need to be designed specifically for each family of processors.

A special program or utility is required to log machine errors.

Guidelines for writing a machine-check exception handler or a machine-error logging utility are given in the

following sections.

16.10.1 Machine-Check Exception Handler

The machine-check exception (#MC) corresponds to vector 18. To service machine-check exceptions, a trap gate

must be added to the IDT. The pointer in the trap gate must point to a machine-check exception handler. Two

approaches can be taken to designing the exception handler:

1. The handler can merely log all the machine status and error information, then call a debugger or shut down the

system.

2. The handler can analyze the reported error information and, in some cases, attempt to correct the error and

restart the processor.

For Pentium 4, Intel Xeon, Intel Atom, P6 family, and Pentium processors; virtually all machine-check conditions

cannot be corrected (they result in abort-type exceptions). The logging of status and error information is therefore

a baseline implementation requirement.

When IA32_MCG_CAP[24] is clear, consider the following when writing a machine-check exception handler:

• To determine the nature of the error, the handler must read each of the error-reporting register banks. The

count field in the IA32_MCG_CAP register gives number of register banks. The first register of register bank 0

is at address 400H.

• The VAL (valid) flag in each IA32_MCi_STATUS register indicates whether the error information in the register

is valid. If this flag is clear, the registers in that bank do not contain valid error information and do not need to

be checked.

• To write a portable exception handler, only the MCA error code field in the IA32_MCi_STATUS register should be

checked. See Section 16.9, “Interpreting the MCA Error Codes,” for information that can be used to write an

algorithm to interpret this field.

• Correctable errors are corrected automatically by the processor. The UC flag in each IA32_MCi_STATUS reg-

ister indicates whether the processor automatically corrected an error.

• The RIPV, PCC, and OVER flags in each IA32_MCi_STATUS register indicate whether recovery from the error is

possible. If PCC or OVER are set, recovery is not possible. If RIPV is not set, program execution can not be

restarted reliably. When recovery is not possible, the handler typically records the error information and signals

an abort to the operating system.

• The RIPV flag in the IA32_MCG_STATUS register indicates whether the program can be restarted at the

instruction indicated by the instruction pointer (the address of the instruction pushed on the stack when the

exception was generated). If this flag is clear, the processor may still be able to be restarted (for debugging

purposes) but not without loss of program continuity.

• For unrecoverable errors, the EIPV flag in the IA32_MCG_STATUS register indicates whether the instruction

indicated by the instruction pointer pushed on the stack (when the exception was generated) is related to the

error. If the flag is clear, the pushed instruction may not be related to the error.

• The MCIP flag in the IA32_MCG_STATUS register indicates whether a machine-check exception was generated.

Before returning from the machine-check exception handler, software should clear this flag so that it can be

used reliably by an error logging utility. The MCIP flag also detects recursion. The machine-check architecture

16-28

Vol. 3B

MACHINE-CHECK ARCHITECTURE

does not support recursion. When the processor detects machine-check recursion, it enters the shutdown

state.

Example 16-2 gives typical steps carried out by a machine-check exception handler.

Example 16-2. Machine-Check Exception Handler Pseudocode

IF CPU supports MCE

THEN

IF CPU supports MCA

THEN

call errorlogging routine; (* returns restartability *)

FI;

ELSE (* Pentium(R) processor compatible *)

READ P5_MC_ADDR

READ P5_MC_TYPE;

report RESTARTABILITY to console;

FI;

IF error is not restartable

THEN

report RESTARTABILITY to console;

abort system;

FI;

CLEAR MCIP flag in IA32_MCG_STATUS;

16.10.2 Pentium Processor Machine-Check Exception Handling

Machine-check exception handler on P6 family, Intel Atom and later processor families, should follow the guidelines

described in Section 16.10.1 and Example 16-2 that check the processor’s support of MCA.

NOTE

On processors that support MCA (CPUID.1.EDX.MCA = 1) reading the P5_MC_TYPE and

P5_MC_ADDR registers may produce invalid data.

When machine-check exceptions are enabled for the Pentium processor (MCE flag is set in control register CR4),

the machine-check exception handler uses the RDMSR instruction to read the error type from the P5_MC_TYPE

16.10.3 Logging Correctable Machine-Check Errors

The error handling routine for servicing the machine-check exceptions is responsible for logging uncorrected

errors.

If a machine-check error is correctable, the processor does not generate a machine-check exception for it. To

detect correctable machine-check errors, a utility program must be written that reads each of the machine-check

error-reporting register banks and logs the results in an accounting file or data structure. This utility can be imple-

mented in either of the following ways.

• A system daemon that polls the register banks on an infrequent basis, such as hourly or daily.

• A user-initiated application that polls the register banks and records the exceptions. Here, the actual polling

service is provided by an operating-system driver or through the system call interface.

• An interrupt service routine servicing CMCI can read the MC banks and log the error. Please refer to Section

16.10.4.2 for guidelines on logging correctable machine checks.

Example 16-3 gives pseudocode for an error logging utility.

Vol. 3B

16-29

MACHINE-CHECK ARCHITECTURE

Example 16-3. Machine-Check Error Logging Pseudocode

Assume that execution is restartable;

IF the processor supports MCA

THEN

FOR each bank of machine-check registers

READ IA32_MCi_STATUS;

IF VAL flag in IA32_MCi_STATUS = 1

THEN

IF ADDRV flag in IA32_MCi_STATUS = 1

THEN READ IA32_MCi_ADDR;

FI;

IF MISCV flag in IA32_MCi_STATUS = 1

THEN READ IA32_MCi_MISC;

FI;

IF MCIP flag in IA32_MCG_STATUS = 1

(* Machine-check exception is in progress *)

AND PCC flag in IA32_MCi_STATUS = 1

OR RIPV flag in IA32_MCG_STATUS = 0

(* execution is not restartable *)

THEN

RESTARTABILITY = FALSE;

return RESTARTABILITY to calling procedure;

FI;

Save time-stamp counter and processor ID;

Set IA32_MCi_STATUS to all 0s;

Execute serializing instruction (i.e., CPUID);

FI;

OD;

FI;

If the processor supports the machine-check architecture, the utility reads through the banks of error-reporting

registers looking for valid register entries. It then saves the values of the IA32_MCi_STATUS, IA32_MCi_ADDR,

IA32_MCi_MISC, and IA32_MCG_STATUS registers for each bank that is valid. The routine minimizes processing

time by recording the raw data into a system data structure or file, reducing the overhead associated with polling.

User utilities analyze the collected data in an off-line environment.

When the MCIP flag is set in the IA32_MCG_STATUS register, a machine-check exception is in progress and the

machine-check exception handler has called the exception logging routine.

Once the logging process has been completed the exception-handling routine must determine whether execution

can be restarted, which is usually possible when damage has not occurred (The PCC flag is clear, in the IA32_M-

Ci_STATUS register) and when the processor can guarantee that execution is restartable (the RIPV flag is set in the

IA32_MCG_STATUS register). If execution cannot be restarted, the system is not recoverable and the exception-

handling routine should signal the console appropriately before returning the error status to the Operating System

kernel for subsequent shutdown.

The machine-check architecture allows buffering of exceptions from a given error-reporting bank although the

Pentium 4, Intel Xeon, Intel Atom, and P6 family processors do not implement this feature. The error logging

routine should provide compatibility with future processors by reading each hardware error-reporting bank's

IA32_MCi_STATUS register and then writing 0s to clear the OVER and VAL flags in this register. The error logging

utility should re-read the IA32_MCi_STATUS register for the bank ensuring that the valid bit is clear. The processor

will write the next error into the register bank and set the VAL flags.

Additional information that should be stored by the exception-logging routine includes the processor’s time-stamp

counter value, which provides a mechanism to indicate the frequency of exceptions. A multiprocessing operating

system stores the identity of the processor node incurring the exception using a unique identifier, such as the

processor’s APIC ID (see Section 11.8, “Handling Interrupts”).

The basic algorithm given in Example 16-3 can be modified to provide more robust recovery techniques. For

example, software has the flexibility to attempt recovery using information unavailable to the hardware. Specifi-

cally, the machine-check exception handler can, after logging carefully analyze the error-reporting registers when

the error-logging routine reports an error that does not allow execution to be restarted. These recovery techniques

16-30

Vol. 3B

MACHINE-CHECK ARCHITECTURE

can use external bus related model-specific information provided with the error report to localize the source of the

error within the system and determine the appropriate recovery strategy.

16.10.4 Machine-Check Software Handler Guidelines for Error Recovery

16.10.4.1 Machine-Check Exception Handler for Error Recovery

When writing a machine-check exception (MCE) handler to support software recovery from Uncorrected Recover-

able (UCR) errors, consider the following:

• When IA32_MCG_CAP [24] is zero, there are no recoverable errors supported and all machine-check are fatal

exceptions. The logging of status and error information is therefore a baseline implementation requirement.

• When IA32_MCG_CAP [24] is 1, certain uncorrected errors called uncorrected recoverable (UCR) errors may be

software recoverable. The handler can analyze the reported error information, and in some cases attempt to

recover from the uncorrected error and continue execution.

• For processors on which CPUID reports DisplayFamily_DisplayModel as 06H_0EH and onward, an MCA signal is

broadcast to all logical processors in the system; see the CPUID instruction in Chapter 3, “Instruction Set

Reference, A-L‚” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. Due to the

potentially shared machine check MSR resources among the logical processors on the same package/core, the

MCE handler may be required to synchronize with the other processors that received a machine check error and

serialize access to the machine check registers when analyzing, logging, and clearing the information in the

machine check registers.

- On processors that indicate ability for local machine-check exception (MCG_LMCE_P), hardware can choose

to report the error to only a single logical processor if system software has enabled LMCE by setting

IA32_MCG_EXT_CTL[LMCE_EN] = 1 as outlined in Section 16.3.1.5.

• The VAL (valid) flag in each IA32_MCi_STATUS register indicates whether the error information in the register

is valid. If this flag is clear, the registers in that bank do not contain valid error information and should not be

checked.

• The MCE handler is primarily responsible for processing uncorrected errors. The UC flag in each IA32_M-

Ci_Status register indicates whether the reported error was corrected (UC=0) or uncorrected (UC=1). The MCE

handler can optionally log and clear the corrected errors in the MC banks if it can implement software algorithm

to avoid the undesired race conditions with the CMCI or CMC polling handler.

• For uncorrectable errors, the EIPV flag in the IA32_MCG_STATUS register indicates (when set) that the

instruction pointed to by the instruction pointer pushed onto the stack when the machine-check exception is

generated is directly associated with the error. When this flag is cleared, the instruction pointed to may not be

associated with the error.

• The MCIP flag in the IA32_MCG_STATUS register indicates whether a machine-check exception was generated.

When a machine check exception is generated, it is expected that the MCIP flag in the IA32_MCG_STATUS

piece of hardware signaling an interrupt with vector 18.

When IA32_MCG_CAP [24] is 1, the following rules can apply when writing a machine check exception (MCE)

handler to support software recovery:

• The PCC flag in each IA32_MCi_STATUS register indicates whether recovery from the error is possible for

uncorrected errors (UC=1). If the PCC flag is set for enabled uncorrected errors (UC=1 and EN=1), recovery is

not possible. When recovery is not possible, the MCE handler typically records the error information and signals

the operating system to reset the system.

• The RIPV flag in the IA32_MCG_STATUS register indicates whether restarting the program execution from the

instruction pointer saved on the stack for the machine check exception is possible. When the RIPV is set,

program execution can be restarted reliably when recovery is possible. If the RIPV flag is not set, program

execution cannot be restarted reliably. In this case the recovery algorithm may involve terminating the current

program execution and resuming an alternate thread of execution upon return from the machine check handler

when recovery is possible. When recovery is not possible, the MCE handler signals the operating system to

reset the system.

Vol. 3B

16-31

MACHINE-CHECK ARCHITECTURE

•

When the EN flag is zero but the VAL and UC flags are one in the IA32_MCi_STATUS register, the reported

uncorrected error in this bank is not enabled. As uncorrected errors with the EN flag = 0 are not the source of

machine check exceptions, the MCE handler should log and clear non-enabled errors when the S bit is set and

should continue searching for enabled errors from the other IA32_MCi_STATUS registers. Note that when

IA32_MCG_CAP [24] is 0, any uncorrected error condition (VAL =1 and UC=1) including the one with the EN

flag cleared are fatal and the handler must signal the operating system to reset the system. For the errors that

do not generate machine check exceptions, the EN flag has no meaning.

•

When the VAL flag is one, the UC flag is one, the EN flag is one and the PCC flag is zero in the IA32_MCi_STATUS

the S flag and the AR flag to find the type of the UCR error for software recovery and determine if software error

recovery is possible.

•

When both the S and the AR flags are clear in the IA32_MCi_STATUS register for the UCR error (VAL=1, UC=1,

EN=x and PCC=0), the error in this bank is an uncorrected no-action required error (UCNA). UCNA errors are

uncorrected but do not require any OS recovery action to continue execution. These errors indicate that some

data in the system is corrupt, but that data has not been consumed and may not be consumed. If that data is

consumed a non-UCNA machine check exception will be generated. UCNA errors are signaled in the same way

as corrected machine check errors and the CMCI and CMC polling handler is primarily responsible for handling

UCNA errors. Like corrected errors, the MCA handler can optionally log and clear UCNA errors as long as it can

avoid the undesired race condition with the CMCI or CMC polling handler. As UCNA errors are not the source of

machine check exceptions, the MCA handler should continue searching for uncorrected or software recoverable

errors in all other MC banks.

•

When the S flag in the IA32_MCi_STATUS register is set for the UCR error ((VAL=1, UC=1, EN=1 and PCC=0),

the error in this bank is software recoverable and it was signaled through a machine-check exception. The AR

flag in the IA32_MCi_STATUS register further clarifies the type of the software recoverable errors.

•

When the AR flag in the IA32_MCi_STATUS register is clear for the software recoverable error (VAL=1, UC=1,

EN=1, PCC=0 and S=1), the error in this bank is a software recoverable action optional (SRAO) error. The MCE

handler and the operating system can analyze the IA32_MCi_STATUS [15:0] to implement MCA error code

specific optional recovery action, but this recovery action is optional. System software can resume the program

execution from the instruction pointer saved on the stack for the machine check exception when the RIPV flag

in the IA32_MCG_STATUS register is set.

•

Even if the OVER flag in the IA32_MCi_STATUS register is set for the SRAO error (VAL=1, UC=1, EN=1, PCC=0,

S=1 and AR=0), the MCE handler can take recovery action for the SRAO error logged in the IA32_MCi_STATUS

instruction pointer saved on the stack for the machine check exception is still possible for the overflowed SRAO

error if the RIPV flag in the IA32_MCG_STATUS is set.

•

When the AR flag in the IA32_MCi_STATUS register is set for the software recoverable error (VAL=1, UC=1,

EN=1, PCC=0 and S=1), the error in this bank is a software recoverable action required (SRAR) error. The MCE

handler and the operating system must take recovery action in order to continue execution after the machine-

check exception. The MCA handler and the operating system need to analyze the IA32_MCi_STATUS [15:0] to

determine the MCA error code specific recovery action. If no recovery action can be performed, the operating

system must reset the system.

•

When the OVER flag in the IA32_MCi_STATUS register is set for the SRAR error (VAL=1, UC=1, EN=1, PCC=0,

S=1 and AR=1), the MCE handler cannot take recovery action as the information of the SRAR error in the

IA32_MCi_STATUS register was potentially lost due to the overflow condition. Since the recovery action for

SRAR errors must be taken, the MCE handler must signal the operating system to reset the system.

•

When the MCE handler cannot find any uncorrected (VAL=1, UC=1 and EN=1) or any software recoverable

errors (VAL=1, UC=1, EN=1, PCC=0 and S=1) in any of the IA32_MCi banks of the processors, this is an

unexpected condition for the MCE handler and the handler should signal the operating system to reset the

system.

•

Before returning from the machine-check exception handler, software must clear the MCIP flag in the IA32_MC-

G_STATUS register. The MCIP flag is used to detect recursion. The machine-check architecture does not support

recursion. When the processor receives a machine check when MCIP is set, it automatically enters the

shutdown state.

Example 16-4 gives pseudocode for an MC exception handler that supports recovery of UCR.

16-32

Vol. 3B

MACHINE-CHECK ARCHITECTURE

Example 16-4. Machine-Check Error Handler Pseudocode Supporting UCR

MACHINE CHECK HANDLER: (* Called from INT 18 handler *)

NOERROR = TRUE;

ProcessorCount = 0;

IF CPU supports MCA

THEN

RESTARTABILITY = TRUE;

IF (Processor Family = 6 AND DisplayModel ≥ 0EH) OR (Processor Family > 6)

THEN

IF ( MCG_LMCE = 1)

MCA_BROADCAST = FALSE;

ELSE

MCA_BROADCAST = TRUE;

FI;

Acquire SpinLock;

ProcessorCount++; (* Allowing one logical processor at a time to examine machine check registers *)

CALL MCA ERROR PROCESSING; (* returns RESTARTABILITY and NOERROR *)

ELSE

MCA_BROADCAST = FALSE;

(* Implement a rendezvous mechanism with the other processors if necessary *)

CALL MCA ERROR PROCESSING;

FI;

ELSE (* Pentium(R) processor compatible *)

READ P5_MC_ADDR

READ P5_MC_TYPE;

RESTARTABILITY = FALSE;

FI;

IF NOERROR = TRUE

THEN

IF NOT (MCG_RIPV = 1 AND MCG_EIPV = 0)

THEN

RESTARTABILITY = FALSE;

FI;

IF RESTARTABILITY = FALSE

THEN

Report RESTARTABILITY to console;

Reset system;

FI;

IF MCA_BROADCAST = TRUE

THEN

IF ProcessorCount = MAX_PROCESSORS

AND NOERROR = TRUE

THEN

Report RESTARTABILITY to console;

Reset system;

FI;

Release SpinLock;

Wait till ProcessorCount = MAX_PROCESSRS on system;

(* implement a timeout and abort function if necessary *)

FI;

CLEAR IA32_MCG_STATUS;

RESUME Execution;

(* End of MACHINE CHECK HANDLER*)

MCA ERROR PROCESSING:

(* MCA Error Processing Routine called from MCA Handler *)

IF MCIP flag in IA32_MCG_STATUS = 0

THEN (* MCIP=0 upon MCA is unexpected *)

RESTARTABILITY = FALSE;

FI;

Vol. 3B

16-33

MACHINE-CHECK ARCHITECTURE

FOR each bank of machine-check registers

CLEAR_MC_BANK = FALSE;

READ IA32_MCi_STATUS;

IF VAL Flag in IA32_MCi_STATUS = 1

THEN

IF UC Flag in IA32_MCi_STATUS = 1

THEN

IF Bit 24 in IA32_MCG_CAP = 0

THEN (* the processor does not support software error recovery *)

RESTARTABILITY = FALSE;

NOERROR = FALSE;

GOTO LOG MCA REGISTER;

FI;

(* the processor supports software error recovery *)

IF EN Flag in IA32_MCi_STATUS = 0 AND OVER Flag in IA32_MCi_STATUS=0

THEN (* It is a spurious MCA Log. Log and clear the register *)

CLEAR_MC_BANK = TRUE;

GOTO LOG MCA REGISTER;

FI;

IF PCC = 1 and EN = 1 in IA32_MCi_STATUS

THEN (* processor context might have been corrupted *)

RESTARTABILITY = FALSE;

ELSE (* It is a uncorrected recoverable (UCR) error *)

IF S Flag in IA32_MCi_STATUS = 0

THEN

IF AR Flag in IA32_MCi_STATUS = 0

THEN (* It is a uncorrected no action required (UCNA) error *)

GOTO CONTINUE; (* let CMCI and CMC polling handler to process *)

ELSE

RESTARTABILITY = FALSE; (* S=0, AR=1 is illegal *)

FI;

IF RESTARTABILITY = FALSE

THEN (* no need to take recovery action if RESTARTABILITY is already false *)

NOERROR = FALSE;

GOTO LOG MCA REGISTER;

FI;

(* S in IA32_MCi_STATUS = 1 *)

IF AR Flag in IA32_MCi_STATUS = 1

THEN (* It is a software recoverable and action required (SRAR) error *)

IF OVER Flag in IA32_MCi_STATUS = 1

THEN

RESTARTABILITY = FALSE;

NOERROR = FALSE;

GOTO LOG MCA REGISTER;

IF MCACOD Value in IA32_MCi_STATUS is recognized

AND Current Processor is an Affected Processor

THEN

Implement MCACOD specific recovery action;

CLEAR_MC_BANK = TRUE;

ELSE

RESTARTABILITY = FALSE;

FI;

ELSE (* It is a software recoverable and action optional (SRAO) error *)

IF OVER Flag in IA32_MCi_STATUS = 0 AND

MCACOD in IA32_MCi_STATUS is recognized

THEN

Implement MCACOD specific recovery action;

FI;

CLEAR_MC_BANK = TRUE;

FI; AR

FI; PCC

NOERROR = FALSE;

16-34

Vol. 3B

MACHINE-CHECK ARCHITECTURE

GOTO LOG MCA REGISTER;

ELSE (* It is a corrected error; continue to the next IA32_MCi_STATUS *)

GOTO CONTINUE;

FI; UC

FI; VAL

LOG MCA REGISTER:

SAVE IA32_MCi_STATUS;

If MISCV in IA32_MCi_STATUS

THEN

SAVE IA32_MCi_MISC;

FI;

IF ADDRV in IA32_MCi_STATUS

THEN

SAVE IA32_MCi_ADDR;

FI;

IF CLEAR_MC_BANK = TRUE

THEN

SET all 0 to IA32_MCi_STATUS;

If MISCV in IA32_MCi_STATUS

THEN

SET all 0 to IA32_MCi_MISC;

FI;

IF ADDRV in IA32_MCi_STATUS

THEN

SET all 0 to IA32_MCi_ADDR;

FI;

CONTINUE:

OD;

( *END FOR *)

RETURN;

(* End of MCA ERROR PROCESSING*)

16.10.4.2 Corrected Machine-Check Handler for Error Recovery

When writing a corrected machine check handler, which is invoked as a result of CMCI or called from an OS CMC

Polling dispatcher, consider the following:

• The VAL (valid) flag in each IA32_MCi_STATUS register indicates whether the error information in the register

is valid. If this flag is clear, the registers in that bank does not contain valid error information and does not need

to be checked.

• The CMCI or CMC polling handler is responsible for logging and clearing corrected errors. The UC flag in each

IA32_MCi_Status register indicates whether the reported error was corrected (UC=0) or not (UC=1).

• When IA32_MCG_CAP [24] is one, the CMC handler is also responsible for logging and clearing uncorrected no-

action required (UCNA) errors. When the UC flag is one but the PCC, S, and AR flags are zero in the IA32_M-

Ci_STATUS register, the reported error in this bank is an uncorrected no-action required (UCNA) error. In cases

when SRAO error are signaled as UCNA error via CMCI, software can perform recovery for those errors

identified in Table 16-16.

• In addition to corrected errors and UCNA errors, the CMC handler optionally logs uncorrected (UC=1 and

PCC=1), software recoverable machine check errors (UC=1, PCC=0 and S=1), but should avoid clearing those

errors from the MC banks. Clearing these errors may result in accidentally removing these errors before these

errors are actually handled and processed by the MCE handler for attempted software error recovery.

Example 16-5 gives pseudocode for a CMCI handler with UCR support.

Vol. 3B

16-35

CHAPTER 19

LAST BRANCH RECORDS

NOTE

This chapter defines a last-branch recording (LBR) facility that is architectural and part of the Intel

64 architecture. This facility is an enhancement of but distinct from earlier LBR facilities that were

not architectural. Those earlier facilities are documented in Chapter 18.

Support of the architectural LBR feature in a logical processor is reported in CPUID.(EAX=07H,

ECX=0H):EDX[19]=1. When the architectural LBR feature is supported, capability details like the number of LBR

records that are available is indicated in CPUID.1CH:EAX[7:0]. The number of LBR records available varies across

processor generations, so software should only access the available LBR records indicated by

CPUID.1CH:EAX[7:0].

Last Branch Records (LBRs) enable recording of software path history by logging taken branches and other control

flow transfers within processor registers. Each LBR record or entry is comprised of three MSRs:

• IA32_LBR_x_FROM_IP - Holds the source IP of the operation.

• IA32_LBR_x_TO_IP - Holds the destination IP of the operation.

• IA32_LBR_x_INFO - Holds metadata for the operation, including mispredict, TSX, and elapsed cycle time infor-

mation.

LBR records are stored in age order. The most recent LBR entry is stored in IA32_LBR_0_*, the next youngest in

IA32_LBR_1_*, and so on. When an operation to be recorded completes (retires) with LBRs enabled

(IA32_LBR_CTL.LBREn=1), older LBR entries are shifted in the LBR array by one entry, then a record of the new

operation is written into entry 0. See Section 19.1.1 for the list of recorded operations.

The number of LBR entries available for recording operations is dictated by the value in IA32_LBR_DEPTH.DEPTH.

By default, the DEPTH value matches the maximum number of LBRs supported by the processor, but software may

opt to use fewer in order to achieve reduced context switch latency.

In addition to the LBRs, there is a single Last Event Record (LER). It records the last taken branch preceding the

last exception, hardware interrupt, or software interrupt. Like LBRs, the LER is comprised of three MSRs

(IA32_LER_FROM_IP, IA32_LER_TO_IP, IA32_LER_INFO), and is subject to the same dependencies on enabling

and filtering.

Which operations are recorded in LBRs depends upon a series of factors:

• Branch Type Filtering - Software must opt in to the types of branches to be logged; see Section 19.1.2.3.

• Current Privilege Level (CPL) - LBRs can be filtered based on CPL; see Section 19.1.2.5.

• LBR Freeze - LBR and LER recording can be suspended by setting IA32_PERF_GLOBAL_STATUS.LBR_FRZ to 1.

See Section 18.4.7 for details on LBR_FRZ.

On some implementations, recording LBRs may require constraining the number of operations that can complete in

a cycle. As a result, on these implementations, enabling LBRs may have some performance overhead.

19.1

BEHAVIOR

19.1.1 Logged Operations

LBRs can log most control flow transfer operations.

The source IP recorded for a branch instruction is the IP of that instruction. For events that take place between

instructions, the source IP recorded is the IP of the next sequential instruction.

The destination IP recorded is always the target of the branch or event, the next instruction that will execute.

The full list of operations and the respective IPs recorded is shown in Table 19-1.

Vol. 3B

19-1

LAST BRANCH RECORDS

Table 19-1. LBR IP Values for Various Operations

Operation

FROM_IP

TO_IP

Taken Branch¹, Exception, INT3, INTn,

Current IP

Target IP

INTO, TSX Abort

Interrupt

Next IP

Target IP

INIT (BSP)

Next IP

Reset Vector

INIT (AP) + SIPI

Next IP

SIPI Vector

EENTER/ERESUME + EEXIT/AEX

Current IP

Target or Trampoline IP

RSM²

Target IP

#DB, #SMI, VM exit, VM entry

None

NOTES:

1. Direct CALLs with displacement zero, for which the target is typically the next sequential IP, are not treated as

taken branches by LBRs.

2. RSM is only recorded in LBRs when IA32_DEBUGCTL.FREEZE_WHILE_SMM is set to 0.

19.1.2 Configuration

19.1.2.1 Enabling and Disabling

LBRs are enabled by setting IA32_LBR_CTL.LBREn to 1.

Some operations, such as entry to a secure mode like SMM or Intel SGX, can cause LBRs to be temporarily

disabled. Other operations, such as debug exceptions or some SMX operations, disable LBRs and require software

to re-enable them. Details on these interactions can be found in Section 19.1.4.

19.1.2.2 LBR Depth

The number of LBRs used by the processor can be constrained by modifying the IA32_LBR_DEPTH.DEPTH value.

DEPTH defaults to the maximum number of LBRs supported by the processor. Allowed DEPTH values can be found

in CPUID.1CH:EAX[7:0].

Reducing the LBR depth can result in improved performance, by reducing the number of LBRs that need to be read

and/or context switched.

On a software write to IA32_LBR_DEPTH, all LBR entries are reset to 0. LERs are not impacted.

A RDMSR or WRMSR to any IA32_LBR_x_* MSRs, such that x ≥ DEPTH, will generate a #GP exception. Note that

the XSAVES and XRSTORS instructions access only the LBRs associated with entries 0 to DEPTH-1.

By clearing the LBR entries on writes to IA32_LBR_DEPTH, and forbidding any software writes to LBRs ≥ DEPTH, it

is thereby guaranteed that any LBR entries equal to or above DEPTH will have value 0.

19.1.2.3 Branch Type Enabling and Filtering

Software must opt in to the types of branches that are desired to be recorded. These elections are made in

IA32_LBR_CTL; see Section 19.2. Branch type options are listed in Table 19-2; only those enabled will be recorded.

19-2

Vol. 3B

LAST BRANCH RECORDS

Table 19-2. Branch Type Filtering Details

Branch Type

Operations Recorded

COND

Jcc, J*CXZ, and LOOP*

NEAR_IND_JMP

JMP r/m*

NEAR_REL_JMP

JMP rel*

NEAR_IND_CALL

CALL r/m*

NEAR_REL_CALL

CALL rel* (excluding CALLs to the next sequential IP)

NEAR_RET

RET (0C3H)

OTHER_BRANCH

JMP/CALL ptr*, JMP/CALL m*, RET (0C8H), SYS*, interrupts, exceptions (other than debug

exceptions), IRET, INT3, INTn, INTO, TSX Abort, EENTER, ERESUME, EEXIT, AEX, INIT, SIPI, RSM

These encodings match those in IA32_LBR_x_INFO.BR_TYPE.

Control flow transfers that are not recorded include #DB, VM exit, VM entry, and #SMI.

19.1.2.4 Call-Stack Mode

The LBR array is, by default, treated as a ring buffer that captures control flow transitions. However, the finite

depth of the LBR array can be limiting when profiling certain high-level languages (e.g., C++), where a transition

of the execution flow is accompanied by a large number of leaf function calls. These calls to leaf functions, and their

returns, are likely to displace the main execution context from the LBRs.

When call-stack mode is enabled, the LBR array can capture unfiltered call data normally, but as return instructions

are executed the last captured branch (call) record is flushed from the LBRs in a last-in first-out (LIFO) manner.

Thus, branch information pertaining to completed leaf functions will not be retained, while preserving the call stack

information of the main line execution path.

Call-stack mode is enabled by setting IA32_LBR_CTL.CALL_STACK to 1. When enabled, near RET instructions

receive special treatment. Rather than adding a new record in LBR_0, a near RET will instead “pop” the CALL entry

at LBR_0 by shifting entries LBR_1..LBR_[DEPTH-1] up to LBR_0..LBR_[DEPTH-2], and clearing LBR_[DEPTH-1] to

0. Thus, LBR processing software can consume only valid call-stack entries by reading until finding an entry that is

all zeros.

Call-stack mode should be used with branch type enabling configured to capture only CALLs (NEAR_REL_CALL and

NEAR_IND_CALL) and RETs (NEAR_RET). When configured in this manner, the LBR array emulates a call stack,

where CALLs are “pushed” and RETs “pop” them off the stack. If other branch types (JCC, NEAR_*_JMP, or

OTHER_BRANCH) are enabled for recording with call-stack mode, LBR behavior may be undefined.

It is recommended that call-stack mode be used along with CPL filtering, by setting at most one of the OS and USR

bits in the IA32_LBR_CTL MSR. Call-stack mode does not emulate the stack switch that can occur on CPL transi-

tions, and hence monitoring all CPLs may result in a corrupted LBR call stack.

Call-Stack Mode and LBR Freeze

When IA32_DEBUGCTL.FREEZE_LBRS_ON_PMI=1, IA32_PERF_GLOBAL_STATUS.LBR_FRZ will be set to 1 when a

PMI is pended. That will cause LBRs and LERs to cease recording branches until LBR_FRZ is cleared. Because there

may be some “skid”, or instructions retiring, in between the PMI being pended and the PMI being taken, it is

possible that some branches may be missing from the LBRs. In the case of call-stack mode, if a CALL or RET is

missed, that can lead to confusing results where CALL entries fail to get “popped” off the stack, and RETs “pop” the

wrong CALLs.

An alternative is to utilize CPL filtering to limit LBR recording to less privileged modes only (CPL>3) instead of using

the FREEZE_LBRS_ON_PMI=1 feature. This will record branches in the “skid”, but avoid recording any branches in

the privilege level 0 handler.

Vol. 3B

19-3

LAST BRANCH RECORDS

19.1.2.5 CPL Filtering

Software must opt in to which CPL(s) will have branches recorded. If IA32_LBR_CTL.OS=1, then branches in

CPL=0 can be recorded. If IA32_LBR_CTL.USR=1, then branches in CPL>0 can be recorded. For operations which

change the CPL, the operation is recorded in LBRs only if the CPL at the end of the operation is enabled for LBR

recording. In cases where the CPL transitions from a value that is filtered out to a value that is enabled for LBR

recording, the FROM_IP address for the recorded CPL transition branch or event will be 0FFFFFFFFFFFFFFFFH.

19.1.3 Record Data

19.1.3.1 IP Fields

The source and destination IP values in IA32_LBR_x_[FROM|TO]_IP and IA32_LER_x_[FROM|TO]_IP may hold

effective IPs or linear IPs (LIPs), depending on the processor generation. The effective IP is the offset from the CS

base address, while LIP includes the CS base address. Which IP type is used is indicated in CPUID.1CH:EAX[bit 31].

The value read from this field will always be canonical. Note that this includes the case where a canonical violation

(#GP) results from executing sequential code that runs precisely to the end of the lower canonical address space

(where IP[63:MAXLINADDR-1] is 0, but IP[MAXLINADDR-2:0] is all ones). In this case, the FROM_IP will hold the

lowest canonical address in the upper canonical space, such that IP[63:MAXLINADDR-1] is all ones, and IP[MAXLI-

NADDR-2:0] is 0.

In some cases, due to CPL filtering, the FROM_IP of the recorded operation may be filtered out. In this case

0FFFFFFFFFFFFFFFFH will be recorded. See Section 19.1.2.5 for details.

Writes of these fields will be forced canonical, such that the processor ignores the value written to the upper bits

(IP[63:MAXLINADDR-1]).

19.1.3.2 Branch Types

The IA32_LBR_x_INFO.BR_TYPE and IA32_LER_INFO.BR_TYPE fields encode the branch types as shown in Table

19-3.

Table 19-3. IA32_LBR_x_INFO and IA32_LER_INFO Branch Type Encodings

Encoding

Branch Type

0000B

COND

0001B

NEAR_IND_JMP

0010B

NEAR_REL_JMP

0011B

NEAR_IND_CALL

0100B

NEAR_REL_CALL

0101B

NEAR_RET

011xB

Reserved

1xxxB

OTHER_BRANCH

For a list of branch operations that fall into the categories above, see Table 19-2. In future generations, BR_TYPE

bits 2:0 may be used to distinguish between differing types of OTHER_BRANCH.

19.1.3.3 Cycle Time

Each time an operation is recorded in an LBR, the value of the LBR cycle timer is recorded in

IA32_LBR_x_INFO.CYC_CNT. The LBR cycle timer is a saturating counter that counts at the processor clock rate.

Each time an operation is recorded in an LBR, the counter is reset but continues counting.

19-4

Vol. 3B

LAST BRANCH RECORDS

There is an LBR cycle counter valid bit, IA32_LBR_x_INFO.CYC_CNT_VALID. When set, the CYC_CNT field holds a

valid value, the number of elapsed cycles since the last operation recorded in an LBR (up to 0FFFFH).

Some implementations may opt to reduce the granularity of the CYC_CNT field for larger values. The implication of

this is that the least significant bits may be forced to 1 in cases where the count has reached some minimum

threshold. It is guaranteed that this reduced granularity will never result in an inaccuracy of more than 10%.

19.1.3.4 Mispredict Information

IA32_LBR_x_INFO.MISPRED provides an indication of whether the recorded branch was predicted incorrectly by

the processor. The bit is set if either the taken/not-taken direction of a conditional branch was mispredicted, or if

the target of an indirect branch was mispredicted.

19.1.3.5 Intel® TSX Information

IA32_LBR_x_INFO.IN_TSX indicates whether the operation recorded retired during a TSX transaction.

IA32_LBR_x_INFO.TSX_ABORT indicates that the operation is a TSX Abort.

19.1.4 Interaction with Other Processor Features

19.1.4.1 SMM

IA32_LBR_CTL.LBREn is saved and cleared on #SMI, and restored on RSM. As a result of disabling LBRs, the #SMI

is not recorded. RSM is recorded only if IA32_DEBUGCTL.FREEZE_WHILE_SMM is set to 0, and the FROM_IP will be

set to the same value as the TO_IP.

19.1.4.2 SMM Transfer Monitor (STM)

LBREn is not cleared on #SMI when it causes SMM VM exit. Instead, the STM should use the VMCS controls

described in Section 19.1.4.3 to disable LBRs while in SMM, and to restore them on VM entries that exit SMM.

On VMCALL to configure STM, IA32_LBR_CTL is cleared.

19.1.4.3 VMX

By default, LBR operation persists across VMX transitions. However, VMCS fields have been added to enable

constraining LBR usage to within non-root operation only. See details in Table 19-4.

Table 19-4. LBR VMCS Fields

Name

Type

Bit Position

Behavior

Guest IA32_LBR_CTL

Guest State Field

The guest value of IA32_LBR_CTL is written to this field on all

VM exits.

Load Guest IA32_LBR_CTL

Entry Control

When set, VM entry will write the value from the “Guest

IA32_LBR_CTL” guest state field to IA32_LBR_CTL.

Clear IA32_LBR_CTL

Exit Control

When set, VM exit will clear IA32_LBR_CTL after the value has

been saved to the “Guest IA32_LBR_CTL” guest state field.

To enable “guest-only” LBR use, a VMM should set both the “Load Guest IA32_LBR_CTL” entry control and the

“Clear IA32_LBR_CTL” exit control. For “system-wide” LBR use, where LBRs remain enabled across host and

guest(s), a VMM should keep both new VMCS controls clear.

VM entry checks that, if the “Load Guest IA32_LBR_CTL” entry control is 1, bits reserved in the IA32_LBR_CTL MSR

must be 0 in the field for that register.

Vol. 3B

19-5

LAST BRANCH RECORDS

For additional information relating to VMX transitions, see Chapter 25, Chapter 27, and Chapter 28 in the Intel^® 64

and IA-32 Architectures Software Developer’s Manual, Volume 3C.

19.1.4.4 Intel® SGX

On entry to an enclave, via EENTER or ERESUME, logging of LBR entries is suspended. On enclave exit, via EEXIT

or AEX, logging resumes. The cycle counter will continue to run during enclave execution.

An exception to the above is made for opt-in debug enclaves. For such enclaves, LBR logging is not impacted.

19.1.4.5 Debug Exceptions

When a branch happens because of a #DB exception, IA32_LBR_CTL.LBREn is cleared. As a result, the operation is

not recorded.

19.1.4.6 SMX

On GETSEC leaves SENTER or ENTERACCS, IA32_LBR_CTL is cleared. As a result, the operation is not recorded.

19.1.4.7 MWAIT

On an MWAIT that requests a C-state deeper than C1, IA32_LBR_x_* MSRs may be cleared to 0. IA32_LBR_CTL,

IA32_LBR_DEPTH, and IA32_LER_* MSRs will be preserved.

For an MWAIT that enters a C-state equal to or less deep than C1, and all C-states that enter as a result of Hard-

ware Duty Cycling (HDC), all LBR MSRs are preserved.

19.1.4.8 Processor Event-Based Sampling (PEBS)

PEBS records can be configured to include LBRs, by setting PEBS_DATA_CFG.LBREn[3]=1. The number of LBRs to

include in the record is also configurable, via PEBS_DATA_CFG.NUM_LBRS[28:24]. For details on PEBS, see Section

20.9 of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B.

If NUM_LBRS is set to a value greater than LBR_DEPTH, then only LBR_DEPTH entries will be written into the PEBS

record. Further, the Record Size field will be decreased to match the actual size of the record to be written, and the

Record Format field will replace the value of NUM_LBRS with the value of LBR_DEPTH. These adjustments ensure

that software is able to properly interpret the PEBS record.

19.2

MSRS

The MSRs that represent the LBR entries (IA32_LBR_x_[TO|FROM|INFO]) and the LER entry

(IA32_LER_[TO|FROM|INFO]) do not fault on writes. Any address field written will force sign-extension based on

the maximum linear address width supported by the processor, and any non-zero value written to undefined bits

may be ignored such that subsequent reads return 0.

On a warm reset, all LBR MSRs, including IA32_LBR_DEPTH, have their values preserved. However,

IA32_LBR_CTL.LBREn is cleared to 0, disabling LBRs. If a warm reset is triggered while the processor is in the C6

idle state, also known as warm init, all LBR MSRs will be reset to their initial values.

See Table 2-2 in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4, for details on LBR

MSRs.

19.3

FAST LBR READ ACCESS

XSAVES provides a faster means than RDMSR for software to read all LBRs. When using XSAVES for reading LBRs

rather than for context switch, software should take care to ensure that XSAVES does not write LBR state to an area

of memory that has been or will be used by XRSTORS. This could corrupt INIT tracking.

19-6

Vol. 3B

CHAPTER 23

ARCHITECTURE COMPATIBILITY

Intel 64 and IA-32 processors are binary compatible. Compatibility means that, within limited constraints,

programs that execute on previous generations of processors will produce identical results when executed on later

processors. The compatibility constraints and any implementation differences between the Intel 64 and IA-32

processors are described in this chapter.

Each new processor has enhanced the software visible architecture from that found in earlier Intel 64 and IA-32

processors. Those enhancements have been defined with consideration for compatibility with previous and future

processors. This chapter also summarizes the compatibility considerations for those extensions.

23.1

PROCESSOR FAMILIES AND CATEGORIES

IA-32 processors are referred to in several different ways in this chapter, depending on the type of compatibility

information being related, as described in the following:

•

IA-32 Processors - All the Intel processors based on the Intel IA-32 Architecture, which include the

8086/88, Intel 286, Intel386, Intel486, Pentium, Pentium Pro, Pentium II, Pentium III, Pentium 4, and Intel

Xeon processors.

•

32-bit Processors - All the IA-32 processors that use a 32-bit architecture, which include the Intel386,

Intel486, Pentium, Pentium Pro, Pentium II, Pentium III, Pentium 4, and Intel Xeon processors.

•

16-bit Processors - All the IA-32 processors that use a 16-bit architecture, which include the 8086/88 and

Intel 286 processors.

•

P6 Family Processors - All the IA-32 processors that are based on the P6 microarchitecture, which include

the Pentium Pro, Pentium II, and Pentium III processors.

•

Pentium^® 4 Processors - A family of IA-32 and Intel 64 processors that are based on the Intel NetBurst^®

microarchitecture.

•

Intel^® Pentium^® M Processors - A family of IA-32 processors that are based on the Intel Pentium M

processor microarchitecture.

•

Intel^® Core™ Duo and Solo Processors - Families of IA-32 processors that are based on an improved Intel

Pentium M processor microarchitecture.

•

Intel^® Xeon^® Processors - A family of IA-32 and Intel 64 processors that are based on the Intel NetBurst

microarchitecture. This family includes the Intel Xeon processor and the Intel Xeon processor MP based on the

Intel NetBurst microarchitecture. Intel Xeon processors 3000, 3100, 3200, 3300, 3200, 5100, 5200, 5300,

5400, 7200, 7300 series are based on Intel Core microarchitectures and support Intel 64 architecture.

•

Pentium^® D Processors - A family of dual-core Intel 64 processors that provides two processor cores in a

physical package. Each core is based on the Intel NetBurst microarchitecture.

•

Pentium^® Processor Extreme Editions - A family of dual-core Intel 64 processors that provides two

processor cores in a physical package. Each core is based on the Intel NetBurst microarchitecture and supports

Intel Hyper-Threading Technology.

•

Intel^® Core™ 2 Processor family- A family of Intel 64 processors that are based on the Intel Core microar-

chitecture. Intel Pentium Dual-Core processors are also based on the Intel Core microarchitecture.

•

Intel Atom^® Processors - A family of IA-32 and Intel 64 processors. 45 nm Intel Atom processors are based

on the Intel Atom microarchitecture. 32 nm Intel Atom processors are based on newer microarchitectures

including the Silvermont microarchitecture and the Airmont microarchitecture. Each generation of Intel Atom

processors can be identified by the CPUID’s DisplayFamily_DisplayModel signature; see Table 2-1 “CPUID

Signature Values of DisplayFamily_DisplayModel” in Chapter 2, “Model-Specific Registers (MSRs),” of the Intel^®

64 and IA-32 Architectures Software Developer’s Manual, Volume 4.

Vol. 3B

23-1

ARCHITECTURE COMPATIBILITY

23.2

RESERVED BITS

Throughout this manual, certain bits are marked as reserved in many register and memory layout descriptions.

When bits are marked as undefined or reserved, it is essential for compatibility with future processors that software

treat these bits as having a future, though unknown effect. Software should follow these guidelines in dealing with

reserved bits:

• Do not depend on the states of any reserved bits when testing the values of registers or memory locations that

contain such bits. Mask out the reserved bits before testing.

• Do not depend on the states of any reserved bits when storing them to memory or to a register.

• Do not depend on the ability to retain information written into any reserved bits.

• When loading a register, always load the reserved bits with the values indicated in the documentation, if any, or

reload them with values previously read from the same register.

Software written for existing IA-32 processor that handles reserved bits correctly will port to future IA-32 proces-

sors without generating protection exceptions.

23.3

ENABLING NEW FUNCTIONS AND MODES

Most of the new control functions defined for the P6 family and Pentium processors are enabled by new mode flags

in the control registers (primarily register CR4). This register is undefined for IA-32 processors earlier than the

Pentium processor. Attempting to access this register with an Intel486 or earlier IA-32 processor results in an

invalid-opcode exception (#UD). Consequently, programs that execute correctly on the Intel486 or earlier IA-32

processor cannot erroneously enable these functions. Attempting to set a reserved bit in register CR4 to a value

other than its original value results in a general-protection exception (#GP). So, programs that execute on the P6

family and Pentium processors cannot erroneously enable functions that may be implemented in future IA-32

processors.

The P6 family and Pentium processors do not check for attempts to set reserved bits in model-specific registers;

however these bits may be checked on more recent processors. It is the obligation of the software writer to enforce

this discipline. These reserved bits may be used in future Intel processors.

23.4

DETECTING THE PRESENCE OF NEW FEATURES THROUGH SOFTWARE

Software can check for the presence of new architectural features and extensions in either of two ways:

1. Test for the presence of the feature or extension. Software can test for the presence of new flags in the EFLAGS

test), an exception is generated. Likewise, software can attempt to execute a new instruction, which results in

an invalid-opcode exception (#UD) being generated if it is not supported.

2. Execute the CPUID instruction. The CPUID instruction (added to the IA-32 in the Pentium processor) indicates

the presence of new features directly.

See Chapter 20, “Processor Identification and Feature Determination,” in the Intel^® 64 and IA-32 Architectures

Software Developer’s Manual, Volume 1, for detailed information on detecting new processor features and exten-

sions.

23.5

INTEL MMX TECHNOLOGY

The Pentium processor with MMX technology introduced the MMX technology and a set of MMX instructions to the

IA-32. The MMX instructions are described in Chapter 9, “Programming with Intel® MMX™ Technology,” in the

Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, and in the Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D. The MMX technology and MMX instructions are

also included in the Pentium II, Pentium III, Pentium 4, and Intel Xeon processors.

23-2

Vol. 3B

ARCHITECTURE COMPATIBILITY

23.6

STREAMING SIMD EXTENSIONS (SSE)

The Streaming SIMD Extensions (SSE) were introduced in the Pentium III processor. The SSE extensions consist of

a new set of instructions and a new set of registers. The new registers include the eight 128-bit XMM registers and

the 32-bit MXCSR control and status register. These instructions and registers are designed to allow SIMD compu-

tations to be made on single precision floating-point numbers. Several of these new instructions also operate in the

MMX registers. SSE instructions and registers are described in Section 10, “Programming with Intel® Streaming

SIMD Extensions (Intel® SSE),” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1,

and in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D.

23.7

STREAMING SIMD EXTENSIONS 2 (SSE2)

The Streaming SIMD Extensions 2 (SSE2) were introduced in the Pentium 4 and Intel Xeon processors. They

consist of a new set of instructions that operate on the XMM and MXCSR registers and perform SIMD operations on

double precision floating-point values and on integer values. Several of these new instructions also operate in the

MMX registers. SSE2 instructions and registers are described in Chapter 11, “Programming with Intel® Streaming

SIMD Extensions 2 (Intel® SSE2),” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume

1, and in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D.

23.8

STREAMING SIMD EXTENSIONS 3 (SSE3)

The Streaming SIMD Extensions 3 (SSE3) were introduced in Pentium 4 processors supporting Intel Hyper-

Threading Technology and Intel Xeon processors. SSE3 extensions include 13 instructions. Ten of these 13 instruc-

tions support the single instruction multiple data (SIMD) execution model used with SSE/SSE2 extensions. One

SSE3 instruction accelerates x87 style programming for conversion to integer. The remaining two instructions

(MONITOR and MWAIT) accelerate synchronization of threads. SSE3 instructions are described in Chapter 12,

“Programming with Intel® SSE3, SSSE3, Intel® SSE4, and Intel® AES-NI,” in the Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volume 1, and in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volumes 2A, 2B, 2C, & 2D.

23.9

ADDITIONAL STREAMING SIMD EXTENSIONS

The Supplemental Streaming SIMD Extensions 3 (SSSE3) were introduced in the Intel Core 2 processor and Intel

Xeon processor 5100 series. Streaming SIMD Extensions 4 provided 54 new instructions introduced in 45 nm Intel

Xeon processors and Intel Core 2 processors. SSSE3, SSE4.1 and SSE4.2 instructions are described in Chapter 12,

“Programming with Intel® SSE3, SSSE3, Intel® SSE4, and Intel® AES-NI,” in the Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volume 1, and in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volumes 2A, 2B, 2C, & 2D.

23.10 INTEL HYPER-THREADING TECHNOLOGY

Intel Hyper-Threading Technology provides two logical processors that can execute two separate code streams

(called threads) concurrently by using shared resources in a single processor core or in a physical package.

This feature was introduced in the Intel Xeon processor MP and later steppings of the Intel Xeon processor, and

Pentium 4 processors supporting Intel Hyper-Threading Technology. The feature is also found in the Pentium

processor Extreme Edition. See also: Section 9.7, “Intel® Hyper-Threading Technology Architecture.”

45 nm and 32 nm Intel Atom processors support Intel Hyper-Threading Technology.

Intel Atom processors based on Silvermont and Airmont microarchitectures do not support Intel Hyper-Threading

Technology.

Vol. 3B

23-3

ARCHITECTURE COMPATIBILITY

23.11 MULTI-CORE TECHNOLOGY

The Pentium D processor and Pentium processor Extreme Edition provide two processor cores in each physical

processor package. See also: Section 9.5, “Intel® Hyper-Threading Technology and Intel® Multi-Core Technology,”

and Section 9.8, “Multi-Core Architecture.” Intel Core 2 Duo, Intel Pentium Dual-Core processors, Intel Xeon

processors 3000, 3100, 5100, 5200 series provide two processor cores in each physical processor package. Intel

Core 2 Extreme, Intel Core 2 Quad processors, Intel Xeon processors 3200, 3300, 5300, 5400, 7300 series provide

two processor cores in each physical processor package.

23.12 SPECIFIC FEATURES OF DUAL-CORE PROCESSOR

Dual-core processors may have some processor-specific features. Use CPUID feature flags to detect the availability

features. Note the following:

• CPUID Brand String - On Pentium processor Extreme Edition, the process will report the correct brand string

only after the correct microcode updates are loaded.

• Enhanced Intel SpeedStep Technology - This feature is supported in Pentium D processor but not in

Pentium processor Extreme Edition.

23.13 NEW INSTRUCTIONS IN THE PENTIUM AND LATER IA-32 PROCESSORS

Table 23-1 identifies the instructions introduced into the IA-32 in the Pentium processor and later IA-32 processors.

23.13.1 Instructions Added Prior to the Pentium Processor

The following instructions were added in the Intel486 processor:

• BSWAP (byte swap) instruction.

• XADD (exchange and add) instruction.

• CMPXCHG (compare and exchange) instruction.

• ΙNVD (invalidate cache) instruction.

• WBINVD (write-back and invalidate cache) instruction.

• INVLPG (invalidate TLB entry) instruction.

Table 23-1. New Instruction in the Pentium Processor and Later IA-32 Processors

Instruction

CPUID Identification Bits

Introduced In

CMOVcc (conditional move)

EDX, Bit 15

Pentium Pro processor

FCMOVcc (floating-point conditional move)

EDX, Bits 0 and 15

FCOMI (floating-point compare and set EFLAGS)

EDX, Bits 0 and 15

RDPMC (read performance monitoring counters)

EAX, Bits 8-11, set to 6H;

see Note 1

UD2 (undefined)

EAX, Bits 8-11, set to 6H

23-4

Vol. 3B

ARCHITECTURE COMPATIBILITY

Table 23-1. New Instruction in the Pentium Processor and Later IA-32 Processors (Contd.)

Instruction

CPUID Identification Bits

Introduced In

CMPXCHG8B (compare and exchange 8 bytes)

EDX, Bit 8

Pentium processor

CPUID (CPU identification)

None; see Note 2

RDTSC (read time-stamp counter)

EDX, Bit 4

RDMSR (read model-specific register)

EDX, Bit 5

WRMSR (write model-specific register)

EDX, Bit 5

MMX Instructions

EDX, Bit 23

NOTES:

1. The RDPMC instruction was introduced in the P6 family of processors and added to later model Pentium processors. This instruc-

tion is model specific in nature and not architectural.

2. The CPUID instruction is available in all Pentium and P6 family processors and in later models of the Intel486 processors. The ability

to set and clear the ID flag (bit 21) in the EFLAGS register indicates the availability of the CPUID instruction.

The following instructions were added in the Intel386 processor:

• LSS, LFS, and LGS (load SS, FS, and GS registers).

• Long-displacement conditional jumps.

• Single-bit instructions.

• Bit scan instructions.

• Double-shift instructions.

• Byte set on condition instruction.

• Move with sign/zero extension.

• Generalized multiply instruction.

• MOV to and from control registers.

• MOV to and from test registers (now obsolete).

• MOV to and from debug registers.

• RSM (resume from SMM). This instruction was introduced in the Intel386 SL and Intel486 SL processors.

The following instructions were added in the Intel 387 math coprocessor:

• FPREM1.

• FUCOM, FUCOMP, and FUCOMPP.

23.14 OBSOLETE INSTRUCTIONS

The MOV to and from test registers instructions were removed from the Pentium processor and future IA-32

processors. Execution of these instructions generates an invalid-opcode exception (#UD).

23.15 UNDEFINED OPCODES

All new instructions defined for Intel 64 and IA-32 processors use binary encodings that were reserved on earlier-

generation processors. Generally, attempting to execute a reserved opcode results in an invalid-opcode (#UD)

exception being generated. Consequently, programs that execute correctly on earlier-generation processors

cannot erroneously execute these instructions and thereby produce unexpected results when executed on later

Intel 64 processors.

For compatibility with prior generations, there are a few reserved opcodes which do not result in a #UD but rather

result in the same behavior as certain defined instructions. In the interest of standardization, it is recommended

Vol. 3B

23-5

ARCHITECTURE COMPATIBILITY

that software not use the opcodes given below but instead use those defined in the Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D.

The following items enumerate those reserved opcodes (referring in some cases to opcode groups as defined in

Appendix A, “Opcode Map,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2D).

• Immediate Group 1 - When not in 64-bit mode, instructions encoded with opcode 82H result in the behavior

of the corresponding instructions encoded with opcode 80H. Depending on the Op/Reg field of the ModR/M

Byte, these opcodes are the byte forms of ADD, OR, ADC, SBB, AND, SUB, XOR, CMP. (In 64-bit mode, these

opcodes cause a #UD.)

• Shift Group 2 /6 - Instructions encoded with opcodes C0H, C1H, D0H, D1H, D2H, and D3H with value 110B in

the Op/Reg field (/6) of the ModR/M Byte result in the behavior of the corresponding instructions with value

100B in the Op/Reg field (/4). These are various forms of the SAL/SHL instruction.

• Unary Group 3 /1 - Instructions encoded with opcodes F6H and F7H with value 001B in the Op/Reg field (/01)

of the ModR/M Byte result in the behavior of the corresponding instructions with value 000B in the Op/Reg field

(/0). These are various forms of the TEST instruction.

• Reserved NOP - Instructions encoded with the opcode 0F0DH or with the opcodes 0F18H through 0F1FH

result in the behavior of the NOP (No Operation) instruction, except for those opcodes defined in the Intel^® 64

and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D. The opcodes not so defined

are considered “Reserved NOP” and may be used for future instructions which have no defined impact on

existing architectural state. These reserved NOP opcodes are decoded with a ModR/M byte and typical

instruction prefix options but still result in the behavior of the NOP instruction.

• x87 Opcodes - There are several groups of x87 opcodes which provide the same behavior as other x87

instructions. See Section 23.18.9 for the complete list.

There are a few reserved opcodes that provide unique behavior but do not provide capabilities that are not already

available in the main instructions defined in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volumes 2A, 2B, 2C, & 2D.

• D6H - When not in 64-bit mode SALC - Set AL to Cary flag. IF (CF=1), AL=FF, ELSE, AL=0 (#UD in 64-bit

mode)

• x87 Opcodes - There are a few x87 opcodes with subtly different behavior from existing x87 instructions. See

Section 23.18.9 for details.

23.16 NEW FLAGS IN THE EFLAGS REGISTER

The section titled “EFLAGS Register” in Chapter 3, “Basic Execution Environment,” of the Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volume 1, shows the configuration of flags in the EFLAGS register for the P6

family processors. No new flags have been added to this register in the P6 family processors. The flags added to

this register in the Pentium and Intel486 processors are described in the following sections.

The following flags were added to the EFLAGS register in the Pentium processor:

• VIF (virtual interrupt flag), bit 19.

• VIP (virtual interrupt pending), bit 20.

• ID (identification flag), bit 21.

The AC flag (bit 18) was added to the EFLAGS register in the Intel486 processor.

23.16.1 Using EFLAGS Flags to Distinguish Between 32-Bit IA-32 Processors

The following bits in the EFLAGS register that can be used to differentiate between the 32-bit IA-32 processors:

• Bit 18 (the AC flag) can be used to distinguish an Intel386 processor from the P6 family, Pentium, and Intel486

processors. Since it is not implemented on the Intel386 processor, it will always be clear.

• Bit 21 (the ID flag) indicates whether an application can execute the CPUID instruction. The ability to set and

clear this bit indicates that the processor is a P6 family or Pentium processor. The CPUID instruction can then

be used to determine which processor.

23-6

Vol. 3B

ARCHITECTURE COMPATIBILITY

• Bits 19 (the VIF flag) and 20 (the VIP flag) will always be zero on processors that do not support virtual mode

extensions, which includes all 32-bit processors prior to the Pentium processor.

See Chapter 20, “Processor Identification and Feature Determination,” in the Intel^® 64 and IA-32 Architectures

Software Developer’s Manual, Volume 1, for more information on identifying processors.

23.17 STACK OPERATIONS AND USER SOFTWARE

This section identifies the differences in stack implementation between the various IA-32 processors.

23.17.1 PUSH SP

The P6 family, Pentium, Intel486, Intel386, and Intel 286 processors push a different value on the stack for a PUSH

SP instruction than the 8086 processor. The 32-bit processors push the value of the SP register before it is decre-

mented as part of the push operation; the 8086 processor pushes the value of the SP register after it is decre-

mented. If the value pushed is important, replace PUSH SP instructions with the following three instructions:

PUSH BP

MOV BP, SP

XCHG BP, [BP]

This code functions as the 8086 processor PUSH SP instruction on the P6 family, Pentium, Intel486, Intel386, and

Intel 286 processors.

23.17.2 EFLAGS Pushed on the Stack

The setting of the stored values of bits 12 through 15 (which includes the IOPL field and the NT flag) in the EFLAGS

than with the 8086 and Intel 286 processors. The differences are as follows:

•

8086 processor-bits 12 through 15 are always set.

• Intel 286 processor-bits 12 through 15 are always cleared in real-address mode.

•

32-bit processors in real-address mode-bit 15 (reserved) is always cleared, and bits 12 through 14 have the

last value loaded into them.

23.18 X87 FPU

This section addresses the issues that must be faced when porting floating-point software designed to run on

earlier IA-32 processors and math coprocessors to a Pentium 4, Intel Xeon, P6 family, or Pentium processor with

integrated x87 FPU. To software, a Pentium 4, Intel Xeon, or P6 family processor looks very much like a Pentium

processor. Floating-point software which runs on a Pentium or Intel486 DX processor, or on an Intel486 SX

processor/Intel 487 SX math coprocessor system or an Intel386 processor/Intel 387 math coprocessor system,

will run with at most minor modifications on a Pentium 4, Intel Xeon, or P6 family processor. To port code directly

from an Intel 286 processor/Intel 287 math coprocessor system or an Intel 8086 processor/8087 math copro-

cessor system to a Pentium 4, Intel Xeon, P6 family, or Pentium processor, certain additional issues must be

addressed.

In the following sections, the term “32-bit x87 FPUs” refers to the P6 family, Pentium, and Intel486 DX processors,

and to the Intel 487 SX and Intel 387 math coprocessors; the term “16-bit IA-32 math coprocessors” refers to the

Intel 287 and 8087 math coprocessors.

Vol. 3B

23-7

ARCHITECTURE COMPATIBILITY

23.18.1 Control Register CR0 Flags

The ET, NE, and MP flags in control register CR0 control the interface between the integer unit of an IA-32 processor

and either its internal x87 FPU or an external math coprocessor. The effect of these flags in the various IA-32

processors are described in the following paragraphs.

The ET (extension type) flag (bit 4 of the CR0 register) is used in the Intel386 processor to indicate whether the

math coprocessor in the system is an Intel 287 math coprocessor (flag is clear) or an Intel 387 DX math copro-

cessor (flag is set). This bit is hardwired to 1 in the P6 family, Pentium, and Intel486 processors.

The NE (Numeric Exception) flag (bit 5 of the CR0 register) is used in the P6 family, Pentium, and Intel486 proces-

sors to determine whether unmasked floating-point exceptions are reported internally through interrupt vector 16

(flag is set) or externally through an external interrupt (flag is clear). On a hardware reset, the NE flag is initialized

to 0, so software using the automatic internal error-reporting mechanism must set this flag to 1. This flag is nonex-

istent on the Intel386 processor.

As on the Intel 286 and Intel386 processors, the MP (monitor coprocessor) flag (bit 1 of register CR0) determines

whether the WAIT/FWAIT instructions or waiting-type floating-point instructions trap when the context of the x87

FPU is different from that of the currently-executing task. If the MP and TS flag are set, then a WAIT/FWAIT instruc-

tion and waiting instructions will cause a device-not-available exception (interrupt vector 7). The MP flag is used on

the Intel 286 and Intel386 processors to support the use of a WAIT/FWAIT instruction to wait on a device other

than a math coprocessor. The device reports its status through the BUSY# pin. Since the P6 family, Pentium, and

Intel486 processors do not have such a pin, the MP flag has no relevant use and should be set to 1 for normal oper-

ation.

23.18.2 x87 FPU Status Word

This section identifies differences to the x87 FPU status word for the different IA-32 processors and math coproces-

sors, the reason for the differences, and their impact on software.

23.18.2.1 Condition Code Flags (C0 through C3)

The following information pertains to differences in the use of the condition code flags (C0 through C3) located in

bits 8, 9, 10, and 14 of the x87 FPU status word.

After execution of an FINIT instruction or a hardware reset on a 32-bit x87 FPU, the condition code flags are set to

0. The same operations on a 16-bit IA-32 math coprocessor leave these flags intact (they contain their prior value).

This difference in operation has no impact on software and provides a consistent state after reset.

Transcendental instruction results in the core range of the P6 family and Pentium processors may differ from the

Intel486 DX processor and Intel 487 SX math coprocessor by 2 to 3 units in the last place (ulps)-(see “Transcen-

dental Instruction Accuracy” in Chapter 8, “Programming with the x87 FPU,” of the Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volume 1). As a result, the value saved in the C1 flag may also differ.

After an incomplete FPREM/FPREM1 instruction, the C0, C1, and C3 flags are set to 0 on the 32-bit x87 FPUs. After

the same operation on a 16-bit IA-32 math coprocessor, these flags are left intact.

On the 32-bit x87 FPUs, the C2 flag serves as an incomplete flag for the FTAN instruction. On the 16-bit IA-32 math

coprocessors, the C2 flag is undefined for the FPTAN instruction. This difference has no impact on software,

because Intel 287 or 8087 programs do not check C2 after an FPTAN instruction. The use of this flag on later

processors allows fast checking of operand range.

23.18.2.2 Stack Fault Flag

When unmasked stack overflow or underflow occurs on a 32-bit x87 FPU, the IE flag (bit 0) and the SF flag (bit 6)

of the x87 FPU status word are set to indicate a stack fault and condition code flag C1 is set or cleared to indicate

overflow or underflow, respectively. When unmasked stack overflow or underflow occurs on a 16-bit IA-32 math

coprocessor, only the IE flag is set. Bit 6 is reserved on these processors. The addition of the SF flag on a 32-bit x87

FPU has no impact on software. Existing exception handlers need not change, but may be upgraded to take advan-

tage of the additional information.

23-8

Vol. 3B

ARCHITECTURE COMPATIBILITY

23.18.3 x87 FPU Control Word

Only affine closure is supported for infinity control on a 32-bit x87 FPU. The infinity control flag (bit 12 of the x87

FPU control word) remains programmable on these processors, but has no effect. This change was made to

conform to the IEEE Standard 754 for Floating-Point Arithmetic. On a 16-bit IA-32 math coprocessor, both affine

and projective closures are supported, as determined by the setting of bit 12. After a hardware reset, the default

value of bit 12 is projective. Software that requires projective infinity arithmetic may give different results.

23.18.4 x87 FPU Tag Word

When loading the tag word of a 32-bit x87 FPU, using an FLDENV, FRSTOR, or FXRSTOR (Pentium III processor only)

instruction, the processor examines the incoming tag and classifies the location only as empty or non-empty. Thus,

tag values of 00, 01, and 10 are interpreted by the processor to indicate a non-empty location. The tag value of 11

is interpreted by the processor to indicate an empty location. Subsequent operations on a non-empty register

always examine the value in the register, not the value in its tag. The FSTENV, FSAVE, and FXSAVE (Pentium III

processor only) instructions examine the non-empty registers and put the correct values in the tags before storing

the tag word.

The corresponding tag for a 16-bit IA-32 math coprocessor is checked before each register access to determine the

class of operand in the register; the tag is updated after every change to a register so that the tag always reflects

the most recent status of the register. Software can load a tag with a value that disagrees with the contents of a

coprocessors honor the tag and do not examine the register.

Software written to run on a 16-bit IA-32 math coprocessor may not operate correctly on a 16-bit x87 FPU, if it

uses the FLDENV, FRSTOR, or FXRSTOR instructions to change tags to values (other than to empty) that are

different from actual register contents.

The encoding in the tag word for the 32-bit x87 FPUs for unsupported data formats (including pseudo-zero and

unnormal) is special (10B), to comply with IEEE Standard 754. The encoding in the 16-bit IA-32 math coprocessors

for pseudo-zero and unnormal is valid (00B) and the encoding for other unsupported data formats is special (10B).

Code that recognizes the pseudo-zero or unnormal format as valid must therefore be changed if it is ported to a 32-

bit x87 FPU.

23.18.5 Data Types

This section discusses the differences of data types for the various x87 FPUs and math coprocessors.

23.18.5.1 NaNs

The 32-bit x87 FPUs distinguish between signaling NaNs (SNaNs) and quiet NaNs (QNaNs). These x87 FPUs only

generate QNaNs and normally do not generate an exception upon encountering a QNaN. An invalid-operation

exception (#I) is generated only upon encountering a SNaN, except for the FCOM, FIST, and FBSTP instructions,

which also generates an invalid-operation exceptions for a QNaNs. This behavior matches IEEE Standard 754.

The 16-bit IA-32 math coprocessors only generate one kind of NaN (the equivalent of a QNaN), but the raise an

invalid-operation exception upon encountering any kind of NaN.

When porting software written to run on a 16-bit IA-32 math coprocessor to a 32-bit x87 FPU, uninitialized memory

locations that contain QNaNs should be changed to SNaNs to cause the x87 FPU or math coprocessor to fault when

uninitialized memory locations are referenced.

23.18.5.2 Pseudo-zero, Pseudo-NaN, Pseudo-infinity, and Unnormal Formats

The 32-bit x87 FPUs neither generate nor support the pseudo-zero, pseudo-NaN, pseudo-infinity, and unnormal

formats. Whenever they encounter them in an arithmetic operation, they raise an invalid-operation exception. The

16-bit IA-32 math coprocessors define and support special handling for these formats. Support for these formats

was dropped to conform with IEEE Standard 754 for Floating-Point Arithmetic.

Vol. 3B

23-9

ARCHITECTURE COMPATIBILITY

This change should not impact software ported from 16-bit IA-32 math coprocessors to 32-bit x87 FPUs. The 32-

bit x87 FPUs do not generate these formats, and therefore will not encounter them unless software explicitly loads

them in the data registers. The only affect may be in how software handles the tags in the tag word (see also:

Section 23.18.4, “x87 FPU Tag Word”).

23.18.6 Floating-Point Exceptions

This section identifies the implementation differences in exception handling for floating-point instructions in the

various x87 FPUs and math coprocessors.

23.18.6.1 Denormal Operand Exception (#D)

When the denormal operand exception is masked, the 32-bit x87 FPUs automatically normalize denormalized

numbers when possible; whereas, the 16-bit IA-32 math coprocessors return a denormal result. A program written

to run on a 16-bit IA-32 math coprocessor that uses the denormal exception solely to normalize denormalized

operands is redundant when run on the 32-bit x87 FPUs. If such a program is run on 32-bit x87 FPUs, performance

can be improved by masking the denormal exception. Floating-point programs run faster when the FPU performs

normalization of denormalized operands.

The denormal operand exception is not raised for transcendental instructions and the FXTRACT instruction on the

16-bit IA-32 math coprocessors. This exception is raised for these instructions on the 32-bit x87 FPUs. The excep-

tion handlers ported to these latter processors need to be changed only if the handlers gives special treatment to

different opcodes.

23.18.6.2 Numeric Overflow Exception (#O)

On the 32-bit x87 FPUs, when the numeric overflow exception is masked and the rounding mode is set to chop

(toward 0), the result is the largest positive or smallest negative number. The 16-bit IA-32 math coprocessors do

not signal the overflow exception when the masked response is not ∞; that is, they signal overflow only when the

rounding control is not set to round to 0. If rounding is set to chop (toward 0), the result is positive or negative ∞.

Under the most common rounding modes, this difference has no impact on existing software.

If rounding is toward 0 (chop), a program on a 32-bit x87 FPU produces, under overflow conditions, a result that is

different in the least significant bit of the significand, compared to the result on a 16-bit IA-32 math coprocessor.

The reason for this difference is IEEE Standard 754 compatibility.

When the overflow exception is not masked, the precision exception is flagged on the 32-bit x87 FPUs. When the

result is stored in the stack, the significand is rounded according to the precision control (PC) field of the FPU

control word or according to the opcode. On the 16-bit IA-32 math coprocessors, the precision exception is not

flagged and the significand is not rounded. The impact on existing software is that if the result is stored on the

stack, a program running on a 32-bit x87 FPU produces a different result under overflow conditions than on a 16-

bit IA-32 math coprocessor. The difference is apparent only to the exception handler. This difference is for IEEE

Standard 754 compatibility.

23.18.6.3 Numeric Underflow Exception (#U)

When the underflow exception is masked on the 32-bit x87 FPUs, the underflow exception is signaled when the

result is tiny and inexact (see Section 4.9.1.5, “Numeric Underflow Exception (#U),” in Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volume 1). When the underflow exception is unmasked and the instruction

is supposed to store the result on the stack, the significand is rounded to the appropriate precision (according to

the PC flag in the FPU control word, for those instructions controlled by PC, otherwise to extended precision), after

adjusting the exponent.

23.18.6.4 Exception Precedence

There is no difference in the precedence of the denormal-operand exception on the 32-bit x87 FPUs, whether it be

masked or not. When the denormal-operand exception is not masked on the 16-bit IA-32 math coprocessors, it

takes precedence over all other exceptions. This difference causes no impact on existing software, but some

23-10

Vol. 3B

ARCHITECTURE COMPATIBILITY

unneeded normalization of denormalized operands is prevented on the Intel486 processor and Intel 387 math

coprocessor.

23.18.6.5 CS and EIP For FPU Exceptions

On the Intel 32-bit x87 FPUs, the values from the CS and EIP registers saved for floating-point exceptions point to

any prefixes that come before the floating-point instruction. On the 8087 math coprocessor, the saved CS and IP

registers points to the floating-point instruction.

23.18.6.6 FPU Error Signals

The floating-point error signals to the P6 family, Pentium, and Intel486 processors do not pass through an interrupt

controller; an INT# signal from an Intel 387, Intel 287 or 8087 math coprocessors does. If an 8086 processor uses

another exception for the 8087 interrupt, both exception vectors should call the floating-point-error exception

handler. Some instructions in a floating-point-error exception handler may need to be deleted if they use the inter-

rupt controller. The P6 family, Pentium, and Intel486 processors have signals that, with the addition of external

logic, support reporting for emulation of the interrupt mechanism used in many personal computers.

On the P6 family, Pentium, and Intel486 processors, an undefined floating-point opcode will cause an invalid-

opcode exception (#UD, interrupt vector 6). Undefined floating-point opcodes, like legal floating-point opcodes,

cause a device not available exception (#NM, interrupt vector 7) when either the TS or EM flag in control register

CR0 is set. The P6 family, Pentium, and Intel486 processors do not check for floating-point error conditions on

encountering an undefined floating-point opcode.

23.18.6.7 Assertion of the FERR# Pin

When using the MS-DOS compatibility mode for handing floating-point exceptions, the FERR# pin must be

connected to an input to an external interrupt controller. An external interrupt is then generated when the FERR#

output drives the input to the interrupt controller and the interrupt controller in turn drives the INTR pin on the

processor.

For the P6 family and Intel386 processors, an unmasked floating-point exception always causes the FERR# pin to

be asserted upon completion of the instruction that caused the exception. For the Pentium and Intel486 proces-

sors, an unmasked floating-point exception may cause the FERR# pin to be asserted either at the end of the

instruction causing the exception or immediately before execution of the next floating-point instruction. (Note that

the next floating-point instruction would not be executed until the pending unmasked exception has been

handled.) See Appendix D, “Guidelines for Writing SIMD Floating-Point Exception Handlers,” in the Intel^® 64 and

IA-32 Architectures Software Developer’s Manual, Volume 1, for a complete description of the required mechanism

for handling floating-point exceptions using the MS-DOS compatibility mode.

Using FERR# and IGNNE# to handle floating-point exception is deprecated by modern operating systems; this

approach also limits newer processors to operate with one logical processor active.

23.18.6.8 Invalid Operation Exception On Denormals

An invalid-operation exception is not generated on the 32-bit x87 FPUs upon encountering a denormal value when

executing a FSQRT, FDIV, or FPREM instruction or upon conversion to BCD or to integer. The operation proceeds by

first normalizing the value. On the 16-bit IA-32 math coprocessors, upon encountering this situation, the invalid-

operation exception is generated. This difference has no impact on existing software. Software running on the 32-

bit x87 FPUs continues to execute in cases where the 16-bit IA-32 math coprocessors trap. The reason for this

change was to eliminate an exception from being raised.

23.18.6.9 Alignment Check Exceptions (#AC)

If alignment checking is enabled, a misaligned data operand on the P6 family, Pentium, and Intel486 processors

causes an alignment check exception (#AC) when a program or procedure is running at privilege-level 3, except

for the stack portion of the FSAVE/FNSAVE, FXSAVE, FRSTOR, and FXRSTOR instructions.

Vol. 3B

23-11

ARCHITECTURE COMPATIBILITY

23.18.6.10 Segment Not Present Exception During FLDENV

On the Intel486 processor, when a segment not present exception (#NP) occurs in the middle of an FLDENV

instruction, it can happen that part of the environment is loaded and part not. In such cases, the FPU control word

is left with a value of 007FH. The P6 family and Pentium processors ensure the internal state is correct at all times

by attempting to read the first and last bytes of the environment before updating the internal state.

23.18.6.11 Device Not Available Exception (#NM)

The device-not-available exception (#NM, interrupt 7) will occur in the P6 family, Pentium, and Intel486 processors

as described in Section 2.5, “Control Registers,” Table 2-2, and Chapter 6, “Interrupt 7-Device Not Available

Exception (#NM).”

23.18.6.12 Coprocessor Segment Overrun Exception

The coprocessor segment overrun exception (interrupt 9) does not occur in the P6 family, Pentium, and Intel486

processors. In situations where the Intel 387 math coprocessor would cause an interrupt 9, the P6 family, Pentium,

and Intel486 processors simply abort the instruction. To avoid undetected segment overruns, it is recommended

that the floating-point save area be placed in the same page as the TSS. This placement will prevent the FPU envi-

ronment from being lost if a page fault occurs during the execution of an FLDENV, FRSTOR, or FXRSTOR instruction

while the operating system is performing a task switch.

23.18.6.13 General Protection Exception (#GP)

A general-protection exception (#GP, interrupt 13) occurs if the starting address of a floating-point operand falls

outside a segment’s size. An exception handler should be included to report these programming errors.

23.18.6.14 Floating-Point Error Exception (#MF)

In real mode and protected mode (not including virtual-8086 mode), interrupt vector 16 must point to the floating-

point exception handler. In virtual-8086 mode, the virtual-8086 monitor can be programmed to accommodate a

different location of the interrupt vector for floating-point exceptions.

23.18.7 Changes to Floating-Point Instructions

This section identifies the differences in floating-point instructions for the various Intel FPU and math coprocessor

architectures, the reason for the differences, and their impact on software.

23.18.7.1 FDIV, FPREM, and FSQRT Instructions

The 32-bit x87 FPUs support operations on denormalized operands and, when detected, an underflow exception

can occur, for compatibility with the IEEE Standard 754. The 16-bit IA-32 math coprocessors do not operate on

denormalized operands or return underflow results. Instead, they generate an invalid-operation exception when

they detect an underflow condition. An existing underflow exception handler will require change only if it gives

different treatment to different opcodes. Also, it is possible that fewer invalid-operation exceptions will occur.

23.18.7.2 FSCALE Instruction

With the 32-bit x87 FPUs, the range of the scaling operand is not restricted. If (0 < | ST(1) < 1), the scaling factor

is 0; therefore, ST(0) remains unchanged. If the rounded result is not exact or if there was a loss of accuracy

(masked underflow), the precision exception is signaled. With the 16-bit IA-32 math coprocessors, the range of the

scaling operand is restricted. If (0 < | ST(1) | < 1), the result is undefined and no exception is signaled. The

impact of this difference on exiting software is that different results are delivered on the 32-bit and 16-bit FPUs and

math coprocessors when (0 < | ST(1) | < 1).

23-12

Vol. 3B

Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 5