Content      ..     58      59      60      61     ..

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

PERFORMANCE MONITORING

20.7.3 Determining the Processor Base Frequency

For Intel processors in which the nominal core crystal clock frequency is enumerated in CPUID.15H.ECX and the

core crystal clock ratio is encoded in CPUID.15H (see Table 3-8 “Information Returned by CPUID Instruction”), the

nominal TSC frequency can be determined by using the following equation:

Nominal TSC frequency = ( CPUID.15H.ECX[31:0] * CPUID.15H.EBX[31:0] ) ÷ CPUID.15H.EAX[31:0]

For Intel processors in which CPUID.15H.EBX[31:0] ÷ CPUID.0x15.EAX[31:0] is enumerated but CPUID.15H.ECX

is not enumerated, Table 20-91 can be used to look up the nominal core crystal clock frequency.

Table 20-91. Nominal Core Crystal Clock Frequency

Processor Families/Processor Number Series¹

Nominal Core Crystal Clock Frequency

Intel® Xeon® Scalable Processor Family with CPUID signature 06_55H.

25 MHz

6th and 7th generation Intel® Core™ processors and Intel® Xeon® W Processor Family.

24 MHz

Next Generation Intel Atom® processors based on Goldmont Microarchitecture with

19.2 MHz

CPUID signature 06_5CH (does not include Intel Xeon processors).

NOTES:

1. For any processor in which CPUID.15H is enumerated and MSR_PLATFORM_INFO[15:8] (which gives the scalable bus frequency) is

available, a more accurate frequency can be obtained by using CPUID.15H.

20.7.3.1 For Intel® Processors Based on Sandy Bridge, Ivy Bridge, Haswell, and Broadwell

Microarchitectures

The scalable bus frequency is encoded in the bit field MSR_PLATFORM_INFO[15:8] and the nominal TSC frequency

can be determined by multiplying this number by a bus speed of 100 MHz.

20.7.3.2 For Intel® Processors Based on Nehalem Microarchitecture

The scalable bus frequency is encoded in the bit field MSR_PLATFORM_INFO[15:8] and the nominal TSC frequency

can be determined by multiplying this number by a bus speed of 133.33 MHz.

20.7.3.3 For Intel Atom® Processors Based on Silvermont Microarchitecture (Including Intel Processors

Based on Airmont Microarchitecture)

The scalable bus frequency is encoded in the bit field MSR_PLATFORM_INFO[15:8] and the nominal TSC frequency

can be determined by multiplying this number by the scalable bus frequency. The scalable bus frequency is

encoded in the bit field MSR_FSB_FREQ[2:0] for Intel Atom processors based on the Silvermont microarchitecture,

and in bit field MSR_FSB_FREQ[3:0] for processors based on the Airmont microarchitecture; see Chapter 2,

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

4.

20.7.3.4 For Intel® Core™ 2 Processor Family and for Intel® Xeon® Processors Based on Intel Core

Microarchitecture

For processors based on Intel Core microarchitecture, the scalable bus frequency is encoded in the bit field

MSR_FSB_FREQ[2:0] at (0CDH), see Chapter 2, “Model-Specific Registers (MSRs)‚” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 4. The maximum resolved bus ratio can be read from the

following bit field:

• If XE operation is disabled, the maximum resolved bus ratio can be read in MSR_PLATFORM_ID[12:8]. It

corresponds to the Processor Base frequency.

20-140

Vol. 3B

PERFORMANCE MONITORING

63

16 15

13 12

11

8

7 6

5 4 3 2 1 0

PEBS_OUTPUT_PT_AVAIL (R/O)

PERF_METRICS_AVAILABLE (R/O)

FW_WRITE (R/O)

SMM_FREEZE (R/O)

PEBS_REC_FMT (R/O)

PEBS_ARCH _REG (R/O)

PEBS_TRAP (R/O)

LBR_FMT (R/O)

Reserved

Figure 20-65. Layout of IA32_PERF_CAPABILITIES MSR

20.8.1 Filtering of SMM Handler Overhead

When performance monitoring facilities and/or branch profiling facilities (see Section 18.5, “Last Branch, Interrupt,

and Exception Recording (Intel® Core™ 2 Duo and Intel Atom® Processors)”) are enabled, these facilities capture

event counts, branch records and branch trace messages occurring in a logical processor. The occurrence of inter-

rupts, instruction streams due to various interrupt handlers all contribute to the results recorded by these facilities.

If CPUID.01H:ECX.PDCM[bit 15] is 1, the processor supports the IA32_PERF_CAPABILITIES MSR. If IA32_PERF_-

CAPABILITIES.FREEZE_WHILE_SMM[Bit 12] is 1, the processor supports the ability for system software using

performance monitoring and/or branch profiling facilities to filter out the effects of servicing system management

interrupts.

If the FREEZE_WHILE_SMM capability is enabled on a logical processor and after an SMI is delivered, the processor

will clear all the enable bits of IA32_PERF_GLOBAL_CTRL, save a copy of the content of IA32_DEBUGCTL and

disable LBR, BTF, TR, and BTS fields of IA32_DEBUGCTL before transferring control to the SMI handler.

The enable bits of IA32_PERF_GLOBAL_CTRL will be set to 1, the saved copy of IA32_DEBUGCTL prior to SMI

delivery will be restored , after the SMI handler issues RSM to complete its servicing.

It is the responsibility of the SMM code to ensure the state of the performance monitoring and branch profiling facil-

ities are preserved upon entry or until prior to exiting the SMM. If any of this state is modified due to actions by the

SMM code, the SMM code is required to restore such state to the values present at entry to the SMM handler.

System software is allowed to set IA32_DEBUGCTL.FREEZE_WHILE_SMM[bit 14] to 1 only supported as indicated

by IA32_PERF_CAPABILITIES.FREEZE_WHILE_SMM[Bit 12] reporting 1.

20.9

PEBS FACILITY

20.9.1 Extended PEBS

• The Extended PEBS feature supports Processor Event Based Sampling (PEBS) on all counters, both fixed

function and general purpose; and all performance monitoring events, both precise and non-precise. PEBS can

be enabled for the general purpose counters using PEBS_EN_PMCi bits of IA32_PEBS_ENABLE (i = 0, 1,..m).

PEBS can be enabled for 'i' fixed function counters using the PEBS_EN_FIXEDi bits of IA32_PEBS_ENABLE (i =

0, 1, ...n).

20-142

Vol. 3B

PERFORMANCE MONITORING

63

n

32 31

m

1 0

● ● ●

● ● ●

PEBS_EN_FIXEDn (R/W)

PEBS_EN_FIXED1 (R/W)

PEBS_EN_FIXED0 (R/W)

PEBS_EN_PMCm (R/W)

PEBS_EN_PMC1 (R/W)

PEBS_EN_PMC0 (R/W)

Reserved

RESET Value - 00000000 _00000000 H

Figure 20-66. Layout of IA32_PEBS_ENABLE MSR

A PEBS record due to a precise event will be generated after an instruction that causes the event when the counter

has already overflowed. A PEBS record due to a non-precise event will occur at the next opportunity after the

counter has overflowed, including immediately after an overflow is set by an MSR write.

Currently, IA32_FIXED_CTR0 counts instructions retired and is a precise event. IA32_FIXED_CTR1, IA32_-

FIXED_CTR2 … IA32_FIXED_CTRm count as non-precise events.

The Applicable Counter field in the Basic Info Group of the PEBS record indicates which counters caused the PEBS

record to be generated. It is in the same format as the enable bits for each counter in IA32_PEBS_ENABLE. As an

example, an Applicable Counter field with bits 2 and 32 set would indicate that both general purpose counter 2 and

fixed function counter 0 generated the PEBS record.

• To properly use PEBS for the additional counters, software will need to set up the counter reset values in PEBS

portion of the DS_BUFFER_MANAGEMENT_AREA data structure that is indicated by the IA32_DS_AREA

