Content      ..     41      42      43      44     ..

Intel 64 and IA-32 Architectures. Software Developer’s Manual (2026) - page 43

XSETBV-Set Extended Control Register

Opcode

Instruction

Op/

64-Bit

Compat/

Description

En

Mode

Leg Mode

NP 0F 01 D1

XSETBV

ZO

Valid

Valid

Write the value in EDX:EAX to the XCR

specified by ECX.

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ZO

N/A

N/A

N/A

N/A

Description

Writes the contents of registers EDX:EAX into the 64-bit extended control register (XCR) specified in the ECX

register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The

contents of the EDX register are copied to high-order 32 bits of the selected XCR and the contents of the EAX

register are copied to low-order 32 bits of the XCR. (On processors that support the Intel 64 architecture, the high-

order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an XCR should be set to values

previously read.

This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection

exception #GP(0) is generated. Specifying a reserved or unimplemented XCR in ECX will also cause a general

protection exception. The processor will also generate a general protection exception if software attempts to write

to reserved bits in an XCR.

Currently, only XCR0 is supported. Thus, all other values of ECX are reserved and will cause a #GP(0). Note that

bit 0 of XCR0 (corresponding to x87 state) must be set to 1; the instruction will cause a #GP(0) if an attempt is

made to clear this bit. In addition, the instruction causes a #GP(0) if an attempt is made to set XCR0[2] (AVX state)

while clearing XCR0[1] (SSE state); it is necessary to set both bits to use AVX instructions; Section 13.3, “Enabling

the XSAVE Feature Set and XSAVE-Enabled Features,” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Operation

XCR[ECX] := EDX:EAX;

Flags Affected

None.

Intel C/C++ Compiler Intrinsic Equivalent

XSETBV void _xsetbv( unsigned int, unsigned __int64);

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If an invalid XCR is specified in ECX.

If the value in EDX:EAX sets bits that are reserved in the XCR specified by ECX.

If an attempt is made to clear bit 0 of XCR0.

If an attempt is made to set XCR0[2:1] to 10b.

#UD

If CPUID.01H:ECX.XSAVE[26] = 0.

If CR4.OSXSAVE[bit 18] = 0.

If the LOCK prefix is used.

XSETBV-Set Extended Control Register

Vol. 2D

6-70

XSUSLDTRK-Suspend Tracking Load Addresses

Opcode/

Op/

64/32 bit

CPUID Feature

Description

Instruction

En

Mode

Flag

Support

F2 0F 01 E8

ZO

V/V

TSXLDTRK

Specifies the start of an Intel TSX suspend read

XSUSLDTRK

address tracking region.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

ZO

N/A

N/A

N/A

N/A

N/A

Description

The instruction marks the start of an Intel TSX (RTM) suspend load address tracking region. If the instruction is

used inside a transactional region, subsequent loads are not added to the read set of the transaction. If the instruc-

tion is used inside a suspend load address tracking region it will cause transaction abort.

If the instruction is used outside of a transactional region it behaves like a NOP.

Chapter 16, “Programming with Intel® Transactional Synchronization Extensions‚” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 1 provides additional information on Intel^® TSX Suspend Load

Address Tracking.

Operation

XSUSLDTRK

IF RTM_ACTIVE = 1:

IF SUSLDTRK_ACTIVE = 0:

SUSLDTRK_ACTIVE := 1

ELSE:

RTM_ABORT

ELSE:

NOP

Flags Affected

None.

Intel C/C++ Compiler Intrinsic Equivalent

XSUSLDTRK void _xsusldtrk(void);

SIMD Floating-Point Exceptions

None.

Other Exceptions

#UD

If CPUID.07H.00H:EDX.TSXLDTRK[16] = 0.

If the LOCK prefix is used.

XSUSLDTRK-Suspend Tracking Load Addresses

Vol. 2D

6-72

XTEST-Test if in Transactional Execution

Opcode/Instruction

Op/

64/32bit

CPUID

Description

En

Mode

Feature

Support

Flag

NP 0F 01 D6

ZO

V/V

HLE or

Test if executing in a transactional region.

XTEST

RTM

Instruction Operand Encoding

Op/En

Operand 1

Operand2

Operand3

Operand4

ZO

N/A

N/A

N/A

N/A

Description

The XTEST instruction queries the transactional execution status. If the instruction executes inside a transaction-

ally executing RTM region or a transactionally executing HLE region, then the ZF flag is cleared, else it is set.

Operation

XTEST

IF (RTM_ACTIVE = 1 OR HLE_ACTIVE = 1)

THEN

ZF := 0

ELSE

ZF := 1

FI;

Flags Affected

The ZF flag is cleared if the instruction is executed transactionally; otherwise it is set to 1. The CF, OF, SF, PF, and

AF, flags are cleared.

Intel C/C++ Compiler Intrinsic Equivalent

XTEST int _xtest( void );

SIMD Floating-Point Exceptions

None.

Other Exceptions

#UD

If CPUID.07H.00H:EBX.HLE[4] = 0 and CPUID.07H.00H:EBX.RTM[11] = 0.

If LOCK prefix is used.

XTEST-Test if in Transactional Execution

Vol. 2D

6-73

CHAPTER 7

SAFER MODE EXTENSIONS REFERENCE

7.1

OVERVIEW

This chapter describes the Safer Mode Extensions (SMX) for the Intel 64 and IA-32 architectures. Safer Mode

Extensions (SMX) provide a programming interface for system software to establish a measured environment

within the platform to support trust decisions by end users. The measured environment includes:

• Measured launch of a system executive, referred to as a Measured Launched Environment (MLE)¹. The system

executive may be based on a Virtual Machine Monitor (VMM), a measured VMM is referred to as MVMM².

• Mechanisms to ensure the above measurement is protected and stored in a secure location in the platform.

• Protection mechanisms that allow the VMM to control attempts to modify the VMM.

The measurement and protection mechanisms used by a measured environment are supported by the capabilities

of an Intel^® Trusted Execution Technology (Intel^® TXT) platform:

• The SMX are the processor’s programming interface in an Intel TXT platform.

• The chipset in an Intel TXT platform provides enforcement of the protection mechanisms.

• Trusted Platform Module (TPM) 1.2 in the platform provides platform configuration registers (PCRs) to store

software measurement values.

7.2

SMX FUNCTIONALITY

SMX functionality is provided in an Intel 64 processor through the GETSEC instruction via leaf functions. The

GETSEC instruction supports multiple leaf functions. Leaf functions are selected by the value in EAX at the time

GETSEC is executed. Each GETSEC leaf function is documented separately in the reference pages with a unique

mnemonic (even though these mnemonics share the same opcode, 0F 37).

7.2.1

Detecting and Enabling SMX

Software can detect support for SMX operation using the CPUID instruction. If software executes CPUID with 1 in

EAX, a value of 1 in bit 6 of ECX indicates support for SMX operation (GETSEC is available), see CPUID instruction

for the layout of feature flags of reported by CPUID.01H:ECX.

System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1 before attempting to execute GETSEC.

Otherwise, execution of GETSEC results in the processor signaling an invalid opcode exception (#UD).

If the CPUID SMX feature flag is clear (CPUID.01H:ECX[6] = 0), attempting to set CR4.SMXE[Bit 14] results in a

general protection exception.

The IA32_FEATURE_CONTROL MSR (at address 03AH) provides feature control bits that configure operation of

VMX and SMX. These bits are documented in Table 7-1.

Table 7-1. Layout of IA32_FEATURE_CONTROL

Bit Position

Description

0

Lock bit (0 = unlocked, 1 = locked). When set to '1' further writes to this MSR are blocked.

1

Enable VMX in SMX operation.

2

Enable VMX outside SMX operation.

1. See the Intel® Trusted Execution Technology Measured Launched Environment Programming Guide.

2. An MVMM is sometimes referred to as a measured launched environment (MLE). See the Intel® Trusted Execution Technology Mea-

sured Launched Environment Programming Guide.

Vol. 2D

7-1

SAFER MODE EXTENSIONS REFERENCE

Table 7-1. Layout of IA32_FEATURE_CONTROL

7:3

Reserved

14:8

SENTER Local Function Enables: When set, each bit in the field represents an enable control for a corresponding

SENTER function.

15

SENTER Global Enable: Must be set to ‘1’ to enable operation of GETSEC[SENTER].

16

Reserved

17

SGX Launch Control Enable: Must be set to ‘1’ to enable runtime re-configuration of SGX Launch Control via the

IA32_SGXLEPUBKEYHASHn MSR.

18

SGX Global Enable: Must be set to ‘1’ to enable Intel SGX leaf functions.

19

Reserved

20

LMCE On: When set, system software can program the MSRs associated with LMCE to configure delivery of some

machine check exceptions to a single logical processor.

63:21

Reserved

• Bit 0 is a lock bit. If the lock bit is clear, an attempt to execute VMXON will cause a general-protection

exception. Attempting to execute GETSEC[SENTER] when the lock bit is clear will also cause a general-

protection exception. If the lock bit is set, WRMSR to the IA32_FEATURE_CONTROL MSR will cause a general-

protection exception. Once the lock bit is set, the MSR cannot be modified until a power-on reset. System BIOS

can use this bit to provide a setup option for BIOS to disable support for VMX, SMX or both VMX and SMX.

• Bit 1 enables VMX in SMX operation (between executing the SENTER and SEXIT leaves of GETSEC). If this bit

is clear, an attempt to execute VMXON in SMX will cause a general-protection exception if executed in SMX

operation. Attempts to set this bit on logical processors that do not support both VMX operation (Chapter 7,

“Safer Mode Extensions Reference”) and SMX operation cause general-protection exceptions.

• Bit 2 enables VMX outside SMX operation. If this bit is clear, an attempt to execute VMXON will cause a general-

protection exception if executed outside SMX operation. Attempts to set this bit on logical processors that do

not support VMX operation cause general-protection exceptions.

• Bits 8 through 14 specify enabled functionality of the SENTER leaf function. Each bit in the field represents an

enable control for a corresponding SENTER function. Only enabled SENTER leaf functionality can be used when

executing SENTER.

• Bits 15 specify global enable of all SENTER functionalities.

7.2.2

SMX Instruction Summary

System software must first query for available GETSEC leaf functions by executing GETSEC[CAPABILITIES]. The

CAPABILITIES leaf function returns a bit map of available GETSEC leaves. An attempt to execute an unsupported

leaf index results in an undefined opcode (#UD) exception.

Vol. 2D

7-2

SAFER MODE EXTENSIONS REFERENCE

7.2.2.1

GETSEC[CAPABILITIES]

The SMX functionality provides an architectural interface for newer processor generations to extend SMX capabili-

ties. Specifically, the GETSEC instruction provides a capability leaf function for system software to discover the

available GETSEC leaf functions that are supported in a processor. Table 7-2 lists the currently available GETSEC

leaf functions.

Table 7-2. GETSEC Leaf Functions

Index (EAX)

Leaf function

Description

0

CAPABILITIES

Returns the available leaf functions of the GETSEC instruction.

1

Undefined

Reserved

2

ENTERACCS

Enter

3

EXITAC

Exit

4

SENTER

Launch an MLE.

5

SEXIT

Exit the MLE.

6

PARAMETERS

Return SMX related parameter information.

7

SMCTRL

SMX mode control.

8

WAKEUP

Wake up sleeping processors in safer mode.

9 - (4G-1)

Undefined

Reserved

7.2.2.2

GETSEC[ENTERACCS]

The GETSEC[ENTERACCS] leaf enables authenticated code execution mode. The ENTERACCS leaf function

performs an authenticated code module load using the chipset public key as the signature verification. ENTERACCS

requires the existence of an Intel® Trusted Execution Technology capable chipset since it unlocks the chipset

private configuration register space after successful authentication of the loaded module. The physical base

address and size of the authenticated code module are specified as input register values in EBX and ECX, respec-

tively.

While in the authenticated code execution mode, certain processor state properties change. For this reason, the

time in which the processor operates in authenticated code execution mode should be limited to minimize impact

on external system events.

Upon entry into, the previous paging context is disabled (since the authenticated code module image is specified

with physical addresses and can no longer rely upon external memory-based page-table structures).

Prior to executing the GETSEC[ENTERACCS] leaf, system software must ensure the logical processor issuing

GETSEC[ENTERACCS] is the boot-strap processor (BSP), as indicated by IA32_APIC_BASE.BSP = 1. System soft-

ware must ensure other logical processors are in a suitable idle state and not marked as BSP.

The GETSEC[ENTERACCS] leaf may be used by different agents to load different authenticated code modules to

perform functions related to different aspects of a measured environment, for example system software and

Intel® TXT enabled BIOS may use more than one authenticated code modules.

7.2.2.3

GETSEC[EXITAC]

GETSEC[EXITAC] takes the processor out of authenticated code execution mode. When this instruction leaf is

executed, the contents of the authenticated code execution area are scrubbed and control is transferred to the

non-authenticated context defined by a near pointer passed with the GETSEC[EXITAC] instruction.

The authenticated code execution area is no longer accessible after completion of GETSEC[EXITAC]. RBX (or EBX)

holds the address of the near absolute indirect target to be taken.

Vol. 2D

7-3

SAFER MODE EXTENSIONS REFERENCE

GETSEC[CAPABILITIES]-Report the SMX Capabilities

Opcode

Instruction

Description

NP 0F 37

GETSEC[CAPABILITIES]

Report the SMX capabilities.

(EAX = 0)

The capabilities index is input in EBX with the result returned in EAX.

Description

The GETSEC[CAPABILITIES] function returns a bit vector of supported GETSEC leaf functions. The CAPABILITIES

leaf of GETSEC is selected with EAX set to 0 at entry. EBX is used as the selector for returning the bit vector field in

EAX. GETSEC[CAPABILITIES] may be executed at all privilege levels, but the CR4.SMXE bit must be set or an unde-

fined opcode exception (#UD) is returned.

With EBX = 0 upon execution of GETSEC[CAPABILITIES], EAX returns the a bit vector representing status on the

presence of a Intel^® TXT-capable chipset and the first 30 available GETSEC leaf functions. The format of the

returned bit vector is provided in Table 7-3.

If bit 0 is set to 1, then an Intel^® TXT-capable chipset has been sampled present by the processor. If bits in the range

of 1-30 are set, then the corresponding GETSEC leaf function is available. If the bit value at a given bit index is 0,

then the GETSEC leaf function corresponding to that index is unsupported and attempted execution results in a

#UD.

Bit 31 of EAX indicates if further leaf indexes are supported. If the Extended Leafs bit 31 is set, then additional leaf

functions are accessed by repeating GETSEC[CAPABILITIES] with EBX incremented by one. When the most signifi-

cant bit of EAX is not set, then additional GETSEC leaf functions are not supported; indexing EBX to a higher value

results in EAX returning zero.

Table 7-3. GETSEC Capability Result Encoding (EBX = 0)

Field

Bit position

Description

Chipset Present

0

Intel® TXT-capable chipset is present.

Undefined

1

Reserved

ENTERACCS

2

GETSEC[ENTERACCS] is available.

EXITAC

3

GETSEC[EXITAC] is available.

SENTER

4

GETSEC[SENTER] is available.

SEXIT

5

GETSEC[SEXIT] is available.

PARAMETERS

6

GETSEC[PARAMETERS] is available.

SMCTRL

7

GETSEC[SMCTRL] is available.

WAKEUP

8

GETSEC[WAKEUP] is available.

Undefined

30:9

Reserved

Extended Leafs

31

Reserved for extended information reporting of GETSEC capabilities.

GETSEC[CAPABILITIES]-Report the SMX Capabilities

Vol. 2D

7-7

SAFER MODE EXTENSIONS REFERENCE

GETSEC[ENTERACCS]-Execute Authenticated Chipset Code

Opcode

Instruction

Description

NP 0F 37

GETSEC[ENTERACCS]

Enter authenticated code execution mode.

(EAX = 2)

EBX holds the authenticated code module physical base address. ECX holds the authenticated

code module size (bytes).

Description

The GETSEC[ENTERACCS] function loads, authenticates, and executes an authenticated code module using an

Intel^® TXT platform chipset's public key. The ENTERACCS leaf of GETSEC is selected with EAX set to 2 at entry.

There are certain restrictions enforced by the processor for the execution of the GETSEC[ENTERACCS] instruction:

• Execution is not allowed unless the processor is in protected mode or IA-32e mode with CPL = 0 and

EFLAGS.VM = 0.

• Processor cache must be available and not disabled, that is, CR0.CD and CR0.NW bits must be 0.

• For processor packages containing more than one logical processor, CR0.CD is checked to ensure consistency

between enabled logical processors.

• For enforcing consistency of operation with numeric exception reporting using Interrupt 16, CR0.NE must be

set.

• An Intel TXT-capable chipset must be present as communicated to the processor by sampling of the power-on

configuration capability field after reset.

• The processor can not already be in authenticated code execution mode as launched by a previous

GETSEC[ENTERACCS] or GETSEC[SENTER] instruction without a subsequent exiting using GETSEC[EXITAC]).

• To avoid potential operability conflicts between modes, the processor is not allowed to execute this instruction

if it currently is in SMM or VMX operation.

• To ensure consistent handling of SIPI messages, the processor executing the GETSEC[ENTERACCS] instruction

must also be designated the BSP (boot-strap processor) as defined by IA32_APIC_BASE.BSP (Bit 8).

Failure to conform to the above conditions results in the processor signaling a general protection exception.

Prior to execution of the ENTERACCS leaf, other logical processors, i.e., RLPs, in the platform must be:

• Idle in a wait-for-SIPI state (as initiated by an INIT assertion or through reset for non-BSP designated

processors), or

• In the SENTER sleep state as initiated by a GETSEC[SENTER] from the initiating logical processor (ILP).

If other logical processor(s) in the same package are not idle in one of these states, execution of ENTERACCS

signals a general protection exception. The same requirement and action applies if the other logical processor(s) of

the same package do not have CR0.CD = 0.

A successful execution of ENTERACCS results in the ILP entering an authenticated code execution mode. Prior to

reaching this point, the processor performs several checks. These include:

• Establish and check the location and size of the specified authenticated code module to be executed by the

processor.

• Inhibit the ILP’s response to the external events: INIT, A20M, NMI, and SMI.

• Broadcast a message to enable protection of memory and I/O from other processor agents.

• Load the designated code module into an authenticated code execution area.

• Isolate the contents of the authenticated code execution area from further state modification by external

agents.

• Authenticate the authenticated code module.

• Initialize the initiating logical processor state based on information contained in the authenticated code module

header.

• Unlock the Intel^® TXT-capable chipset private configuration space and TPM locality 3 space.

GETSEC[ENTERACCS]-Execute Authenticated Chipset Code

Vol. 2D

7-10

SAFER MODE EXTENSIONS REFERENCE

A summary of the register state initialization after successful completion of GETSEC[ENTERACCS] is given for the

processor in Table 7-4. The paging is disabled upon entry into authenticated code execution mode. The authenti-

cated code module is loaded and initially executed using physical addresses. It is up to the system software after

execution of GETSEC[ENTERACCS] to establish a new (or restore its previous) paging environment with an appro-

priate mapping to meet new protection requirements. EBP is initialized to the authenticated code module base

physical address for initial execution in the authenticated environment. As a result, the authenticated code can

reference EBP for relative address based references, given that the authenticated code module must be position

independent.

Table 7-4. Register State Initialization After GETSEC[ENTERACCS]

Register State

Initialization Status

Comment

CR0

PG←0, AM←0, WP←0: Others unchanged

Paging, Alignment Check, Write-protection are

disabled.

CR4

MCE←0, CET←0, PCIDE←0, FRED←0: Others

Machine Check Exceptions, Control-flow

unchanged

Enforcement Technology, Process-context

Identifiers, and FRED disabled.

EFLAGS

00000002H

IA32_EFER

0H

IA-32e mode disabled.

EIP

AC.base + EntryPoint

AC.base is in EBX as input to GETSEC[ENTERACCS].

[E|R]BX

Pre-ENTERACCS state: Next [E|R]IP prior to

Carry forward 64-bit processor state across

GETSEC[ENTERACCS]

GETSEC[ENTERACCS].

ECX

Pre-ENTERACCS state: [31:16]=GDTR.limit;

Carry forward processor state across

[15:0]=CS.sel

GETSEC[ENTERACCS].

[E|R]DX

Pre-ENTERACCS state:

Carry forward 64-bit processor state across

GDTR base

GETSEC[ENTERACCS].

EBP

AC.base

CS

Sel=[SegSel], base=0, limit=FFFFFh, G=1, D=1, AR=9BH

DS

Sel=[SegSel] +8, base=0, limit=FFFFFh, G=1, D=1,

AR=93H

GDTR

Base= AC.base (EBX) + [GDTBasePtr], Limit=[GDTLimit]

DR7

00000400H

IA32_DEBUGCTL

0H

IA32_MISC_ENABLE

See Table 7-5 for example.

The number of initialized fields may change due to

processor implementation.

Performance

0H

counters and counter

control registers

The segmentation related processor state that has not been initialized by GETSEC[ENTERACCS] requires appro-

priate initialization before use. Since a new GDT context has been established, the previous state of the segment

selector values held in ES, SS, FS, GS, TR, and LDTR might not be valid.

The MSR IA32_EFER is also unconditionally cleared as part of the processor state initialized by ENTERACCS. Since

paging is disabled upon entering authenticated code execution mode, a new paging environment will have to be

reestablished in order to establish IA-32e mode while operating in authenticated code execution mode.

Debug exception and trap related signaling is also disabled as part of GETSEC[ENTERACCS]. This is achieved by

resetting DR7, TF in EFLAGs, and the MSR IA32_DEBUGCTL. These debug functions are free to be re-enabled once

supporting exception handler(s), descriptor tables, and debug registers have been properly initialized following

entry into authenticated code execution mode. Also, any pending single-step trap condition will have been cleared

upon entry into this mode.

GETSEC[ENTERACCS]-Execute Authenticated Chipset Code

Vol. 2D

7-12

SAFER MODE EXTENSIONS REFERENCE

Performance related counters and counter control registers are cleared as part of execution of ENTERACCS. This

implies any active performance counters at any time of ENTERACCS execution will be disabled. To reactive the

processor performance counters, this state must be re-initialized and re-enabled.

The IA32_MISC_ENABLE MSR is initialized upon entry into authenticated execution mode. Certain bits of this MSR

are preserved because preserving these bits may be important to maintain previously established platform settings

(See the footnote for Table 7-5.). The remaining bits are cleared for the purpose of establishing a more consistent

environment for the execution of authenticated code modules. One of the impacts of initializing this MSR is any

previous condition established by the MONITOR instruction will be cleared.

To support the possible return to the processor architectural state prior to execution of GETSEC[ENTERACCS],

certain critical processor state is captured and stored in the general- purpose registers at instruction completion.

[E|R]BX holds effective address ([E|R]IP) of the instruction that would execute next after GETSEC[ENTERACCS],

ECX[15:0] holds the CS selector value, ECX[31:16] holds the GDTR limit field, and [E|R]DX holds the GDTR base

field. The subsequent authenticated code can preserve the contents of these registers so that this state can be

manually restored if needed, prior to exiting authenticated code execution mode with GETSEC[EXITAC]. For the

processor state after exiting authenticated code execution mode, see the description of GETSEC[SEXIT].

Table 7-5. IA32_MISC_ENABLE MSR Initialization¹ by ENTERACCS and SENTER

Field

Bit position

Description

Fast strings enable

0

Clear to 0.

FOPCODE compatibility mode

2

Clear to 0.

enable

Thermal monitor enable

3

Set to 1 if other thermal monitor capability is not enabled.²

Split-lock disable

4

Clear to 0.

Bus lock on cache line splits

8

Clear to 0.

disable

Hardware prefetch disable

9

Clear to 0.

GV1/2 legacy enable

15

Clear to 0.

MONITOR/MWAIT s/m enable

18

Clear to 0.

Adjacent sector prefetch disable

19

Clear to 0.

NOTES:

1. The number of IA32_MISC_ENABLE fields that are initialized may vary due to processor implementations.

2. ENTERACCS (and SENTER) initialize the state of processor thermal throttling such that at least a minimum level is enabled. If thermal

throttling is already enabled when executing one of these GETSEC leaves, then no change in the thermal throttling control settings

will occur. If thermal throttling is disabled, then it will be enabled via setting of the thermal throttle control bit 3 as a result of execut-

ing these GETSEC leaves.

The IDTR will also require reloading with a new IDT context after entering authenticated code execution mode,

before any exceptions or the external interrupts INTR and NMI can be handled. Since external interrupts are re-

enabled at the completion of authenticated code execution mode (as terminated with EXITAC), it is recommended

that a new IDT context be established before this point. Until such a new IDT context is established, the

programmer must take care in not executing an INT n instruction or any other operation that would result in an

exception or trap signaling.

Prior to completion of the GETSEC[ENTERACCS] instruction and after successful authentication of the AC module,

the private configuration space of the Intel TXT chipset is unlocked. The authenticated code module alone can gain

access to this normally restricted chipset state for the purpose of securing the platform.

Once the authenticated code module is launched at the completion of GETSEC[ENTERACCS], it is free to enable

interrupts by setting EFLAGS.IF and enable NMI by execution of IRET. This presumes that it has re-established

interrupt handling support through initialization of the IDT, GDT, and corresponding interrupt handling code.

GETSEC[ENTERACCS]-Execute Authenticated Chipset Code

Vol. 2D

7-13

SAFER MODE EXTENSIONS REFERENCE

GETSEC[EXITAC]-Exit Authenticated Code Execution Mode

Opcode

Instruction

Description

NP 0F 37

GETSEC[EXITAC]

Exit authenticated code execution mode.

(EAX=3)

RBX holds the Near Absolute Indirect jump target and EDX hold the exit parameter flags.

Description

The GETSEC[EXITAC] leaf function exits the ILP out of authenticated code execution mode established by

GETSEC[ENTERACCS] or GETSEC[SENTER]. The EXITAC leaf of GETSEC is selected with EAX set to 3 at entry. EBX

(or RBX, if in 64-bit mode) holds the near jump target offset for where the processor execution resumes upon

exiting authenticated code execution mode. EDX contains additional parameter control information. Currently only

an input value of 0 in EDX is supported. All other EDX settings are considered reserved and result in a general

protection violation.

GETSEC[EXITAC] can only be executed if the processor is in protected mode with CPL = 0 and EFLAGS.VM = 0. The

processor must also be in authenticated code execution mode. To avoid potential operability conflicts between

modes, the processor is not allowed to execute this instruction if it is in SMM or in VMX operation. A violation of

these conditions results in a general protection violation.

Upon completion of the GETSEC[EXITAC] operation, the processor unmasks responses to external event signals

INIT#, NMI#, and SMI#. This unmasking is performed conditionally, based on whether the authenticated code

execution mode was entered via execution of GETSEC[SENTER] or GETSEC[ENTERACCS]. If the processor is in

authenticated code execution mode due to the execution of GETSEC[SENTER], then these external event signals

will remain masked. In this case, A20M is kept disabled in the measured environment until the measured environ-

ment executes GETSEC[SEXIT]. INIT# is unconditionally unmasked by EXITAC. Note that any events that are

pending, but have been blocked while in authenticated code execution mode, will be recognized at the completion

of the GETSEC[EXITAC] instruction if the pin event is unmasked.

The intent of providing the ability to optionally leave the pin events SMI#, and NMI# masked is to support the

completion of a measured environment bring-up that makes use of VMX. In this envisioned security usage

scenario, these events will remain masked until an appropriate virtual machine has been established in order to

field servicing of these events in a safer manner. Details on when and how events are masked and unmasked in

VMX operation are described in Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C. It

should be cautioned that if no VMX environment is to be activated following GETSEC[EXITAC], that these events

will remain masked until the measured environment is exited with GETSEC[SEXIT]. If this is not desired then the

GETSEC function SMCTRL(0) can be used for unmasking SMI# in this context. NMI# can be correspondingly

unmasked by execution of IRET.

A successful exit of the authenticated code execution mode requires the ILP to perform additional steps as outlined

below:

• Invalidate the contents of the internal authenticated code execution area.

• Invalidate processor TLBs.

• Clear the internal processor AC Mode indicator flag.

• Re-lock the TPM locality 3 space.

• Unlock the Intel^® TXT-capable chipset memory and I/O protections to allow memory and I/O activity by other

processor agents.

• Perform a near absolute indirect jump to the designated instruction location.

The content of the authenticated code execution area is invalidated by hardware in order to protect it from further

use or visibility. This internal processor storage area can no longer be used or relied upon after GETSEC[EXITAC].

Data structures need to be re-established outside of the authenticated code execution area if they are to be refer-

enced after EXITAC. Since addressed memory content formerly mapped to the authenticated code execution area

may no longer be coherent with external system memory after EXITAC, processor TLBs in support of linear to phys-

ical address translation are also invalidated.

GETSEC[EXITAC]-Exit Authenticated Code Execution Mode

Vol. 2D

7-18

SAFER MODE EXTENSIONS REFERENCE

GETSEC[SENTER]-Enter a Measured Environment

Opcode

Instruction

Description

NP 0F 37

GETSEC[SENTER]

Launch a measured environment.

(EAX=4)

EBX holds the SINIT authenticated code module physical base address.

ECX holds the SINIT authenticated code module size (bytes).

EDX controls the level of functionality supported by the measured environment launch.

Description

The GETSEC[SENTER] instruction initiates the launch of a measured environment and places the initiating logical

processor (ILP) into the authenticated code execution mode. The SENTER leaf of GETSEC is selected with EAX set

to 4 at execution. The physical base address of the AC module to be loaded and authenticated is specified in EBX.

The size of the module in bytes is specified in ECX. EDX controls the level of functionality supported by the

measured environment launch. To enable the full functionality of the protected environment launch, EDX must be

initialized to zero.

The authenticated code base address and size parameters (in bytes) are passed to the GETSEC[SENTER] instruc-

tion using EBX and ECX respectively. The ILP evaluates the contents of these registers according to the rules for the

AC module address in GETSEC[ENTERACCS]. AC module execution follows the same rules, as set by

GETSEC[ENTERACCS].

The launching software must ensure that the TPM.ACCESS_0.activeLocality bit is clear before executing the

GETSEC[SENTER] instruction.

There are restrictions enforced by the processor for execution of the GETSEC[SENTER] instruction:

• Execution is not allowed unless the processor is in protected mode or IA-32e mode with CPL = 0 and

EFLAGS.VM = 0.

• Processor cache must be available and not disabled using the CR0.CD and NW bits.

• For enforcing consistency of operation with numeric exception reporting using Interrupt 16, CR0.NE must be

set.

• An Intel TXT-capable chipset must be present as communicated to the processor by sampling of the power-on

configuration capability field after reset.

• The processor can not be in authenticated code execution mode or already in a measured environment (as

launched by a previous GETSEC[ENTERACCS] or GETSEC[SENTER] instruction).

• To avoid potential operability conflicts between modes, the processor is not allowed to execute this instruction

if it currently is in SMM or VMX operation.

• To ensure consistent handling of SIPI messages, the processor executing the GETSEC[SENTER] instruction

must also be designated the BSP (boot-strap processor) as defined by IA32_APIC_BASE.BSP (Bit 8).

• EDX must be initialized to a setting supportable by the processor. Unless enumeration by the GETSEC[PARAM-

ETERS] leaf reports otherwise, only a value of zero is supported.

Failure to abide by the above conditions results in the processor signaling a general protection violation.

This instruction leaf starts the launch of a measured environment by initiating a rendezvous sequence for all logical

processors in the platform. The rendezvous sequence involves the initiating logical processor sending a message

(by executing GETSEC[SENTER]) and other responding logical processors (RLPs) acknowledging the message,

thus synchronizing the RLP(s) with the ILP.

In response to a message signaling the completion of rendezvous, RLPs clear the bootstrap processor indicator flag

(IA32_APIC_BASE.BSP) and enter an SENTER sleep state. In this sleep state, RLPs enter an idle processor condi-

tion while waiting to be activated after a measured environment has been established by the system executive.

RLPs in the SENTER sleep state can only be activated by the GETSEC leaf function WAKEUP in a measured environ-

ment.

GETSEC[SENTER]-Enter a Measured Environment

Vol. 2D

7-22

SAFER MODE EXTENSIONS REFERENCE

Table 7-6. Register State Initialization After GETSEC[SENTER] and GETSEC[WAKEUP]

Register State

ILP after GETSEC[SENTER]

RLP after GETSEC[WAKEUP]

CR0

PG←0, AM←0, WP←0; Others unchanged

PG←0, CD←0, NW←0, AM←0, WP←0; PE←1, NE←1

CR4

00004000H

00004000H

EFLAGS

00000002H

00000002H

IA32_EFER

0H

0

EIP

[EntryPoint from MLE header¹]

[LT.MLE.JOIN + 12]

EBX

Unchanged [SINIT.BASE]

Unchanged

EDX

SENTER control flags

Unchanged

EBP

SINIT.BASE

Unchanged

CS

Sel=[SINIT SegSel], base=0, limit=FFFFFh, G=1,

Sel = [LT.MLE.JOIN + 8], base = 0, limit = FFFFFH, G =

D=1, AR=9BH

1, D = 1, AR = 9BH

DS, ES, SS

Sel=[SINIT SegSel] +8, base=0, limit=FFFFFh, G=1,

Sel = [LT.MLE.JOIN + 8] +8, base = 0, limit = FFFFFH, G

D=1, AR=93H

= 1, D = 1, AR = 93H

GDTR

Base= SINIT.base (EBX) + [SINIT.GDTBasePtr],

Base = [LT.MLE.JOIN + 4], Limit = [LT.MLE.JOIN]

Limit=[SINIT.GDTLimit]

DR7

00000400H

00000400H

IA32_DEBUGCTL

0H

0H

Performance counters

0H

0H

and counter control

registers

IA32_MISC_ENABLE

See Table 7-5

See Table 7-5

IA32_SMM_MONITOR_

Bit 2←0

Bit 2←0

CTL

NOTES:

1. See the Intel® Trusted Execution Technology Measured Launched Environment Programming Guide for MLE header format.

Segmentation related processor state that has not been initialized by GETSEC[SENTER] requires appropriate

initialization before use. Since a new GDT context has been established, the previous state of the segment selector

values held in FS, GS, TR, and LDTR may no longer be valid. The IDTR will also require reloading with a new IDT

context after launching the measured environment before exceptions or the external interrupts INTR and NMI can

be handled. In the meantime, the programmer must take care in not executing an INT n instruction or any other

condition that would result in an exception or trap signaling.

Debug exception and trap related signaling is also disabled as part of execution of GETSEC[SENTER]. This is

achieved by clearing DR7, TF in EFLAGs, and the MSR IA32_DEBUGCTL as defined in Table 7-6. These can be re-

enabled once supporting exception handler(s), descriptor tables, and debug registers have been properly re-initial-

ized following SENTER. Also, any pending single-step trap condition will be cleared at the completion of SENTER for

both the ILP and RLP(s).

Performance related counters and counter control registers are cleared as part of execution of SENTER on both the

ILP and RLP. This implies any active performance counters at the time of SENTER execution will be disabled. To

reactive the processor performance counters, this state must be re-initialized and re-enabled.

Since MCE along with all other state bits (with the exception of SMXE) are cleared in CR4 upon execution of SENTER

processing, any enabled machine check error condition that occurs will result in the processor performing the TXT-

shutdown action. This also applies to an RLP while in the SENTER sleep state. For each logical processor CR4.MCE

must be reestablished with a valid machine check exception handler to otherwise avoid an TXT-shutdown under

such conditions.

GETSEC[SENTER]-Enter a Measured Environment

Vol. 2D

7-25

SAFER MODE EXTENSIONS REFERENCE

GETSEC[SEXIT]-Exit Measured Environment

Opcode

Instruction

Description

NP 0F 37

GETSEC[SEXIT]

Exit measured environment.

(EAX=5)

Description

The GETSEC[SEXIT] instruction initiates an exit of a measured environment established by GETSEC[SENTER]. The

SEXIT leaf of GETSEC is selected with EAX set to 5 at execution. This instruction leaf sends a message to all logical

processors in the platform to signal the measured environment exit.

There are restrictions enforced by the processor for the execution of the GETSEC[SEXIT] instruction:

• Execution is not allowed unless the processor is in protected mode (CR0.PE = 1) with CPL = 0 and EFLAGS.VM

= 0.

• The processor must be in a measured environment as launched by a previous GETSEC[SENTER] instruction,

but not still in authenticated code execution mode.

• To avoid potential interoperability conflicts between modes, the processor is not allowed to execute this

instruction if it currently is in SMM or in VMX operation.

• To ensure consistent handling of SIPI messages, the processor executing the GETSEC[SEXIT] instruction must

also be designated the BSP (bootstrap processor) as defined by the register bit IA32_APIC_BASE.BSP (bit 8).

Failure to abide by the above conditions results in the processor signaling a general protection violation.

This instruction initiates a sequence to rendezvous the RLPs with the ILP. It then clears the internal processor flag

indicating the processor is operating in a measured environment.

In response to a message signaling the completion of rendezvous, all RLPs restart execution with the instruction

that was to be executed at the time GETSEC[SEXIT] was recognized. This applies to all processor conditions, with

the following exceptions:

• If an RLP executed HLT and was in this halt state at the time of the message initiated by GETSEC[SEXIT], then

execution resumes in the halt state.

• If an RLP was executing MWAIT, then a message initiated by GETSEC[SEXIT] causes an exit of the MWAIT

state, falling through to the next instruction.

• If an RLP was executing an intermediate iteration of a string instruction, then the processor resumes execution

of the string instruction at the point which the message initiated by GETSEC[SEXIT] was recognized.

• If an RLP is still in the SENTER sleep state (never awakened with GETSEC[WAKEUP]), it will be sent to the wait-

for-SIPI state after first clearing the bootstrap processor indicator flag (IA32_APIC_BASE.BSP) and any

pending SIPI state. In this case, such RLPs are initialized to an architectural state consistent with having taken

a soft reset using the INIT# pin.

Prior to completion of the GETSEC[SEXIT] operation, both the ILP and any active RLPs unmask the response of the

external event signals INIT#, A20M, NMI#, and SMI#. This unmasking is performed unconditionally to recognize

pin events which are masked after a GETSEC[SENTER]. The state of A20M is unmasked, as the A20M pin is not

recognized while the measured environment is active.

On a successful exit of the measured environment, the ILP re-locks the Intel® TXT-capable chipset private config-

uration space. GETSEC[SEXIT] does not affect the content of any PCR.

At completion of GETSEC[SEXIT] by the ILP, execution proceeds to the next instruction. Since EFLAGS and the

debug register state are not modified by this instruction, a pending trap condition is free to be signaled if previously

enabled.

GETSEC[SEXIT]-Exit Measured Environment

Vol. 2D

7-31

SAFER MODE EXTENSIONS REFERENCE

GETSEC[PARAMETERS]-Report the SMX Parameters

Opcode

Instruction

Description

NP 0F 37

GETSEC[PARAMETERS]

Report the SMX parameters.

(EAX=6)

The parameters index is input in EBX with the result returned in EAX, EBX, and ECX.

Description

The GETSEC[PARAMETERS] instruction returns specific parameter information for SMX features supported by the

processor. Parameter information is returned in EAX, EBX, and ECX, with the input parameter selected using EBX.

Software retrieves parameter information by searching with an input index for EBX starting at 0, and then reading

the returned results in EAX, EBX, and ECX. EAX[4:0] is designated to return a parameter type field indicating if a

parameter is available and what type it is. If EAX[4:0] is returned with 0, this designates a null parameter and indi-

cates no more parameters are available.

Table 7-7 defines the parameter types supported in current and future implementations.

Table 7-7. SMX Reporting Parameters Format

Parameter

Type EAX[4:0]

Parameter Description

EAX[31:5]

EBX[31:0]

ECX[31:0]

0

NULL

Reserved (0 returned)

Reserved (unmodified)

Reserved (unmodified)

1

Supported AC module

Reserved (0 returned)

Version comparison mask

Version numbers

versions

supported

2

Max size of authenticated

Multiply by 32 for size in

Reserved (unmodified)

Reserved (unmodified)

code execution area

bytes

3

External memory types

Memory type bit mask

Reserved (unmodified)

Reserved (unmodified)

supported during AC mode

4

Selective SENTER

EAX[14:8] correspond to

Reserved (unmodified)

Reserved (unmodified)

functionality control

available SENTER function

disable controls

5

TXT extensions support

TXT Feature Extensions

Reserved

Reserved

Flags (see Table )

6-31

Undefined

Reserved (unmodified)

Reserved (unmodified)

Reserved (unmodified)

Table 7-8. TXT Feature Extensions Flags

Bit

Definition

Description

5

Processor based S-CRTM

Returns 1 if this processor implements a processor-rooted S-CRTM capability and 0 if

support

not (S-CRTM is rooted in BIOS).

This flag cannot be used to infer whether the chipset supports TXT or whether the

processor support SMX.

6

Machine Check Handling

Returns 1 if it machine check status registers can be preserved through ENTERACCS

and SENTER. If this bit is 1, the caller of ENTERACCS and SENTER is not required to

clear machine check error status bits before invoking these GETSEC leaves.

If this bit returns 0, the caller of ENTERACCS and SENTER must clear all machine

check error status bits before invoking these GETSEC leaves.

31:7

Reserved

Reserved for future use. Will return 0.

GETSEC[PARAMETERS]-Report the SMX Parameters

Vol. 2D

7-34

SAFER MODE EXTENSIONS REFERENCE

Supported AC module versions (as defined by the AC module HeaderVersion field) can be determined for a partic-

ular SMX capable processor by the type 1 parameter. Using EBX to index through the available parameters reported

by GETSEC[PARAMETERS] for each unique parameter set returned for type 1, software can determine the

complete list of AC module version(s) supported.

For each parameter set, EBX returns the comparison mask and ECX returns the available HeaderVersion field

values supported, after AND'ing the target HeaderVersion with the comparison mask. Software can then determine

if a particular AC module version is supported by following the pseudo-code search routine given below:

parameter_search_index= 0

do {

EBX= parameter_search_index++

EAX= 6

GETSEC

if (EAX[4:0] = 1) {

if ((version_query & EBX) = ECX) {

version_is_supported= 1

break

}

}

} while (EAX[4:0] ≠ 0)

If only AC modules with a HeaderVersion of 0 are supported by the processor, then only one parameter set of type

1 will be returned, as follows: EAX = 00000001H,

EBX = FFFFFFFFH and ECX = 00000000H.

The maximum capacity for an authenticated code execution area supported by the processor is reported with the

parameter type of 2. The maximum supported size in bytes is determined by multiplying the returned size in

EAX[31:5] by 32. Thus, for a maximum supported authenticated RAM size of 32KBytes, EAX returns with

00008002H.

Supportable memory types for memory mapped outside of the authenticated code execution area are reported

with the parameter type of 3. While is active, as initiated by the GETSEC functions SENTER and ENTERACCS and

terminated by EXITAC, there are restrictions on what memory types are allowed for the rest of system memory. It

is the responsibility of the system software to initialize the memory type range register (MTRR) MSRs and/or the

page attribute table (PAT) to only map memory types consistent with the reporting of this parameter. The reporting

of supportable memory types of external memory is indicated using a bit map returned in EAX[31:8]. These bit

positions correspond to the memory type encodings defined for the MTRR MSR and PAT programming. See

Table 7-9.

The parameter type of 4 is used for enumerating the availability of selective GETSEC[SENTER] function disable

controls. If a 1 is reported in bits 14:8 of the returned parameter EAX, then this indicates a disable control capa-

bility exists with SENTER for a particular function. The enumerated field in bits 14:8 corresponds to use of the EDX

input parameter bits 6:0 for SENTER. If an enumerated field bit is set to 1, then the corresponding EDX input

parameter bit of EDX may be set to 1 to disable that designated function. If the enumerated field bit is 0 or this

parameter is not reported, then no disable capability exists with the corresponding EDX input parameter for

SENTER, and EDX bit(s) must be cleared to 0 to enable execution of SENTER. If no selective disable capability for

SENTER exists as enumerated, then the corresponding bits in the IA32_FEATURE_CONTROL MSR bits 14:8 must

also be programmed to 1 if the SENTER global enable bit 15 of the MSR is set. This is required to enable future

extensibility of SENTER selective disable capability with respect to potentially separate software initialization of the

MSR.

Table 7-9. External Memory Types Using Parameter 3

EAX Bit Position

Parameter Description

8

Uncacheable (UC)

9

Write Combining (WC)

11:10

Reserved

12

Write-through (WT)

GETSEC[PARAMETERS]-Report the SMX Parameters

Vol. 2D

7-35

SAFER MODE EXTENSIONS REFERENCE

Table 7-9. External Memory Types Using Parameter 3 (Contd.)

13

Write-protected (WP)

14

Write-back (WB)

31:15

Reserved

If the GETSEC[PARAMETERS] leaf or specific parameter is not present for a given SMX capable processor, then

default parameter values should be assumed. These are defined in Table 7-10.

Table 7-10. Default Parameter Values

Parameter Type EAX[4:0]

Default Setting

Parameter Description

1

0.0 only

Supported AC module versions.

2

32 KBytes

Authenticated code execution area size.

3

UC only

External memory types supported during AC execution mode.

4

None

Available SENTER selective disable controls.

Operation

(* example of a processor supporting only a 0.0 HeaderVersion, 32K ACRAM size, memory types UC and WC *)

IF (CR4.SMXE=0)

THEN #UD;

ELSE IF (in VMX non-root operation)

THEN VM Exit (reason=”GETSEC instruction”);

ELSE IF (GETSEC leaf unsupported)

THEN #UD;

(* example of a processor supporting a 0.0 HeaderVersion *)

IF (EBX=0) THEN

EAX := 00000001h;

EBX := FFFFFFFFh;

ECX := 00000000h;

ELSE IF (EBX=1)

(* example of a processor supporting a 32K ACRAM size *)

THEN EAX := 00008002h;

ESE IF (EBX= 2)

(* example of a processor supporting external memory types of UC and WC *)

THEN EAX := 00000303h;

ESE IF (EBX= other value(s) less than unsupported index value)

(* EAX value varies. Consult Table 7-7 and Table *)

ELSE (* unsupported index*)

EAX := 00000000h;

END;

Flags Affected

None.

Use of Prefixes

LOCK

Causes #UD.

REP*

Cause #UD (includes REPNE/REPNZ and REP/REPE/REPZ).

Operand size

Causes #UD.

GETSEC[PARAMETERS]-Report the SMX Parameters

Vol. 2D

7-36

SAFER MODE EXTENSIONS REFERENCE

GETSEC[SMCTRL]-SMX Mode Control

Opcode

Instruction

Description

NP 0F 37 (EAX = 7)

GETSEC[SMCTRL]

Perform specified SMX mode control as selected with the input EBX.

Description

The GETSEC[SMCTRL] instruction is available for performing certain SMX specific mode control operations. The

operation to be performed is selected through the input register EBX. Currently only an input value in EBX of 0 is

supported. All other EBX settings will result in the signaling of a general protection violation.

If EBX is set to 0, then the SMCTRL leaf is used to re-enable SMI events. SMI is masked by the ILP executing the

GETSEC[SENTER] instruction (SMI is also masked in the responding logical processors in response to SENTER

rendezvous messages.). The determination of when this instruction is allowed and the events that are unmasked

is dependent on the processor context (See Table 7-11). For brevity, the usage of SMCTRL where EBX=0 will be

referred to as GETSEC[SMCTRL(0)].

As part of support for launching a measured environment, the SMI, NMI, and INIT events are masked after

GETSEC[SENTER], and remain masked after exiting authenticated execution mode. Unmasking these events

should be accompanied by securely enabling these event handlers. These security concerns can be addressed in

VMX operation by a MVMM.

The VM monitor can choose two approaches:

• In a dual monitor approach, the executive software will set up an SMM monitor in parallel to the executive VMM

(i.e., the MVMM), see Chapter 34, “System Management Mode‚” of Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 3C. The SMM monitor is dedicated to handling SMI events without compromising

the security of the MVMM. This usage model of handling SMI while a measured environment is active does not

require the use of GETSEC[SMCTRL(0)] as event re-enabling after the VMX environment launch is handled

implicitly and through separate VMX based controls.

• If a dedicated SMM monitor will not be established and SMIs are to be handled within the measured

environment, then GETSEC[SMCTRL(0)] can be used by the executive software to re-enable SMI that has been

masked as a result of SENTER.

Table 7-11 defines the processor context in which GETSEC[SMCTRL(0)] can be used and which events will be

unmasked. Note that the events that are unmasked are dependent upon the currently operating processor context.

Table 7-11. Supported Actions for GETSEC[SMCTRL(0)]

ILP Mode of Operation

SMCTRL execution action

In VMX non-root operation

VM exit

SENTERFLAG = 0

#GP(0), illegal context

In authenticated code execution mode

#GP(0), illegal context

(ACMODEFLAG = 1)

SENTERFLAG = 1, not in VMX operation, not in SMM

Unmask SMI

SENTERFLAG = 1, in VMX root operation, not in

Unmask SMI if SMM monitor is not configured, otherwise #GP(0)

SMM

SENTERFLAG = 1, In VMX root operation, in SMM

#GP(0), illegal context

GETSEC[SMCTRL]-SMX Mode Control

Vol. 2D

7-38

SAFER MODE EXTENSIONS REFERENCE

GETSEC[WAKEUP]-Wake Up Sleeping Processors in Measured Environment

Opcode

Instruction

Description

NP 0F 37

GETSEC[WAKEUP]

Wake up the responding logical processors from the SENTER sleep state.

(EAX=8)

Description

The GETSEC[WAKEUP] leaf function broadcasts a wake-up message to all logical processors currently in the

SENTER sleep state. This GETSEC leaf must be executed only by the ILP, in order to wake-up the RLPs. Responding

logical processors (RLPs) enter the SENTER sleep state after completion of the SENTER rendezvous sequence.

The GETSEC[WAKEUP] instruction may only be executed:

• In a measured environment as initiated by execution of GETSEC[SENTER].

• Outside of authenticated code execution mode.

• Execution is not allowed unless the processor is in protected mode with CPL = 0 and EFLAGS.VM = 0.

• In addition, the logical processor must be designated as the boot-strap processor as configured by setting

IA32_APIC_BASE.BSP = 1.

If these conditions are not met, attempts to execute GETSEC[WAKEUP] result in a general protection violation.

An RLP exits the SENTER sleep state and start execution in response to a WAKEUP signal initiated by ILP’s execu-

tion of GETSEC[WAKEUP]. The RLP retrieves a pointer to a data structure that contains information to enable

execution from a defined entry point. This data structure is located using a physical address held in the Intel^® TXT-

capable chipset configuration register LT.MLE.JOIN. The register is publicly writable in the chipset by all processors

and is not restricted by the Intel^® TXT-capable chipset configuration register lock status. The format of this data

structure is defined in Table 7-12.

Table 7-12. RLP MVMM JOIN Data Structure

Offset

Field

0

GDT limit

4

GDT base pointer

8

Segment selector initializer

12

EIP

The MLE JOIN data structure contains the information necessary to initialize RLP processor state and permit the

processor to join the measured environment. The GDTR, LIP, and CS, DS, SS, and ES selector values are initialized

using this data structure. The CS selector index is derived directly from the segment selector initializer field; DS,

SS, and ES selectors are initialized to CS+8. The segment descriptor fields are initialized implicitly with BASE = 0,

LIMIT = FFFFFH, G = 1, D = 1, P = 1, S = 1; read/write/access for DS, SS, and ES; and execute/read/access for

CS. It is the responsibility of external software to establish a GDT pointed to by the MLE JOIN data structure that

contains descriptor entries consistent with the implicit settings initialized by the processor (see Table 7-6). Certain

states from the content of Table 7-12 are checked for consistency by the processor prior to execution. A failure of

any consistency check results in the RLP aborting entry into the protected environment and signaling an Intel®

TXT shutdown condition. The specific checks performed are documented later in this section. After successful

completion of processor consistency checks and subsequent initialization, RLP execution in the measured environ-

ment begins from the entry point at offset 12 (as indicated in Table 7-12).

GETSEC[WAKEUP]-Wake Up Sleeping Processors in Measured Environment

Vol. 2D

7-41

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

PREFETCHWT1-Prefetch Vector Data Into Caches With Intent to Write and T1 Hint

Opcode/

Op/

64/32 bit

CPUID Feature

Description

Instruction

En

Mode

Flag

Support

0F 0D /2

M

V/V

PREFETCHWT1

Move data from m8 closer to the processor using T1 hint

PREFETCHWT1 m8

with intent to write.

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (r)

N/A

N/A

N/A

Description

Fetches the line of data from memory that contains the byte specified with the source operand to a location in the

cache hierarchy specified by an intent to write hint (so that data is brought into ‘Exclusive’ state via a request for

ownership) and a locality hint:

• T1 (temporal data with respect to first level cache)-prefetch data into the second level cache.

The source operand is a byte memory location. (The locality hints are encoded into the machine level instruction

using bits 3 through 5 of the ModR/M byte. Use of any ModR/M value other than the specified ones will lead to

unpredictable behavior.)

If the line selected is already present in the cache hierarchy at a level closer to the processor, no data movement

occurs. Prefetches from uncacheable or WC memory are ignored.

The PREFETCHWT1 instruction is merely a hint and does not affect program behavior. If executed, this instruction

moves data closer to the processor in anticipation of future use.

The implementation of prefetch locality hints is implementation-dependent, and can be overloaded or ignored by a

processor implementation. The amount of data prefetched is also processor implementation-dependent. It will,

however, be a minimum of 32 bytes. Additional details of the implementation-dependent locality hints are

described in Section 9.5, “Memory Optimization Using Prefetch” of the Intel® 64 and IA-32 Architectures Optimi-

zation Reference Manual.

It should be noted that processors are free to speculatively fetch and cache data from system memory regions that

are assigned a memory-type that permits speculative reads (that is, the WB, WC, and WT memory types). A

PREFETCHWT1 instruction is considered a hint to this speculative behavior. Because this speculative fetching can

occur at any time and is not tied to instruction execution, a PREFETCHWT1 instruction is not ordered with respect

to the fence instructions (MFENCE, SFENCE, and LFENCE) or locked memory references. A PREFETCHWT1 instruc-

tion is also unordered with respect to CLFLUSH and CLFLUSHOPT instructions, other PREFETCHWT1 instructions, or

any other general instruction. It is ordered with respect to serializing instructions such as CPUID, WRMSR, OUT,

and MOV CR.

This instruction’s operation is the same in non-64-bit modes and 64-bit mode.

Operation

PREFETCH(mem, Level, State) Prefetches a byte memory location pointed by ‘mem’ into the cache level specified by ‘Level’; a request

for exclusive/ownership is done if ‘State’ is 1. Note that the memory location ignore cache line splits. This operation is considered a

hint for the processor and may be skipped depending on implementation.

Prefetch (m8, Level = 1, EXCLUSIVE=1);

Flags Affected

All flags are affected.

C/C++ Compiler Intrinsic Equivalent

void _mm_prefetch( char const *, int hint= _MM_HINT_ET1);

PREFETCHWT1-Prefetch Vector Data Into Caches With Intent to Write and T1 Hint

Vol. 2D

8-2

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

V4FMADDPS/V4FNMADDPS-Packed Single Precision Floating-Point Fused Multiply-Add

(4-Iterations)

Opcode/

Op/

64/32

CPUID Feature

Description

Instruction

En

bit Mode

Flag

Support

EVEX.512.F2.0F38.W0 9A /r

A

V/V

AVX512_4FMAPS

Multiply packed single precision floating-point

V4FMADDPS zmm1{k1}{z}, zmm2+3,

values from source register block indicated by

m128

zmm2 by values from m128 and accumulate the

result in zmm1.

EVEX.512.F2.0F38.W0 AA /r

A

V/V

AVX512_4FMAPS

Multiply and negate packed single precision

V4FNMADDPS zmm1{k1}{z},

floating-point values from source register block

zmm2+3, m128

indicated by zmm2 by values from m128 and

accumulate the result in zmm1.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1_4X

ModRM:reg (r, w)

EVEX.vvvv (r)

ModRM:r/m (r)

N/A

Description

This instruction computes 4 sequential packed fused single precision floating-point multiply-add instructions with a

sequentially selected memory operand in each of the four steps.

In the above box, the notation of “+3” is used to denote that the instruction accesses 4 source registers based on

that operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.

This instruction supports memory fault suppression. The entire memory operand is loaded if any of the 16 lowest

significant mask bits is set to 1 or if a “no masking” encoding is used.

The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation

portion of this instruction.

Rounding is performed at every FMA (fused multiply and add) boundary. Exceptions are also taken sequentially.

Pre- and post-computational exceptions of the first FMA take priority over the pre- and post-computational excep-

tions of the second FMA, etc.

V4FMADDPS/V4FNMADDPS-Packed Single Precision Floating-Point Fused Multiply-Add (4-Iterations)

Vol. 2D

8-4

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

V4FMADDSS/V4FNMADDSS-Scalar Single Precision Floating-Point Fused Multiply-Add

(4-Iterations)

Opcode/

Op/

64/32

CPUID Feature

Description

Instruction

En

bit Mode

Flag

Support

EVEX.LLIG.F2.0F38.W0 9B /r

A

V/V

AVX512_4FMAPS

Multiply scalar single precision floating-point

V4FMADDSS xmm1{k1}{z},

values from source register block indicated by

xmm2+3, m128

xmm2 by values from m128 and accumulate the

result in xmm1.

EVEX.LLIG.F2.0F38.W0 AB /r

A

V/V

AVX512_4FMAPS

Multiply and negate scalar single precision

V4FNMADDSS xmm1{k1}{z},

floating-point values from source register block

xmm2+3, m128

indicated by xmm2 by values from m128 and

accumulate the result in xmm1.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1_4X

ModRM:reg (r, w)

EVEX.vvvv (r)

ModRM:r/m (r)

N/A

Description

This instruction computes 4 sequential scalar fused single precision floating-point multiply-add instructions with a

sequentially selected memory operand in each of the four steps.

In the above box, the notation of “+3” is used to denote that the instruction accesses 4 source registers based that

operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.

This instruction supports memory fault suppression. The entire memory operand is loaded if the least significant

mask bit is set to 1 or if a “no masking” encoding is used.

The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation

portion of this instruction.

Rounding is performed at every FMA boundary. Exceptions are also taken sequentially. Pre- and post-computa-

tional exceptions of the first FMA take priority over the pre- and post-computational exceptions of the second FMA,

etc.

Operation

src_reg_id is the 5 bit index of the vector register specified in the instruction as the src1 register.

define NFMA_SS(vl, dest, k1, msrc, regs_loaded, src_base, posneg):

tmpdest := dest

// reg[] is an array representing the SIMD register file.

IF k1[0] or *no writemask*:

FOR j := 0 to regs_loaded - 1:

IF posneg = 0:

tmpdest.single[0] := RoundFPControl_MXCSR(tmpdest.single[0] - reg[src_base + j ].single[0] * msrc.single[j])

ELSE:

tmpdest.single[0] := RoundFPControl_MXCSR(tmpdest.single[0] + reg[src_base + j ].single[0] * msrc.single[j])

ELSE IF *zeroing*:

tmpdest.single[0] := 0

dest := tmpdst

dest[MAX_VL-1:VL] := 0

V4FMADDSS/V4FNMADDSS-Scalar Single Precision Floating-Point Fused Multiply-Add (4-Iterations)

Vol. 2D

8-6

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VEXP2PD-Approximation to the Exponential 2^x of Packed Double Precision Floating-Point

Values With Less Than 2^-23 Relative Error

Opcode/

Op /

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.512.66.0F38.W1 C8 /r

A

V/V

AVX512ER

Computes approximations to the exponential 2^x (with less

VEXP2PD zmm1 {k1}{z},

than 2^-23 of maximum relative error) of the packed double

zmm2/m512/m64bcst {sae}

precision floating-point values from zmm2/m512/m64bcst and

stores the floating-point result in zmm1with writemask k1.

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Full

ModRM:reg (r, w)

ModRM:r/m (r)

N/A

N/A

Description

Computes the approximate base-2 exponential evaluation of the double precision floating-point values in the

source operand (the second operand) and stores the results to the destination operand (the first operand) using

the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.

Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results

are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.

The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit

memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.

EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.

A numerically exact implementation of VEXP2xx can be found at https://software.intel.com/en-us/articles/refer-

ence-implementations-for-IA-approximation-instructions-vrcp14-vrsqrt14-vrcp28-vrsqrt28-vexp2.

Operation

VEXP2PD

(KL, VL) = (8, 512)

FOR j := 0 TO KL-1

i := j * 64

IF k1[j] OR *no writemask* THEN

IF (EVEX.b = 1) AND (SRC *is memory*)

THEN DEST[i+63:i] := EXP2_23_DP(SRC[63:0])

ELSE DEST[i+63:i] := EXP2_23_DP(SRC[i+63:i])

FI;

ELSE

IF *merging-masking*

; merging-masking

THEN *DEST[i+63:i] remains unchanged*

ELSE

; zeroing-masking

DEST[i+63:i] := 0

FI;

FI;

ENDFOR;

VEXP2PD-Approximation to the Exponential 2^x of Packed Double Precision Floating-Point Values With Less Than 2^-23 Relative

Vol. 2D

8-8

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

Table 8-1. Special Values Behavior

Source Input

Result

Comments

NaN

QNaN(src)

If (SRC = SNaN) then #I

+∞

+∞

+/-0

1.0f

Exact result

-∞

+0.0f

Integral value N

2^ (N)

Exact result

Intel C/C++ Compiler Intrinsic Equivalent

VEXP2PD __m512d _mm512_exp2a23_round_pd (__m512d a, int sae);

VEXP2PD __m512d _mm512_mask_exp2a23_round_pd (__m512d a, __mmask8 m, __m512d b, int sae);

VEXP2PD __m512d _mm512_maskz_exp2a23_round_pd ( __mmask8 m, __m512d b, int sae);

SIMD Floating-Point Exceptions

Invalid (if SNaN input), Overflow.

Other Exceptions

See Table 2-48, “Type E2 Class Exception Conditions.”

VEXP2PD-Approximation to the Exponential 2^x of Packed Double Precision Floating-Point Values With Less Than 2^-23 Relative

Vol. 2D

8-9

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VEXP2PS-Approximation to the Exponential 2^x of Packed Single Precision Floating-Point

Values With Less Than 2^-23 Relative Error

Opcode/

Op /

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.512.66.0F38.W0 C8 /r

A

V/V

AVX512ER

Computes approximations to the exponential 2^x (with less

VEXP2PS zmm1 {k1}{z},

than 2^-23 of maximum relative error) of the packed single

zmm2/m512/m32bcst {sae}

precision floating-point values from zmm2/m512/m32bcst and

stores the floating-point result in zmm1with writemask k1.

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Full

ModRM:reg (r, w)

ModRM:r/m (r)

N/A

N/A

Description

Computes the approximate base-2 exponential evaluation of the single precision floating-point values in the source

operand (the second operand) and store the results in the destination operand (the first operand) using the write-

mask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.

Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results

are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.

The source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit

memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.

EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.

A numerically exact implementation of VEXP2xx can be found at https://software.intel.com/en-us/articles/refer-

ence-implementations-for-IA-approximation-instructions-vrcp14-vrsqrt14-vrcp28-vrsqrt28-vexp2.

Operation

VEXP2PS

(KL, VL) = (16, 512)

FOR j := 0 TO KL-1

i := j * 32

IF k1[j] OR *no writemask* THEN

IF (EVEX.b = 1) AND (SRC *is memory*)

THEN DEST[i+31:i] := EXP2_23_SP(SRC[31:0])

ELSE DEST[i+31:i] := EXP2_23_SP(SRC[i+31:i])

FI;

ELSE

IF *merging-masking*

; merging-masking

THEN *DEST[i+31:i] remains unchanged*

ELSE

; zeroing-masking

DEST[i+31:i] := 0

FI;

FI;

ENDFOR;

VEXP2PS-Approximation to the Exponential 2^x of Packed Single Precision Floating-Point Values With Less Than 2^-23 Relative Er-

Vol. 2D

8-10

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

Table 8-2. Special Values Behavior

Source Input

Result

Comments

NaN

QNaN(src)

If (SRC = SNaN) then #I

+∞

+∞

+/-0

1.0f

Exact result

-∞

+0.0f

Integral value N

2^ (N)

Exact result

Intel C/C++ Compiler Intrinsic Equivalent

VEXP2PS __m512 _mm512_exp2a23_round_ps (__m512 a, int sae);

VEXP2PS __m512 _mm512_mask_exp2a23_round_ps (__m512 a, __mmask16 m, __m512 b, int sae);

VEXP2PS __m512 _mm512_maskz_exp2a23_round_ps (__mmask16 m, __m512 b, int sae);

SIMD Floating-Point Exceptions

Invalid (if SNaN input), Overflow.

Other Exceptions

See Table 2-48, “Type E2 Class Exception Conditions.”

VEXP2PS-Approximation to the Exponential 2^x of Packed Single Precision Floating-Point Values With Less Than 2^-23 Relative Er-

Vol. 2D

8-11

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VGATHERPF0DPS/VGATHERPF0QPS/VGATHERPF0DPD/VGATHERPF0QPD-Sparse Prefetch

Packed SP/DP Data Values With Signed Dword, Signed Qword Indices Using T0 Hint

Opcode/

Op/

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.512.66.0F38.W0 C6 /1 /vsib

A

V/V

AVX512PF

Using signed dword indices, prefetch sparse byte

VGATHERPF0DPS vm32z {k1}

memory locations containing single precision data

using opmask k1 and T0 hint.

EVEX.512.66.0F38.W0 C7 /1 /vsib

A

V/V

AVX512PF

Using signed qword indices, prefetch sparse byte

VGATHERPF0QPS vm64z {k1}

memory locations containing single precision data

using opmask k1 and T0 hint.

EVEX.512.66.0F38.W1 C6 /1 /vsib

A

V/V

AVX512PF

Using signed dword indices, prefetch sparse byte

VGATHERPF0DPD vm32y {k1}

memory locations containing double precision data

using opmask k1 and T0 hint.

EVEX.512.66.0F38.W1 C7 /1 /vsib

A

V/V

AVX512PF

Using signed qword indices, prefetch sparse byte

VGATHERPF0QPD vm64z {k1}

memory locations containing double precision data

using opmask k1 and T0 hint.

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1 Scalar

BaseReg (R): VSIB:base,

N/A

N/A

N/A

VectorReg(R): VSIB:index

Description

The instruction conditionally prefetches up to sixteen 32-bit or eight 64-bit integer byte data elements. The

elements are specified via the VSIB (i.e., the index register is an zmm, holding packed indices). Elements will only

be prefetched if their corresponding mask bit is one.

Lines prefetched are loaded into to a location in the cache hierarchy specified by a locality hint (T0):

• T0 (temporal data)-prefetch data into the first level cache.

[PS data] For dword indices, the instruction will prefetch sixteen memory locations. For qword indices, the instruc-

tion will prefetch eight values.

[PD data] For dword and qword indices, the instruction will prefetch eight memory locations.

Note that:

(1) The prefetches may happen in any order (or not at all). The instruction is a hint.

(2) The mask is left unchanged.

(3) Not valid with 16-bit effective addresses. Will deliver a #UD fault.

(4) No FP nor memory faults may be produced by this instruction.

(5) Prefetches do not handle cache line splits

(6) A #UD is signaled if the memory operand is encoded without the SIB byte.

Operation

BASE_ADDR stands for the memory operand base address (a GPR); may not exist.

VINDEX stands for the memory operand vector of indices (a vector register).

SCALE stands for the memory operand scalar (1, 2, 4 or 8).

DISP is the optional 1, 2 or 4 byte displacement.

PREFETCH(mem, Level, State) Prefetches a byte memory location pointed by ‘mem’ into the cache level specified by ‘Level’; a request

for exclusive/ownership is done if ‘State’ is 1. Note that the memory location ignore cache line splits. This operation is considered a

hint for the processor and may be skipped depending on implementation.

VGATHERPF0DPS/VGATHERPF0QPS/VGATHERPF0DPD/VGATHERPF0QPD-Sparse Prefetch Packed SP/DP Data Values With Signed

Vol. 2D

8-12

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VGATHERPF1DPS/VGATHERPF1QPS/VGATHERPF1DPD/VGATHERPF1QPD-Sparse Prefetch

Packed SP/DP Data Values With Signed Dword, Signed Qword Indices Using T1 Hint

Opcode/

Op/

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.512.66.0F38.W0 C6 /2 /vsib

A

V/V

AVX512PF

Using signed dword indices, prefetch sparse byte

VGATHERPF1DPS vm32z {k1}

memory locations containing single precision data using

opmask k1 and T1 hint.

EVEX.512.66.0F38.W0 C7 /2 /vsib

A

V/V

AVX512PF

Using signed qword indices, prefetch sparse byte

VGATHERPF1QPS vm64z {k1}

memory locations containing single precision data using

opmask k1 and T1 hint.

EVEX.512.66.0F38.W1 C6 /2 /vsib

A

V/V

AVX512PF

Using signed dword indices, prefetch sparse byte

VGATHERPF1DPD vm32y {k1}

memory locations containing double precision data using

opmask k1 and T1 hint.

EVEX.512.66.0F38.W1 C7 /2 /vsib

A

V/V

AVX512PF

Using signed qword indices, prefetch sparse byte

VGATHERPF1QPD vm64z {k1}

memory locations containing double precision data using

opmask k1 and T1 hint.

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1 Scalar

BaseReg (R): VSIB:base,

N/A

N/A

N/A

VectorReg(R): VSIB:index

Description

The instruction conditionally prefetches up to sixteen 32-bit or eight 64-bit integer byte data elements. The

elements are specified via the VSIB (i.e., the index register is an zmm, holding packed indices). Elements will only

be prefetched if their corresponding mask bit is one.

Lines prefetched are loaded into to a location in the cache hierarchy specified by a locality hint (T1):

• T1 (temporal data)-prefetch data into the second level cache.

[PS data] For dword indices, the instruction will prefetch sixteen memory locations. For qword indices, the instruc-

tion will prefetch eight values.

[PD data] For dword and qword indices, the instruction will prefetch eight memory locations.

Note that:

(1) The prefetches may happen in any order (or not at all). The instruction is a hint.

(2) The mask is left unchanged.

(3) Not valid with 16-bit effective addresses. Will deliver a #UD fault.

(4) No FP nor memory faults may be produced by this instruction.

(5) Prefetches do not handle cache line splits

(6) A #UD is signaled if the memory operand is encoded without the SIB byte.

Operation

BASE_ADDR stands for the memory operand base address (a GPR); may not exist.

VINDEX stands for the memory operand vector of indices (a vector register).

SCALE stands for the memory operand scalar (1, 2, 4 or 8).

DISP is the optional 1, 2 or 4 byte displacement.

PREFETCH(mem, Level, State) Prefetches a byte memory location pointed by ‘mem’ into the cache level specified by ‘Level’; a request

for exclusive/ownership is done if ‘State’ is 1. Note that the memory location ignore cache line splits. This operation is considered a

hint for the processor and may be skipped depending on implementation.

VGATHERPF1DPS/VGATHERPF1QPS/VGATHERPF1DPD/VGATHERPF1QPD-Sparse Prefetch Packed SP/DP Data Values With Signed

Vol. 2D

8-14

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VP4DPWSSDS-Dot Product of Signed Words With Dword Accumulation and Saturation

(4-Iterations)

Opcode/

Op/

64/32

CPUID Feature

Description

Instruction

En

bit Mode

Flag

Support

EVEX.512.F2.0F38.W0 53 /r

A

V/V

AVX512_4VNNIW

Multiply signed words from source register block

VP4DPWSSDS zmm1{k1}{z},

indicated by zmm2 by signed words from m128

zmm2+3, m128

and accumulate the resulting dword results with

signed saturation in zmm1.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1_4X

ModRM:reg (r, w)

EVEX.vvvv (r)

ModRM:r/m (r)

N/A

Description

This instruction computes 4 sequential register source-block dot-products of two signed word operands with

doubleword accumulation and signed saturation. The memory operand is sequentially selected in each of the four

steps.

In the above box, the notation of “+3” is used to denote that the instruction accesses 4 source registers based on

that operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.

This instruction supports memory fault suppression. The entire memory operand is loaded if any bit of the lowest

16-bits of the mask is set to 1 or if a “no masking” encoding is used.

The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation

portion of this instruction.

Operation

src_reg_id is the 5 bit index of the vector register specified in the instruction as the src1 register.

VP4DPWSSDS dest, src1, src2

(KL,VL) = (16,512)

N := 4

ORIGDEST := DEST

src_base := src_reg_id & ~ (N-1) // for src1 operand

FOR i := 0 to KL-1:

IF k1[i] or *no writemask*:

FOR m := 0 to N-1:

t := SRC2.dword[m]

p1dword := reg[src_base+m].word[2*i] * t.word[0]

p2dword := reg[src_base+m].word[2*i+1] * t.word[1]

DEST.dword[i] := SIGNED_DWORD_SATURATE(DEST.dword[i] + p1dword + p2dword)

ELSE IF *zeroing*:

DEST.dword[i] := 0

ELSE

DEST.dword[i] := ORIGDEST.dword[i]

DEST[MAX_VL-1:VL] := 0

VP4DPWSSDS-Dot Product of Signed Words With Dword Accumulation and Saturation (4-Iterations)

Vol. 2D

8-16

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VP4DPWSSD-Dot Product of Signed Words With Dword Accumulation (4-Iterations)

Opcode/

Op/

64/32

CPUID Feature

Description

Instruction

En

bit Mode

Flag

Support

EVEX.512.F2.0F38.W0 52 /r

A

V/V

AVX512_4VNNIW

Multiply signed words from source register block

VP4DPWSSD zmm1{k1}{z}, zmm2+3,

indicated by zmm2 by signed words from m128

m128

and accumulate resulting signed dwords in zmm1.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1_4X

ModRM:reg (r, w)

EVEX.vvvv (r)

ModRM:r/m (r)

N/A

Description

This instruction computes 4 sequential register source-block dot-products of two signed word operands with

doubleword accumulation; see Figure 8-1 below. The memory operand is sequentially selected in each of the four

steps.

In the above box, the notation of “+3”' is used to denote that the instruction accesses 4 source registers based on

that operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.

This instruction supports memory fault suppression. The entire memory operand is loaded if any bit of the lowest

16-bits of the mask is set to 1 or if a “no masking” encoding is used.

The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation

portion of this instruction.

16b

16b

16b

16b

a3

a2

a1

a0

b1

b0

b1

b0

32b

32b

c1

c0

c1=c1+a2*b0+a3*b1

c0=c0+a0*b0+a1*b1

32b

32b

Figure 8-1. Register Source-Block Dot Product of Two Signed Word Operands With Doubleword Accumulation¹

NOTES:

1. For illustration purposes, one source-block dot product instance is shown out of the four.

VP4DPWSSD-Dot Product of Signed Words With Dword Accumulation (4-Iterations)

Vol. 2D

8-18

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VRCP28PD-Approximation to the Reciprocal of Packed Double Precision Floating-Point Values

With Less Than 2^-28 Relative Error

Opcode/

Op /

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.512.66.0F38.W1 CA /r

A

V/V

AVX512ER

Computes the approximate reciprocals ( < 2^-28 relative error)

VRCP28PD zmm1 {k1}{z},

of the packed double precision floating-point values in

zmm2/m512/m64bcst {sae}

zmm2/m512/m64bcst and stores the results in zmm1. Under

writemask.

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Full

ModRM:reg (w)

ModRM:r/m (r)

N/A

N/A

Description

Computes the reciprocal approximation of the float64 values in the source operand (the second operand) and store

the results to the destination operand (the first operand). The approximate reciprocal is evaluated with less than

2^-28 of maximum relative error.

Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results

are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.

If any source element is NaN, the quietized NaN source value is returned for that element. If any source element is

±∞, ±0.0 is returned for that element. Also, if any source element is ±0.0, ±∞ is returned for that element.

The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit

memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.

EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.

A numerically exact implementation of VRCP28xx can be found at https://software.intel.com/en-us/articles/refer-

ence-implementations-for-IA-approximation-instructions-vrcp14-vrsqrt14-vrcp28-vrsqrt28-vexp2.

Operation

VRCP28PD (EVEX Encoded Versions)

(KL, VL) = (8, 512)

FOR j := 0 TO KL-1

i := j * 64

IF k1[j] OR *no writemask* THEN

IF (EVEX.b = 1) AND (SRC *is memory*)

THEN DEST[i+63:i] := RCP_28_DP(1.0/SRC[63:0]);

ELSE DEST[i+63:i] := RCP_28_DP(1.0/SRC[i+63:i]);

FI;

ELSE

IF *merging-masking*

; merging-masking

THEN *DEST[i+63:i] remains unchanged*

ELSE

; zeroing-masking

DEST[i+63:i] := 0

FI;

FI;

ENDFOR;

VRCP28PD-Approximation to the Reciprocal of Packed Double Precision Floating-Point Values With Less Than 2^-28 Relative Error

Vol. 2D

8-20

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

Table 8-3. VRCP28PD Special Cases

Input Value

Result Value

Comments

NAN

QNAN(input)

If (SRC = SNaN) then #I

0 ≤ X < 2^-1022

INF

Positive input denormal or zero; #Z

-2^-1022 < X ≤ -0

-INF

Negative input denormal or zero; #Z

X > 2¹⁰²²

+0.0f

X < -2¹⁰²²

-0.0f

X = +∞

+0.0f

X = -∞

-0.0f

X = 2^-n

2ⁿ

Exact result (unless input/output is a denormal)

X = -2^-n

-2ⁿ

Exact result (unless input/output is a denormal)

Intel C/C++ Compiler Intrinsic Equivalent

VRCP28PD __m512d _mm512_rcp28_round_pd ( __m512d a, int sae);

VRCP28PD __m512d _mm512_mask_rcp28_round_pd(__m512d a, __mmask8 m, __m512d b, int sae);

VRCP28PD __m512d _mm512_maskz_rcp28_round_pd( __mmask8 m, __m512d b, int sae);

SIMD Floating-Point Exceptions

Invalid (if SNaN input), Divide-by-zero.

Other Exceptions

See Table 2-48, “Type E2 Class Exception Conditions.”

VRCP28PD-Approximation to the Reciprocal of Packed Double Precision Floating-Point Values With Less Than 2^-28 Relative Error

Vol. 2D

8-21

INSTRUCTION SET REFERENCE UNIQUE TO INTEL® XEON PHI™ PROCESSORS

VRCP28SD-Approximation to the Reciprocal of Scalar Double Precision Floating-Point Value

With Less Than 2^-28 Relative Error

Opcode/

Op /

64/32

CPUID

Description

Instruction

En

bit Mode

Feature

Support

Flag

EVEX.LLIG.66.0F38.W1 CB /r

A

V/V

AVX512ER

Computes the approximate reciprocal ( < 2^-28 relative

VRCP28SD xmm1 {k1}{z}, xmm2,

error) of the scalar double precision floating-point value in

xmm3/m64 {sae}

xmm3/m64 and stores the results in xmm1. Under

writemask. Also, upper double precision floating-point

value (bits[127:64]) from xmm2 is copied to

xmm1[127:64].

Instruction Operand Encoding

Op/En

Tuple Type

Operand 1

Operand 2

Operand 3

Operand 4

A

Tuple1 Scalar

ModRM:reg (w)

EVEX.vvvv (r)

ModRM:r/m (r)

N/A

Description

Computes the reciprocal approximation of the low float64 value in the second source operand (the third operand)

and store the result to the destination operand (the first operand). The approximate reciprocal is evaluated with

less than 2^-28 of maximum relative error. The result is written into the low float64 element of the destination

operand according to the writemask k1. Bits 127:64 of the destination is copied from the corresponding bits of the

first source operand (the second operand).

A denormal input value is treated as zero and does not signal #DE, irrespective of MXCSR.DAZ. A denormal result

is flushed to zero and does not signal #UE, irrespective of MXCSR.FTZ.

If any source element is NaN, the quietized NaN source value is returned for that element. If any source element is

±∞, ±0.0 is returned for that element. Also, if any source element is ±0.0, ±∞ is returned for that element.

The first source operand is an XMM register. The second source operand is an XMM register or a 64-bit memory

location. The destination operand is a XMM register, conditionally updated using writemask k1.

A numerically exact implementation of VRCP28xx can be found at https://software.intel.com/en-us/articles/refer-

ence-implementations-for-IA-approximation-instructions-vrcp14-vrsqrt14-vrcp28-vrsqrt28-vexp2.

Operation

VRCP28SD ((EVEX Encoded Versions)

IF k1[0] OR *no writemask* THEN

DEST[63: 0] := RCP_28_DP(1.0/SRC2[63: 0]);

ELSE

IF *merging-masking*

; merging-masking

THEN *DEST[63: 0] remains unchanged*

ELSE

; zeroing-masking

DEST[63: 0] := 0

FI;

FI;

ENDFOR;

DEST[127:64] := SRC1[127: 64]

DEST[MAXVL-1:128] := 0

VRCP28SD-Approximation to the Reciprocal of Scalar Double Precision Floating-Point Value With Less Than 2^-28 Relative Error

Vol. 2D

8-22

Content      ..     41      42      43      44     ..