register. The layout of the DS_BUFFER_MANAGEMENT_AREA is shown in Figure 20-67. When a counter

generates a PEBS records, the appropriate counter reset values will be loaded into that counter. In the above

example where general purpose counter 2 and fixed function counter 0 generated the PEBS record, general

purpose counter 2 would be reloaded with the value contained in PEBS GP Counter 2 Reset (offset 50H) and

fixed function counter 0 would be reloaded with the value contained in PEBS Fixed Counter 0 Reset (offset

80H).

Vol. 3B

20-143

PERFORMANCE MONITORING

IA32_DS_AREA MSR

DS Buffer Management

BTS Buffer

63

BTS Buffer Base

0

00H

Branch Record 0

BTS Index

08H

BTS Absolute Maximum

10H

Branch Record 1

BTS Interrupt Threshold

18H

PEBS Buffer Base

20H

PEBS Index

28H

PEBS Absolute Maximum

30H

PEBS Interrupt Threshold

38H

Branch Record N

PEBS GP Counter 0 Reset

40H

PEBS GP Counter 1 Reset

●●●

PEBS Buffer

PEBS GP Counter m Reset

PEBS Record 0

PEBS Fixed Counter 0 Reset

80H

●●●

PEBS Record 1

PEBS Fixed Counter n Reset

PEBS Record N

Figure 20-67. PEBS Programming Environment

Extended PEBS support debuts on Intel Atom^® processors based on the Goldmont Plus microarchitecture and

future Intel^® Core™ processors based on the Ice Lake microarchitecture.

20.9.2 Adaptive PEBS

The PEBS facility has been enhanced to collect the following CPU state in addition to GPRs, EventingIP, TSC, and

memory access related information collected by legacy PEBS:

• XMM registers

• LBR records (TO/FROM/INFO)

The PEBS record is restructured where fields are grouped into Basic group, Memory group, GPR group, XMM group,

and LBR group. A new register MSR_PEBS_DATA_CFG provides software the capability to select data groups of

interest and thus reduce the record size in memory and record generation latency. Hence, a PEBS record's size and

layout vary based on the selected groups. The MSR also allows software to select LBR depth for branch data

records.

By default, the PEBS record will only contain the Basic group. Optionally, each counter can be configured to

generate a PEBS records with the groups specified in MSR_PEBS_DATA_CFG.

20-144

Vol. 3B

PERFORMANCE MONITORING

Details and examples for the Adaptive PEBS capability follow below.

20.9.2.1 Adaptive_Record Counter Control

• IA32_PERFEVTSELx.Adaptive_Record[34]: If this bit is set and IA32_PEBS_ENABLE.PEBS_EN_PMCx is set for

the corresponding GP counter, an overflow of PMCx results in generation of an adaptive PEBS record with state

information based on the selections made in MSR_PEBS_DATA_CFG. If this bit is not set, a basic record is

generated.

Reserved

Deprecated

31

23

15

7

0

63

55

47

39

32

IA32_PerfEvtSelX

Address Range: 0x186 to 0x18D

Scope: Thread

Reset value: 0x00000000.0000000

Figure 20-68. Layout of IA32_PerfEvtSelX MSR Supporting Adaptive PEBS

• IA32_FIXED_CTR_CTRL.FCx_Adaptive_Record: If this bit is set and IA32_PEBS_ENABLE.PEBS_EN_FIXEDx is

set for the corresponding Fixed counter, an overflow of FixedCtrx results in generation of an adaptive PEBS

record with state information based on the selections made in MSR_PEBS_DATA_CFG. If this bit is not set, a

basic record is generated.

Vol. 3B

20-145

PERFORMANCE MONITORING

Reserved

Deprecated

23

15

7

0

31

55

47

39

32

63

IA32_Fixed_CTR_CTRL

Add ress: 3 8DH

Scope: Thread

Reset value: 0 x0 000000 0.0 00000 00

Figure 20-69. Layout of IA32_FIXED_CTR_CTRL MSR Supporting Adaptive PEBS

20.9.2.2 PEBS Record Format

The data fields in the PEBS record are aggregated into five groups which are described in the sub-sections below.

Processors that support Adaptive PEBS implement a new MSR called MSR_PEBS_DATA_CFG which allows software

to select the data groups to be captured. The data groups are not placed at fixed locations in the PEBS record, but

are positioned immediately after one another, thus making the record format/size variable based on the groups

selected.

20.9.2.2.1 Basic Info

The Basic group contains essential information for software to parse a record along with several critical fields. It is

always collected.

Table 20-92. Basic Info Group

Field Name

Bit Width

Description

Record Format

[47:0]

This field indicates which data groups are included in the record. The field is zero if

none of the counters that triggered the current PEBS record have their

Adaptive_Record bit set. Otherwise it contains the value of MSR_PEBS_DATA_CFG.

[63:48]

This field provides the size of the current record in bytes. Selected groups are

packed back-to-back in the record without gaps or padding for unselected groups.

20-146

Vol. 3B

PERFORMANCE MONITORING

Table 20-92. Basic Info Group (Contd.)

Instruction Pointer

[63:0]

This field reports the Eventing Instruction Pointer (EventingIP) of the retired

instruction that triggered the PEBS record generation. Note that this field is

different than R/EIP which records the instruction pointer of the next instruction

to be executed after record generation. The legacy R/EIP field has been removed.

Applicable Counters

[63:0]

The Applicable Counters field indicates which counters triggered the generation of

the PEBS record, linking the record to specific events. This allows software to

correlate the PEBS record entry properly with the instruction that caused the

event, even when multiple counters are configured to generate PEBS records and

multiple bits are set in the field.

TSC

[63:0]

This field provides the time stamp counter value when the PEBS record was

generated.

20.9.2.2.2 Memory Access Info

This group contains the legacy PEBS memory-related fields; see Section 20.3.1.1.2.

Table 20-93. Memory Access Info Group

Field Name

Bit Width

Description

Memory Access Address

[63:0]

This field contains the linear address of the source of the load, or linear address of

the destination (target) of the store. This value is written as a 64-bit address in

canonical form.

Memory Auxiliary Info

[63:0]

When a MEM_TRANS_RETIRED.* event is configured in a General Purpose counter,

this field contains an encoded value indicating the memory hierarchy source which

satisfied the load. These encodings are detailed in Table 20-4 and Table 20-13. If

the PEBS assist was triggered for a store uop, this field will contain information

indicating the status of the store, as detailed in Table 20-14.

Memory Access Latency¹

[63:0]

When a MEM_TRANS_RETIRED.* event is configured in a General Purpose counter,

this field contains the latency to service the load in core clock cycles.

TSX Auxiliary Info

[31:0]

This field contains the number of cycles in the last TSX region, regardless of

whether that region had aborted or committed.

[63:32]

This field contains the abort details. Refer to Section 20.3.6.5.1.

NOTES:

1. In certain conditions, high latencies in fields under “Memory Access Latency” may be observed even when the Data Src of the “Mem-

ory Auxiliary Info” field indicates a close source.

Beginning with 12th generation Intel Core processors, the memory access information group has been updated.

New fields added are shaded gray in Table 20-94.

Vol. 3B

20-147

PERFORMANCE MONITORING

Table 20-94. Updated Memory Access Info Group

Field Name

Sub-field Name

Bits

Description

Access Address

DLA

[63:0]

This field reports the data linear address (DLA) of the memory access in

(offset 0H)

canonical form.

A zero value indicates the processor could not retrieve the address of the

particular access.

Access Info

Data Src

[3:0]

An encoded value indicating the memory hierarchy source which satisfied the

(offset 8H)

access. These encodings are detailed in Table 20-4.

A zero value indicates the processor could not retrieve the data source of the

particular access.

STLB-miss

[4]

A value of 1 indicates the access has missed the Second-level TLB (STLB).

Is-Lock

[5]

A value of 1 indicates the access was part of a locked (atomic) memory trans-

action.

Data-Blk

[6]

A value of 1 indicates the load was blocked since its data could not be forwarded

from a preceding store.

Address-Blk

[7]

A value of 1 indicates the load was blocked due to potential address conflict with

a preceding store.

Access Latency

Instruction

[15:0]

Measured instruction latency in core cycles.

Latency

(offset 10H)

For loads, the latency starts by the dispatch of the load operation for execution

and lasts until completion of the instruction it belongs to.

This field includes the entire latency including time for data-dependency

resolution or TLB lookups.

Cache Latency

[47:32]

Measured cache access latency in core cycles.

For loads, the latency starts by the actual cache access until the data is returned

by the memory subsystem.

For stores, the latency starts when the demand write accesses the L1 data-

cache and lasts until the cacheline write is completed in the memory subsystem.

This field does not include non-data-cache latency such as memory ordering

checks or TLB lookups.

TSX

Transaction

[31:0]

This field contains the number of cycles in the last TSX region, regardless of

Latency

whether that region had aborted or committed.

(offset 18H)

Abort Info

[63:32]

This field contains the abort details. Refer to Section 20.3.6.5.1.

To determine which fields are supported for certain performance monitoring events, consult the Memory Info attri-

bute in the event lists at https://download.01.org/perfmon/.

NOTE

There may be additional block reasons, even if Data-Blk and Address-Blk are both clear, e.g., non-

optimal instruction latency.

On P-core, the new Data-Blk and Address-Blk bits require the event LD_BLOCKS.STORE_FORWARD

(r8203) to be configured in a programmable counter.

20.9.2.2.3 GPRs

This group is captured when the GPR bit is enabled in MSR_PEBS_DATA_CFG. GPRs are always 64 bits wide. If they

are selected for non 64-bit mode, the upper 32-bit of the legacy RAX - RDI and all contents of R8-15 GPRs will be

filled with 0s. In 64bit mode, the full 64 bit value of each register is written.

20-148

Vol. 3B

PERFORMANCE MONITORING

The order differs from legacy. The table below shows the order of the GPRs in Ice Lake microarchitecture.

Table 20-95. GPRs in Ice Lake Microarchitecture

Field Name

Bit Width

RFLAGS

[63:0]

RIP

[63:0]

RAX

[63:0]

RCX*

[63:0]

RDX*

[63:0]

RBX*

[63:0]

RSP*

[63:0]

RBP*

[63:0]

RSI*

[63:0]

RDI*

[63:0]

R8

[63:0]

R15

[63:0]

The machine state reported in the PEBS record is the committed machine state immediately after the instruction

that triggers PEBS completes.

For instance, consider the following instruction sequence:

MOV eax, [eax]; triggers PEBS record generation

NOP

If the mov instruction triggers PEBS record generation, the EventingIP field in the PEBS record will report the

address of the mov, and the value of EAX in the PEBS record will show the value read from memory, not the target

address of the read operation. And the value of RIP will contain the linear address of the nop.

20.9.2.2.4 XMMs

This group is captured when the XMM bit is enabled in MSR_PEBS_DATA_CFG and SSE is enabled. If SSE is not

enabled, the fields will contain zeroes. XMM8-XMM15 will also contain zeroes if not in 64-bit mode.

Table 20-96. XMMs

Field Name

Bit Width

XMM0

[127:0]

XMM15

[127:0]

Vol. 3B

20-149

PERFORMANCE MONITORING

20.9.2.2.5 LBRs

To capture LBR data in the PEBS record, the LBR bit in MSR_PEBS_DATA_CFG must be enabled. The number of LBR

entries included in the record can be configured in the LBR_entries field of MSR_PEBS_DATA_CFG.

Table 20-97. LBRs

Field Name

Bit Width

Description

LBR[].FROM

[63:0]

Branch from address.

LBR[].TO

[63:0]

Branch to address.

LBR[].INFO

[63:0]

Other LBR information, like timing. This field is described in more

detail in Section 18.12.1, “MSR_LBR_INFO_x MSR.”

LBR entries are recorded into the record starting at LBR[TOS] and proceeding to LBR[TOS-1] and following. Note

that LBR index is modulo the number of LBRs supporting on the processor.

20.9.2.3 MSR_PEBS_DATA_CFG

Bits in MSR_PEBS_DATA_CFG can be set to include data field blocks/groups into adaptive records. The Basic Info

group is always included in the record. Additionally, the number of LBR entries included in the record is configu-

rable.

Reserved

23

15

7

31

31

55

47

39

63

63

MSR_PEBS_DATA_CFG

Address: 3F2H

Scope: Thread

Reset value : 0x00000000 .00000000

Figure 20-70. MSR_PEBS_DATA_CFG

20-150

Vol. 3B

PERFORMANCE MONITORING

Table 20-98. MSR_PEBS_CFG Programming¹

Bit

Bit Index

Access

Description

Memory Info

0

R/W

Setting this bit will capture memory information such as the linear address,

data source and latency of the memory access in the PEBS record.

GPRs

1

R/W

Setting this bit will capture the contents of the General Purpose registers

in the PEBS record.

XMMs

2

R/W

Setting this bit will capture the contents of the XMM registers in the PEBS

record.

LBRs

3

R/W

Setting this bit will capture LBR TO, FROM, and INFO in the PEBS record.

Reserved²

23:4

NA

Reserved

LBR Entries

31:24

R/W

Set the field to the desired number of entries minus 1. For example, if the

LBR_entries field is 0, a single entry will be included in the record. To

include 32 LBR entries, set the LBR_entries field to 31 (0x1F). To ensure

all PEBS records are 16-byte aligned, it is recommended to select an even

number of LBR entries (programmed into LBR_entries as an odd number).

NOTES:

1. A write to the MSR will be ignored when IA32_MISC_ENABLE.PERFMON_AVAILABLE is zero (default).

2. Writing to the reserved bits will cause a GP fault.

20.9.2.4 PEBS Record Examples

The following example shows the layout of the PEBS record when all data groups are selected (all valid bits in

MSR_PEBS_DATA_CFG are set) and maximum number of LBRs are selected. There are no gaps in the PEBS record

when a subset of the groups are selected, thus keeping the layout compact. Implementations that do not support

some features will have to pad zeroes in the corresponding fields.

Table 20-99. PEBS Record Example 1

Offset

Group Name

Field Name

Legacy Name (If Different)

0x0

Basic Info

Record Format

New

Record Size

New

0x8

Instruction Pointer

EventingRIP

0x10

Applicable Counters

0x18

TSC

0x20

Memory Info

Memory Access Address

DLA

0x28

Memory Auxiliary Info

DATA_SRC

0x30

Memory Access Latency

Load Latency

0x38

TSX Auxiliary Info

HLE Information

Vol. 3B

20-151

PERFORMANCE MONITORING

Table 20-99. PEBS Record Example 1

0x40

GPRs

RFLAGS

0x48

RIP

0x50

RAX

0x88

RDI

0x90

R8

0xC8

R15

0xD0

XMMs

XMM0

New

0x1C0

XMM15

0x1D0

LBRs

LBR[TOS].FROM

New

0x1D8

LBR[TOS].TO

0x1E0

LBR[TOS].INFO

0x4B8

LBR[TOS +1].FROM

0x4C0

LBR[TOS +1].TO

0x4C8

LBR[TOS +1].INFO

The following example shows the layout of the PEBS record when Basic, GPR, and LBR group with 3 LBR entries are

selected.

Table 20-100. PEBS Record Example 2

Offset

Group Name

Field Name

Legacy Name (If Different)

0x0

Basic Info

Record Format

New

Record Size

New

0x8

Instruction Pointer

EventingRIP

0x10

Applicable Counters

0x18

TSC

20-152

Vol. 3B

PERFORMANCE MONITORING

Table 20-100. PEBS Record Example 2

0x20

GPRs

RFLAGS

0x28

RIP

0x30

RAX

0x68

RDI

0x70

R8

0xA8

R15

0xB0

LBRs

LBR[TOS].FROM

New

0xB8

LBR[TOS].TO

0xC0

LBR[TOS].INFO

0xE0

LBR[TOS +1].FROM

0xE8

LBR[TOS +1].TO

0xF0

LBR[TOS +1].INFO

20.9.3 Precise Distribution of Instructions Retired (PDIR) Facility

Precise Distribution of Instructions Retired Facility is available via PEBS on some microarchitectures. Refer to

Section 20.3.4.4.4. Counters that support PDIR also vary. See the processor specific sections for availability.

20.9.4 Reduced Skid PEBS

For precise events, upon triggering a PEBS assist, there will be a finite delay between the time the counter over-

flows and when the microcode starts to carry out its data collection obligations. The Reduced Skid mechanism miti-

gates the “skid” problem by providing an early indication of when the counter is about to overflow, allowing the

machine to more precisely trap on the instruction that actually caused the counter overflow thus greatly reducing

skid.

This mechanism is a superset of the PDIR mechanism available in the Sandy Bridge microarchitecture. See Section

20.3.4.4.4

In the Goldmont microarchitecture, the mechanism applies to all precise events including, INST_RETIRED, except

for UOPS_RETIRED. However, the Reduced Skid mechanism is disabled for any counter when the INV, ANY, E, or

CMASK fields are set.

With Reduced Skid PEBS, the skid is precisely one event occurrence. Hence if counting INST_RETIRED, PEBS will

indicate the instruction that follows that which caused the counter to overflow.

For the Reduced Skid mechanism to operate correctly, the performance monitoring counters should not be recon-

figured or modified when they are running with PEBS enabled. The counters need to be disabled (e.g., via

IA32_PERF_GLOBAL_CTRL MSR) before changes to the configuration (e.g., what event is specified in IA32_PERFE-

VTSELx or whether PEBS is enabled for that counter via IA32_PEBS_ENABLE) or counter value (MSR write to

IA32_PMCx and IA32_A_PMCx).

Vol. 3B

20-153

PERFORMANCE MONITORING

20.9.5 EPT-Friendly PEBS

The 3rd generation Intel Xeon Scalable Family of processors based on Ice Lake microarchitecture (and later proces-

sors) and the 12th generation Intel Core processor (and later processors) support VMX guest use of PEBS when the

DS Area (including the PEBS Buffer and DS Management Area) is allocated from a paged pool of EPT pages. In such

a configuration PEBS DS Area accesses may result in VM exits (e.g., EPT violations due to “lazy” EPT page-table

entry propagation), and in such cases the PEBS record will not be lost but instead will “skid” to after the subsequent

VM Entry back to the guest. For precise events the guest will observe that the record skid by one event occurrence,

while for non-precise events the record will skid by one instruction.

20.9.6 PDist: Precise Distribution

PDist eliminates any skid or shadowing effects from PEBS. With PDist, the PEBS record will be generated precisely

upon completion of the instruction or operation that causes the counter to overflow (there is no “wait for next

occurrence” by default).

PDist is supported by selected counters, and is only supported when those counters are programmed to count

select precise events¹. The legacy PEBS behavior applies to counters that do not support PDist, unless specified

otherwise. PDist requires that the INV, ANY, E, and CMASK fields are cleared. Which counters support PDist, and

which events are supported for PDist, is model-specific. Further, the counter reload value must not be lesser than

127 for PDist to operate.

For the PDist mechanism to operate correctly, the performance monitoring counters should not be reconfigured or

modified when they are running with PEBS enabled. The counters need to be disabled (e.g., via IA32_PERF_-

GLOBAL_CTRL MSR) before changes to the configuration (e.g., what event is specified in IA32_PERFEVTSELx or

whether PEBS is enabled for that counter via IA32_PEBS_ENABLE) or counter value (MSR write to IA32_PMCx and

IA32_A_PMCx).

20.9.7 Load Latency Facility

The load latency facility provides software a means to characterize the latencies of memory load operations to

different levels of cache/memory hierarchy. This facility requires a processor supporting the enhanced PEBS record

format in the PEBS buffer.

Beginning with 12th generation Intel Core processors, the load latency facility supports all fields in Table 20-94,

“Updated Memory Access Info Group,” in addition to the Memory Access Address field:

• The Instruction Latency field measures the load latency from the load's first dispatch until final data

writeback from the memory subsystem. The latency is reported for retired demand load operations and in core

cycles (it accounts for re-dispatches and data dependencies).

• The Cache Latency field measures the subset of cache access latency in core cycles. It starts from the actual

cache access until the data is returned by the memory subsystem The latency is reported for retired demand

load operations in core cycles (it does not account for memory ordering blocks).

• The Data Source field is an encoded value indicates the origin of the data obtained by the load instruction. The

encoding is shown in Table 20-101. In the descriptions, local memory refers to system memory physically

attached to a processor package, and remote memory refers to system memory or cache physically attached

to another processor package (in a server product).

• Through the Access Info field, load latency features binary indications on certain blocks that the load

operation may have encountered. Refer to STLB-miss, Is-Lock, Data-Blk and Address-Blk fields in Table 20-94.

NOTE

For loads triggered by software prefetch instructions, the cache related fields including Data Source

and Cache Latency, report values as if the load was an L1 cache hit (the prefetch completes without

waiting for data return, for performance reasons).

1. To determine whether an event is precise or supports PDist, consult the relevant attribute in the event lists at https://down-

load.01.org/perfmon/.

20-154

Vol. 3B

PERFORMANCE MONITORING

Table 20-101. Data Source Encoding for Memory Accesses (Ice Lake and Later Microarchitectures)

Encoding

Description

00H

Unknown Data Source (the processor could not retrieve the origin of this request).

01H

L1 HIT. This request was satisfied by the L1 data cache. (Minimal latency core cache hit.)

02H

FB HIT. This request was merged into an outstanding cache miss to same cache-line address.

03H

L2 HIT. This request was satisfied by the L2 cache.

04H

L3 HIT. This request was satisfied by the L3 cache with no coherency actions performed (snooping).

05H

XCORE MISS. This request was satisfied by the L3 cache but involved a coherency check in some sibling core(s).

06H

XCORE HIT. This request was satisfied by the L3 cache but involved a coherency check that hit a non-modified copy in

a sibling core.

07H

XCORE FWD. This request was satisfied by a sibling core where either a modified (cross-core HITM) or a non-modified

(cross-core FWD) cache-line copy was found.

08H

Local Far Memory. This request has missed the L3 cache and was serviced by local far memory.

09H

Remote Far Memory. This request has missed the L3 cache and was serviced by remote far memory.

0AH

Local Near Memory. This request has missed the L3 cache and was serviced by local near memory.

0BH

Remote Near Memory. This request has missed the L3 cache and was serviced by remote near memory.

0CH

Remote FWD. This request has missed the L3 cache and a non-modified cache-line copy was forwarded from a

remote cache.

0DH

Remote HITM. This request has missed the L3 cache and a modified cache-line was forwarded from a remote cache.

0EH

I/O. Request of input/output operation.

0FH

UC. The request was to uncacheable memory.

To use this feature, software must complete the following steps:

• Complete the PEBS configuration steps.

• Set the Memory Info bit in the PEBS_DATA_CFG MSR.

• One of the relevant IA32_PERFEVTSELx MSRs is programmed to specify the event unit MEM_TRANS_RE-

TIRED.LOAD_LATENCY (IA32_PerfEvtSelX[15:0] = 1CDH). The corresponding counter, IA32_PMCx, will

accumulate event counts for architecturally visible loads which exceed the programmed latency threshold

specified separately in an MSR. Stores are ignored when this event is programmed. The CMASK or INV fields of

the IA32_PerfEvtSelX register used for counting load latency must be 0. Writing other values will result in

undefined behavior.

• The MSR_PEBS_LD_LAT_THRESHOLD MSR is programmed with the desired latency threshold in core clock

cycles. Loads with instruction latency greater than this value are eligible for counting and PEBS data reporting.

The minimum value that may be programmed in this register is 1.

• The PEBS enable bit in the IA32_PEBS_ENABLE register is set for the corresponding IA32_PMCx counter

register.

Refer to Section 20.3.4.4.2 for further implementation details of Load Latency.

20.9.8 Store Latency Facility

Store latency support is available on the 12th generation Intel Core processor. Store latency is a PEBS extension

that provides a means to profile store memory accesses in the system. It complements the load latency facility.

Store latency leverages the PEBS facility where it can provide additional information about sampled stores. The

additional information includes the data address, memory auxiliary information, and the cache latency of the store

access. Normal stores (those preceded with a read-for-ownership) as well as streaming stores are supported by

the store latency facility.

Vol. 3B

20-155

PERFORMANCE MONITORING

Memory store operations typically do not limit performance since they update the memory with no operation that

directly depends on them. Thus, data out of this facility should be carefully used once stores are suspected as a

performance limiter; for example, once the TMA node of Backend_Bound.Memory_Bound.Store_Bound is flagged¹.

To enable the store latency facility, software must complete the following steps:

• Complete the PEBS configuration steps.

• Set the Memory Info bit in the PEBS_DATA_CFG MSR.

• Program the MEM_TRANS_RETIRED.STORE_SAMPLE event on general-purpose performance-monitoring

counter 0 (IA32_PERFEVTSEL0[15:0] = 2CDH).

• Setup the PEBS buffer to hold at least two records, setting both ‘PEBS Absolute Maximum’ and ‘PEBS Interrupt

Threshold’, should any other counter be used by PEBS (that is whenever IA32_PEBS_ENABLE[x] ≠ 0 for x ≠ 0).

• Set IA32_PEBS_ENABLE[0].

The store latency information is written into a PEBS record as shown in Table 20-48.

The store latency relies on the PEBS facility, so the PEBS configuration must be completed first. Unlike load latency,

there is no option to filter on a subset of stores that exceed a certain threshold.

1. For more details about the method, refer to Section B.1, “Top-Down Analysis Method” of the Intel® 64 and IA-32 Architectures Opti-

mization Reference Manual.

20-156

Vol. 3B

CHAPTER 21

8086 EMULATION

IA-32 processors (beginning with the Intel386 processor) provide two ways to execute new or legacy programs

that are assembled and/or compiled to run on an Intel 8086 processor:

• Real-address mode.

• Virtual-8086 mode.

Figure 2-3 shows the relationship of these operating modes to protected mode and system management mode

(SMM).

When the processor is powered up or reset, it is placed in the real-address mode. This operating mode almost

exactly duplicates the execution environment of the Intel 8086 processor, with some extensions. Virtually any

program assembled and/or compiled to run on an Intel 8086 processor will run on an IA-32 processor in this mode.

When running in protected mode, the processor can be switched to virtual-8086 mode to run 8086 programs. This

mode also duplicates the execution environment of the Intel 8086 processor, with extensions. In virtual-8086

mode, an 8086 program runs as a separate protected-mode task. Legacy 8086 programs are thus able to run

under an operating system (such as Microsoft Windows*) that takes advantage of protected mode and to use

protected-mode facilities, such as the protected-mode interrupt- and exception-handling facilities. Protected-mode

multitasking permits multiple virtual-8086 mode tasks (with each task running a separate 8086 program) to be run

on the processor along with other non-virtual-8086 mode tasks.

This section describes both the basic real-address mode execution environment and the virtual-8086-mode execu-

tion environment, available on the IA-32 processors beginning with the Intel386 processor.

21.1

REAL-ADDRESS MODE

The IA-32 architecture’s real-address mode runs programs written for the Intel 8086, Intel 8088, Intel 80186, and

Intel 80188 processors, or for the real-address mode of the Intel 286, Intel386, Intel486, Pentium, P6 family,

Pentium 4, and Intel Xeon processors.

The execution environment of the processor in real-address mode is designed to duplicate the execution environ-

ment of the Intel 8086 processor. To an 8086 program, a processor operating in real-address mode behaves like a

high-speed 8086 processor. The principal features of this architecture are defined in Chapter 3, “Basic Execution

Environment,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.

The following is a summary of the core features of the real-address mode execution environment as would be seen

by a program written for the 8086:

• The processor supports a nominal 1-MByte physical address space (see Section 21.1.1, “Address Translation in

Real-Address Mode,” for specific details). This address space is divided into segments, each of which can be up

to 64 KBytes in length. The base of a segment is specified with a 16-bit segment selector, which is shifted left

by 4 bits to form a 20-bit offset from address 0 in the address space. An operand within a segment is addressed

with a 16-bit offset from the base of the segment. A physical address is thus formed by adding the offset to the

20-bit segment base (see Section 21.1.1, “Address Translation in Real-Address Mode”).

• All operands in “native 8086 code” are 8-bit or 16-bit values. (Operand size override prefixes can be used to

access 32-bit operands.)

• Eight 16-bit general-purpose registers are provided: AX, BX, CX, DX, SP, BP, SI, and DI. The extended 32 bit

registers (EAX, EBX, ECX, EDX, ESP, EBP, ESI, and EDI) are accessible to programs that explicitly perform a size

override operation.

• Four segment registers are provided: CS, DS, SS, and ES. (The FS and GS registers are accessible to programs

that explicitly access them.) The CS register contains the segment selector for the code segment; the DS and

ES registers contain segment selectors for data segments; and the SS register contains the segment selector

for the stack segment.

• The 8086 16-bit instruction pointer (IP) is mapped to the lower 16-bits of the EIP register. Note this register is

a 32-bit register and unintentional address wrapping may occur.

Vol. 3B

21-1

8086 EMULATION

19

4

3

0

Base

16-bit Segment Selector

0 0 0 0

+

19

16

15

0

Offset

0 0 0 0

16-bit Effective Address

=

19

0

Linear

20-bit Linear Address

Address

Figure 21-1. Real-Address Mode Address Translation

The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override

prefix; however, in real-address mode, the value of a 32-bit offset may not exceed FFFFH without causing an

exception.

For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-

bit offset is generated outside the range 0 through FFFFH.

21.1.2 Registers Supported in Real-Address Mode

The register set available in real-address mode includes all the registers defined for the 8086 processor plus the

new registers introduced in later IA-32 processors, such as the FS and GS segment registers, the debug registers,

the control registers, and the floating-point unit registers. The 32-bit operand prefix allows a real-address mode

program to use the 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESP, EBP, ESI, and EDI).

21.1.3 Instructions Supported in Real-Address Mode

The following instructions make up the core instruction set for the 8086 processor. If backwards compatibility to

the Intel 286 and Intel 8086 processors is required, only these instructions should be used in a new program

written to run in real-address mode.

• Move (MOV) instructions that move operands between general-purpose registers, segment registers, and

between memory and general-purpose registers.

• The exchange (XCHG) instruction.

• Load segment register instructions LDS and LES.

• Arithmetic instructions ADD, ADC, SUB, SBB, MUL, IMUL, DIV, IDIV, INC, DEC, CMP, and NEG.

• Logical instructions AND, OR, XOR, and NOT.

• Decimal instructions DAA, DAS, AAA, AAS, AAM, and AAD.

• Stack instructions PUSH and POP (to general-purpose registers and segment registers).

• Type conversion instructions CWD, CDQ, CBW, and CWDE.

• Shift and rotate instructions SAL, SHL, SHR, SAR, ROL, ROR, RCL, and RCR.

• TEST instruction.

• Control instructions JMP, Jcc, CALL, RET, LOOP, LOOPE, and LOOPNE.

• Interrupt instructions INT n, INTO, and IRET.

• EFLAGS control instructions STC, CLC, CMC, CLD, STD, LAHF, SAHF, PUSHF, and POPF.

• I/O instructions IN, INS, OUT, and OUTS.

• Load effective address (LEA) instruction, and translate (XLATB) instruction.

Vol. 3B

21-3

8086 EMULATION

5. Transfers program control to the location specified in the interrupt vector table.

An IRET instruction at the end of the handler procedure reverses these steps to return program control to the inter-

rupted program. Exceptions do not return error codes in real-address mode.

The interrupt vector table is an array of 4-byte entries (see Figure 21-2). Each entry consists of a far pointer to a

handler procedure, made up of a segment selector and an offset. The processor scales the interrupt or exception

vector by 4 to obtain an offset into the interrupt table. Following reset, the base of the interrupt vector table is

located at physical address 0 and its limit is set to 3FFH. In the Intel 8086 processor, the base address and limit of

the interrupt vector table cannot be changed. In the later IA-32 processors, the base address and limit of the inter-

rupt vector table are contained in the IDTR register and can be changed using the LIDT instruction.

(For backward compatibility to Intel 8086 processors, the default base address and limit of the interrupt vector

table should not be changed.)

Up to Entry 255

Entry 3

12

Entry 2

8

Entry 1

4

Segment Selector

2

Interrupt Vector 0*

Offset

0

15

0

* Interrupt vector number 0 selects entry 0

IDTR

(called “interrupt vector 0”) in the interrupt

vector table. Interrupt vector 0 in turn

points to the start of the interrupt handler

for interrupt 0.

Figure 21-2. Interrupt Vector Table in Real-Address Mode

Table 21-1 shows the interrupt and exception vectors that can be generated in real-address mode and virtual-8086

mode, and in the Intel 8086 processor. See Chapter 6, “Interrupt and Exception Handling‚” for a description of the

exception conditions.

21.2

VIRTUAL-8086 MODE

Virtual-8086 mode is actually a special type of a task that runs in protected mode. When the operating-system or

executive switches to a virtual-8086-mode task, the processor emulates an Intel 8086 processor. The execution

environment of the processor while in the 8086-emulation state is the same as is described in Section 21.1, “Real-

Address Mode,” for real-address mode, including the extensions. The major difference between the two modes is

that in virtual-8086 mode the 8086 emulator uses some protected-mode services (such as the protected-mode

interrupt and exception-handling and paging facilities).

Vol. 3B

21-5

8086 EMULATION

As in real-address mode, any new or legacy program that has been assembled and/or compiled to run on an Intel

8086 processor will run in a virtual-8086-mode task. And several 8086 programs can be run as virtual-8086-mode

tasks concurrently with normal protected-mode tasks, using the processor’s multitasking facilities.

Table 21-1. Real-Address Mode Exceptions and Interrupts

Vector

Description

Real-Address Mode

Virtual-8086 Mode

Intel 8086 Processor

No.

0

Divide Error (#DE)

Yes

Yes

Yes

1

Debug Exception (#DB)

Yes

Yes

No

2

NMI Interrupt

Yes

Yes

Yes

3

Breakpoint (#BP)

Yes

Yes

Yes

4

Overflow (#OF)

Yes

Yes

Yes

5

BOUND Range Exceeded (#BR)

Yes

Yes

Reserved

6

Invalid Opcode (#UD)

Yes

Yes

Reserved

7

Device Not Available (#NM)

Yes

Yes

Reserved

8

Double Fault (#DF)

Yes

Yes

Reserved

9

(Intel reserved. Do not use.)

Reserved

Reserved

Reserved

10

Invalid TSS (#TS)

Reserved

Yes

Reserved

11

Segment Not Present (#NP)

Reserved

Yes

Reserved

12

Stack Fault (#SS)

Yes

Yes

Reserved

13

General Protection (#GP)*

Yes

Yes

Reserved

14

Page Fault (#PF)

Reserved

Yes

Reserved

15

(Intel reserved. Do not use.)

Reserved

Reserved

Reserved

16

Floating-Point Error (#MF)

Yes

Yes

Reserved

17

Alignment Check (#AC)

Reserved

Yes

Reserved

18

Machine Check (#MC)

Yes

Yes

Reserved

19-31

(Intel reserved. Do not use.)

Reserved

Reserved

Reserved

32-255

User Defined Interrupts

Yes

Yes

Yes

NOTE:

* In the real-address mode, vector 13 is the segment overrun exception. In protected and virtual-8086 modes, this exception cov-

ers all general-protection error conditions, including traps to the virtual-8086 monitor from virtual-8086 mode.

21.2.1 Enabling Virtual-8086 Mode

The processor runs in virtual-8086 mode when the VM (virtual machine) flag in the EFLAGS register is set. This flag

can only be set when the processor switches to a new protected-mode task or resumes virtual-8086 mode via an

IRET instruction.

System software cannot change the state of the VM flag directly in the EFLAGS register (for example, by using the

POPFD instruction). Instead it changes the flag in the image of the EFLAGS register stored in the TSS or on the

stack following a call to an interrupt- or exception-handler procedure. For example, software sets the VM flag in the

EFLAGS image in the TSS when first creating a virtual-8086 task.

The processor tests the VM flag under three general conditions:

• When loading segment registers, to determine whether to use 8086-style address translation.

• When decoding instructions, to determine which instructions are not supported in virtual-8086 mode and which

instructions are sensitive to IOPL.

21-6

Vol. 3B

8086 EMULATION

Real Mode

Code

Real-Address

Mode

PE=0 or

PE=1

RESET

Task Switch

Protected-

CALL

Protected

Protected-

VM=0

Mode Interrupt

Virtual-8086

Mode

Mode Tasks

and Exception

Monitor

Handlers

RET

Task Switch¹

VM = 0

VM = 1

Interrupt or

Exception²

Virtual-8086

Mode

Virtual-8086

#GP Exception³

RESET

Mode Tasks

(8086

IRET⁴

Programs)

IRET⁵

Redirect Interrupt to 8086 Program

Interrupt or Exception Handler⁶

NOTES:

1. Task switch carried out in either of two ways:

- CALL or JMP where the VM flag in the EFLAGS image is 1.

- IRET where VM is 1 and NT is 1.

2. Hardware interrupt or exception; software interrupt (INT n) when IOPL is 3.

3. General-protection exception caused by software interrupt (INT n), IRET,

POPF, PUSHF, IN, or OUT when IOPL is less than 3.

4. Normal return from protected-mode interrupt or exception handler.

5. A return from the 8086 monitor to redirect an interrupt or exception back

to an interrupt or exception handler in the 8086 program running in virtual-

8086 mode.

6. Internal redirection of a software interrupt (INT n) when VME is 1,

IOPL is <3, and the redirection bit is 1.

Figure 21-3. Entering and Leaving Virtual-8086 Mode

21.2.6 Leaving Virtual-8086 Mode

The processor can leave the virtual-8086 mode only through an interrupt or exception. The following are situations

where an interrupt or exception will lead to the processor leaving virtual-8086 mode (see Figure 21-3):

• The processor services a hardware interrupt generated to signal the suspension of execution of the virtual-

8086 application. This hardware interrupt may be generated by a timer or other external mechanism. Upon

receiving the hardware interrupt, the processor enters protected mode and switches to a protected-mode (or

another virtual-8086 mode) task either through a task gate in the protected-mode IDT or through a trap or

interrupt gate that points to a handler that initiates a task switch. A task switch from a virtual-8086 task to

another task loads the EFLAGS register from the TSS of the new task. The value of the VM flag in the new

EFLAGS determines if the new task executes in virtual-8086 mode or not.

• The processor services an exception caused by code executing the virtual-8086 task or services a hardware

interrupt that “belongs to” the virtual-8086 task. Here, the processor enters protected mode and services the

Vol. 3B

21-9

8086 EMULATION

21.2.8.1 I/O-Port-Mapped I/O

The I/O permission bit map in the TSS can be used to generate exceptions on attempts to access specific I/O port

addresses. The I/O permission bit map of each virtual-8086-mode task determines which I/O addresses generate

exceptions for that task. Because each task may have a different I/O permission bit map, the addresses that

generate exceptions for one task may be different from the addresses for another task. This differs from protected

mode in which, if the CPL is less than or equal to the IOPL, I/O access is allowed without checking the I/O permis-

sion bit map. See Chapter 19, “Input/Output,” in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1, for more information about the I/O permission bit map.

21.2.8.2 Memory-Mapped I/O

In systems which use memory-mapped I/O, the paging facilities of the processor can be used to generate excep-

tions for attempts to access I/O ports. The virtual-8086 monitor may use paging to control memory-mapped I/O in

these ways:

• Map part of the linear address space of each task that needs to perform I/O to the physical address space

where I/O ports are placed. By putting the I/O ports at different addresses (in different pages), the paging

mechanism can enforce isolation between tasks.

• Map part of the linear address space to pages that are not-present. This generates an exception whenever a

task attempts to perform I/O to those pages. System software then can interpret the I/O operation being

attempted.

Software emulation of the I/O space may require too much operating system intervention under some conditions.

In these cases, it may be possible to generate an exception for only the first attempt to access I/O. The system

software then may determine whether a program can be given exclusive control of I/O temporarily, the protection

of the I/O space may be lifted, and the program allowed to run at full speed.

21.2.8.3 Special I/O Buffers

Buffers of intelligent controllers (for example, a bit-mapped frame buffer) also can be emulated using page

mapping. The linear space for the buffer can be mapped to a different physical space for each virtual-8086-mode

task. The virtual-8086 monitor then can control which virtual buffer to copy onto the real buffer in the physical

address space.

21.3

INTERRUPT AND EXCEPTION HANDLING IN VIRTUAL-8086 MODE

When the processor receives an interrupt or detects an exception condition while in virtual-8086 mode, it invokes

an interrupt or exception handler, just as it does in protected or real-address mode. The interrupt or exception

handler that is invoked and the mechanism used to invoke it depends on the class of interrupt or exception that has

been detected or generated and the state of various system flags and fields.

In virtual-8086 mode, the interrupts and exceptions are divided into three classes for the purposes of handling:

• Class 1 — All processor-generated exceptions and all hardware interrupts, including the NMI interrupt and the

hardware interrupts sent to the processor’s external interrupt delivery pins. All class 1 exceptions and

interrupts are handled by the protected-mode exception and interrupt handlers.

• Class 2 — Special case for maskable hardware interrupts (Section 6.3.2, “Maskable Hardware Interrupts”)

when the virtual mode extensions are enabled.

• Class 3 — All software-generated interrupts, that is interrupts generated with the INT n instruction¹.

The method the processor uses to handle class 2 and 3 interrupts depends on the setting of the following flags and

fields:

• IOPL field (bits 12 and 13 in the EFLAGS register) — Controls how class 3 software interrupts are handled

when the processor is in virtual-8086 mode (see Section 2.3, “System Flags and Fields in the EFLAGS

1. The INT 3 instruction is a special case (see the description of the INT n instruction in Chapter 3, “Instruction Set Reference, A-L,” of

the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A).

Vol. 3B

21-11

8086 EMULATION

3. Clears the segment registers. Saving the DS, ES, FS, and GS registers on the stack and then clearing the

registers lets the interrupt or exception handler safely save and restore these registers regardless of the type

segment selectors they contain (protected-mode or 8086-style). The interrupt and exception handlers, which

may be called in the context of either a protected-mode task or a virtual-8086-mode task, can use the same

code sequences for saving and restoring the registers for any task. Clearing these registers before execution of

the IRET instruction does not cause a trap in the interrupt handler. Interrupt procedures that expect values in

the segment registers or that return values in the segment registers must use the register images saved on the

stack for privilege level 0.

4. Clears VM, NT, RF, and TF flags (in the EFLAGS register). If the gate is an interrupt gate, clears the IF flag.

5. Begins executing the selected interrupt or exception handler.

If the trap or interrupt gate references a procedure in a conforming segment or in a segment at a privilege level

other than 0, the processor generates a general-protection exception (#GP). Here, the error code is the segment

selector of the code segment to which a call was attempted.

Without Error Code

With Error Code

ESP from

ESP from

Unused

Unused

TSS

TSS

Old GS

Old GS

Old FS

Old FS

Old DS

Old DS

Old ES

Old ES

Old SS

Old SS

Old ESP

Old ESP

Old EFLAGS

Old EFLAGS

Old CS

Old CS

Old EIP

New ESP

Old EIP

Error Code

New ESP

Figure 21-4. Privilege Level 0 Stack After Interrupt or Exception in Virtual-8086 Mode

Interrupt and exception handlers can examine the VM flag on the stack to determine if the interrupted procedure

was running in virtual-8086 mode. If so, the interrupt or exception can be handled in one of three ways:

• The protected-mode interrupt or exception handler that was called can handle the interrupt or exception.

• The protected-mode interrupt or exception handler can call the virtual-8086 monitor to handle the interrupt or

exception.

• The virtual-8086 monitor (if called) can in turn pass control back to the 8086 program’s interrupt and exception

handler.

If the interrupt or exception is handled with a protected-mode handler, the handler can return to the interrupted

program in virtual-8086 mode by executing an IRET instruction. This instruction loads the EFLAGS and segment

registers from the images saved in the privilege level 0 stack (see Figure 21-4). A set VM flag in the EFLAGS image

causes the processor to switch back to virtual-8086 mode. The CPL at the time the IRET instruction is executed

must be 0, otherwise the processor does not change the state of the VM flag.

The virtual-8086 monitor runs at privilege level 0, like the protected-mode interrupt and exception handlers. It is

commonly closely tied to the protected-mode general-protection exception (#GP, vector 13) handler. If the

Vol. 3B

21-13

8086 EMULATION

The IOPL value interacts with the VME flag and the bits in the interrupt redirection bit map to determine how

specific software interrupts should be handled.

The software interrupt redirection bit map (see Figure 21-5) is a 32-byte field in the TSS. This map is located

directly below the I/O permission bit map in the TSS. Each bit in the interrupt redirection bit map is mapped to an

interrupt vector. Bit 0 in the interrupt redirection bit map (which maps to vector zero in the interrupt table) is

located at the I/O base map address in the TSS minus 32 bytes. When a bit in this bit map is set, it indicates that

the associated software interrupt (interrupt generated with an INT n instruction) should be handled through the

protected-mode IDT and interrupt and exception handlers. When a bit in this bit map is clear, the processor redi-

rects the associated software interrupt back to the interrupt table in the 8086 program (located at linear address 0

in the program’s address space).

NOTE

The software interrupt redirection bit map does not affect hardware generated interrupts and

exceptions. Hardware generated interrupts and exceptions are always handled by the protected-

mode interrupt and exception handlers.

Table 21-2. Software Interrupt Handling Methods While in Virtual-8086 Mode

Bit in

Redir.

Method

VME

IOPL

Bitmap*

Processor Action

1

0

3

X

Interrupt directed to a protected-mode interrupt handler:

• Switches to privilege-level 0 stack.

• Pushes GS, FS, DS, and ES onto privilege-level 0 stack.

• Pushes SS, ESP, EFLAGS, CS, and EIP of interrupted task onto privilege-level 0 stack.

• Clears VM, RF, NT, and TF flags.

• If serviced through interrupt gate, clears IF flag.

• Clears GS, FS, DS, and ES to 0.

• Sets CS and EIP from interrupt gate.

2

0

< 3

X

Interrupt directed to protected-mode general-protection exception (#GP) handler.

3

1

< 3

1

Interrupt directed to a protected-mode general-protection exception (#GP) handler; VIF and VIP

flag support for handling class 2 maskable hardware interrupts.

4

1

3

1

Interrupt directed to protected-mode interrupt handler: (see method 1 processor action).

5

1

3

0

Interrupt redirected to 8086 program interrupt handler:

• Pushes EFLAGS.

• Pushes CS and EIP (lower 16 bits only).

• Clears IF flag.

• Clears TF flag.

• Loads CS and EIP (lower 16 bits only) from selected entry in the interrupt vector table of the

current virtual-8086 task.

6

1

< 3

0

Interrupt redirected to 8086 program interrupt handler; VIF and VIP flag support for handling class

2 maskable hardware interrupts:

• Pushes EFLAGS with IOPL set to 3 and VIF copied to IF.

• Pushes CS and EIP (lower 16 bits only).

• Clears the VIF flag.

• Clears TF flag.

• Loads CS and EIP (lower 16 bits only) from selected entry in the interrupt vector table of the

current virtual-8086 task.

NOTE:

* When set to 0, software interrupt is redirected back to the 8086 program interrupt handler; when set to 1, interrupt is directed to

protected-mode handler.

Vol. 3B

21-17

8086 EMULATION

31

24 23

Task-State Segment (TSS)

0

Last byte of

1

1

1

1

1

1

1

1

bit

map must be

I/O Permission Bit Map

Software Interrupt Redirection Bit Map (32 Bytes)

I/O Map Base

64H

I/O map

base must

not exceed

DFFFH.

0

Figure 21-5. Software Interrupt Redirection Bit Map in TSS

Redirecting software interrupts back to the 8086 program potentially speeds up interrupt handling because a

switch back and forth between virtual-8086 mode and protected mode is not required. This latter interrupt-

handling technique is particularly useful for 8086 operating systems (such as MS-DOS) that use the INT n instruc-

tion to call operating system procedures.

The CPUID instruction can be used to verify that the virtual mode extension is implemented on the processor. Bit 1

of the feature flags register (EDX) indicates the availability of the virtual mode extension (see “CPUID—CPU Iden-

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

oper’s Manual, Volume 2A).

The following sections describe the six methods (or mechanisms) for handling software interrupts in virtual-8086

mode. See Section 21.3.2, “Class 2—Maskable Hardware Interrupt Handling in Virtual-8086 Mode Using the Virtual

Interrupt Mechanism,” for a description of the use of the VIF and VIP flags in the EFLAGS register for handling

maskable hardware interrupts.

21.3.3.1 Method 1: Software Interrupt Handling

When the VME flag in control register CR4 is clear and the IOPL field is 3, a Pentium or later IA-32 processor

handles software interrupts in the same manner as they are handled by an Intel386 or Intel486 processor. It

executes an implicit call to the interrupt handler in the protected-mode IDT pointed to by the interrupt vector. See

Section 21.3.1, “Class 1—Hardware Interrupt and Exception Handling in Virtual-8086 Mode,” for a complete

description of this mechanism and its possible uses.

21.3.3.2 Methods 2 and 3: Software Interrupt Handling

When a software interrupt occurs in virtual-8086 mode and the method 2 or 3 conditions are present, the processor

generates a general-protection exception (#GP). Method 2 is enabled when the VME flag is set to 0 and the IOPL

value is less than 3. Here the IOPL value is used to bypass the protected-mode interrupt handlers and cause any

software interrupt that occurs in virtual-8086 mode to be treated as a protected-mode general-protection excep-

tion (#GP). The general-protection exception handler calls the virtual-8086 monitor, which can then emulate an

8086-program interrupt handler or pass control back to the 8086 program’s handler, as described in Section

21.3.1.2, “Handling an Interrupt or Exception With an 8086 Program Interrupt or Exception Handler.”

Method 3 is enabled when the VME flag is set to 1, the IOPL value is less than 3, and the corresponding bit for the

software interrupt in the software interrupt redirection bit map is set to 1. Here, the processor performs the same

21-18

Vol. 3B

CHAPTER 22

MIXING 16-BIT AND 32-BIT CODE

Program modules written to run on IA-32 processors can be either 16-bit modules or 32-bit modules. Table 22-1

shows the characteristic of 16-bit and 32-bit modules.

Table 22-1. Characteristics of 16-Bit and 32-Bit Program Modules

Characteristic

16-Bit Program Modules

32-Bit Program Modules

Segment Size

0 to 64 KBytes

0 to 4 GBytes

Operand Sizes

8 bits and 16 bits

8 bits and 32 bits

Pointer Offset Size (Address Size)

16 bits

32 bits

Stack Pointer Size

16 Bits

32 Bits

Control Transfers Allowed to Code Segments

16 Bits

32 Bits

of This Size

The IA-32 processors function most efficiently when executing 32-bit program modules. They can, however, also

execute 16-bit program modules, in any of the following ways:

• In real-address mode.

• In virtual-8086 mode.

• System management mode (SMM).

• As a protected-mode task, when the code, data, and stack segments for the task are all configured as a 16-bit

segments.

• By integrating 16-bit and 32-bit segments into a single protected-mode task.

• By integrating 16-bit operations into 32-bit code segments.

Real-address mode, virtual-8086 mode, and SMM are native 16-bit modes. A legacy program assembled and/or

compiled to run on an Intel 8086 or Intel 286 processor should run in real-address mode or virtual-8086 mode

without modification. Sixteen-bit program modules can also be written to run in real-address mode for handling

system initialization or to run in SMM for handling system management functions. See Chapter 21, “8086 Emula-

tion,” for detailed information on real-address mode and virtual-8086 mode; see Chapter 32, “System Manage-

ment Mode,” for information on SMM.

This chapter describes how to integrate 16-bit program modules with 32-bit program modules when operating in

protected mode and how to mix 16-bit and 32-bit code within 32-bit code segments.

22.1

DEFINING 16-BIT AND 32-BIT PROGRAM MODULES

The following IA-32 architecture mechanisms are used to distinguish between and support 16-bit and 32-bit

segments and operations:

• The D (default operand and address size) flag in code-segment descriptors.

• The B (default stack size) flag in stack-segment descriptors.

•

16-bit and 32-bit call gates, interrupt gates, and trap gates.

• Operand-size and address-size instruction prefixes.

•

16-bit and 32-bit general-purpose registers.

The D flag in a code-segment descriptor determines the default operand-size and address-size for the instructions

of a code segment. (In real-address mode and virtual-8086 mode, which do not use segment descriptors, the

default is 16 bits.) A code segment with its D flag set is a 32-bit segment; a code segment with its D flag clear is a

16-bit segment.

Vol. 3B

22-1

MIXING 16-BIT AND 32-BIT CODE

Without Privilege Transition

After 16-bit Call

After 32-bit Call

31

0

31

0

PARM 2

PARM 1

PARM 2

Stack

Growth

CS

IP

SP

PARM 1

CS

EIP

ESP

With Privilege Transition

After 16-bit Call

After 32-bit Call

31

0

31

0

SS

SP

SS

PARM 2

PARM 1

ESP

Stack

Growth

CS

IP

SP

PARM 2

PARM 1

CS

EIP

ESP

Undefined

Figure 22-1. Stack after Far 16- and 32-Bit Calls

While executing 32-bit code, if a call is made to a 16-bit code segment which is at the same or a more privileged

level (that is, the DPL of the called code segment is less than or equal to the CPL of the calling code segment)

through a 16-bit call gate, then the upper 16-bits of the ESP register may be unreliable upon returning to the 32-

bit code segment (that is, after executing a RET in the 16-bit code segment).

When the CALL instruction and its matching RET instruction are in code segments that have D flags with the same

values (that is, both are 32-bit code segments or both are 16-bit code segments), the default settings may be

used. When the CALL instruction and its matching RET instruction are in segments which have different D-flag

settings, an operand-size prefix must be used.

22.4.2.1 Controlling the Operand-Size Attribute For a Call

Three things can determine the operand-size of a call:

• The D flag in the segment descriptor for the calling code segment.

• An operand-size instruction prefix.

• The type of call gate (16-bit or 32-bit), if a call is made through a call gate.

When a call is made with a pointer (rather than a call gate), the D flag for the calling code segment determines the

operand-size for the CALL instruction. This operand-size attribute can be overridden by prepending an operand-

size prefix to the CALL instruction. So, for example, if the D flag for a code segment is set for 16 bits and the

operand-size prefix is used with a CALL instruction, the processor will cause the information stored on the stack to

Vol. 3B

22-5

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.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

Content      ..     58      59      60      61     ..