Intel® 64 Architecture x2APIC Specification

Citation preview

Intel® 64 Architecture x2APIC Specification

Reference Number: 318148-004 March 2010

i

I NFORMATI ON I N THI S DOCUMENT I S PROVI DED I N CONNECTI ON WI TH I NTEL PRODUCTS. NO LI CENSE, EXPRESS OR I MPLI ED, BY ESTOPPEL OR OTHERWI SE, TO ANY I NTELLECTUAL PROPERTY RI GHTS I S GRANTED BY THI S DOCUMENT. EXCEPT AS PROVI DED I N I NTEL’S TERMS AND CONDI TI ONS OF SALE FOR SUCH PRODUCTS, I NTEL ASSUMES NO LI ABI LI TY WHATSOEVER, AND I NTEL DI SCLAI MS ANY EXPRESS OR I MPLI ED WARRANTY, RELATI NG TO SALE AND/ OR USE OF I NTEL PRODUCTS I NCLUDI NG LI ABI LI TY OR WARRANTI ES RELATI NG TO FI TNESS FOR A PARTI CULAR PURPOSE, MERCHANTABI LI TY, OR I NFRI NGEMENT OF ANY PATENT, COPYRI GHT OR OTHER I NTELLECTUAL PROPERTY RI GHT. I NTEL PRODUCTS ARE NOT I NTENDED FOR USE I N MEDI CAL, LI FE SAVI NG, OR LI FE SUSTAI NI NG APPLI CATI ONS. I nt el m ay m ake changes t o specificat ions and product descript ions at any t im e, wit hout not ice. Developers m ust not r ely on t he absence or charact erist ics of any feat ures or inst r uct ions m arked “ reser ved” or “ undefined.” I m pr oper use of r eser ved or undefined feat ures or inst ruct ions m ay cause unpredict able behav ior or failure in developer 's soft war e code w hen r unning on an I nt el pr ocessor. I nt el r eser ves t hese feat ur es or inst r uct ions for fut ur e definit ion and shall have no responsibilit y w hat soever for conflict s or incom pat ibilit ies ar ising from t heir unaut hor ized use. The I nt el ® 64 ar chit ect ure processor s m ay cont ain design defect s or er ror s k now n as errat a. Cur rent charact er ized errat a ar e available on r equest . Hy per -Thr eading Technology r equir es a com put er sy st em w it h an I nt el ® pr ocessor suppor t ing Hy perThreading Technology and an HT Technology enabled chipset , BI OS and operat ing sy st em . Per for m ance w ill vary depending on t he specific har dwar e and soft war e you use. For m or e infor m at ion, see http://www.intel.com/technology/hyperthread/index.htm; including det ails on w hich pr ocessor s support HT Technology. I nt el ® Virt ualizat ion Technology r equir es a com put er sy st em w it h an enabled I nt el ® pr ocessor, BI OS, v ir t ual m achine m onit or ( VMM) and for som e uses, cert ain plat form soft war e enabled for it . Funct ionalit y, perform ance or ot her benefit s w ill var y depending on har dwar e and soft war e configurat ions. I nt el ® Vir t ualizat ion Technology- enabled BI OS and VMM applicat ions are curr ent ly in developm ent . 64- bit com put ing on I nt el ar chit ect ur e r equir es a com put er syst em w it h a pr ocessor, chipset , BI OS, oper at ing sy st em , dev ice dr ivers and applicat ions enabled for I nt el ® 64 ar chit ect ure. Processor s w ill not operat e ( including 32- bit operat ion) w it hout an I nt el ® 64 ar chit ect ur e- enabled BI OS. Per for m ance w ill vary depending on your hardware and soft war e configurat ions. Consult w it h your sy st em vendor for m ore inform at ion. I nt el, Pent ium , I nt el Xeon, I nt el Net Bur st , I nt el Cor e Solo, I nt el Core Duo, I nt el Cor e 2 Duo, I nt el Cor e 2 Ex t r em e, I nt el Pent ium D, I t anium , I nt el SpeedSt ep, MMX, and VTune ar e t radem ar k s or r egist er ed t radem ar k s of I nt el Corporat ion or it s subsidiar ies in t he Unit ed St at es and ot her count ries. * Ot her nam es and brands m ay be claim ed as t he pr oper t y of ot her s. Cont act your local I nt el sales office or your dist ribut or t o obt ain t he lat est specificat ions and befor e placing your pr oduct or der. Copies of docum ent s w hich have an order ing num ber and are r efer enced in t his docum ent , or ot her I nt el lit erat ure, m ay be obt ained from : I nt el Cor porat ion P.O. Box 5937 Denver, CO 80217- 9808 or call 1- 800- 548- 4725 or v isit I nt el’s w ebsit e at http://www.intel.com

Copy r ight © 2006- 2010 I nt el Corporat ion

ii

INTRODUCTION

CHAPTER 1 INTRODUCTION 1.1

INTRODUCTION

The xAPI C archit ect ure provided a key m echanism for int errupt delivery in m any generat ions of I nt el processors and plat form s across different m arket segm ent s. This docum ent describes t he x2API C archit ect ure which is ext ended from t he xAPI C archit ect ure ( t he lat t er was first im plem ent ed on I nt el® Pent ium ® 4 Processors, and ext ended t he API C archit ect ure im plem ent ed on Pent ium and P6 processors) . Ext ensions t o t he xAPI C archit ect ure are int ended prim arily t o increase processor addressabilit y. The x2API C archit ect ure provides backward com pat ibilit y t o t he xAPI C archit ect ure and forward ext endabilit y for fut ure I nt el plat form innovat ions. Specifically, x2API C

•

Ret ains all key elem ent s of com pat ibilit y t o t he xAPI C archit ect ure: — delivery m odes, — int errupt and processor priorit ies, — int errupt sources, — int errupt dest inat ion t ypes;

•

Provides ext ensions t o scale processor addressabilit y for bot h t he logical and physical dest inat ion m odes;

• •

Adds new feat ures t o enhance perform ance of int errupt delivery; Reduces com plexit y of logical dest inat ion m ode int errupt delivery on link based archit ect ures.

1.2

IMPACTED PLATFORM COMPONENTS

x2API C is archit ect ed t o ext end from t he xAPI C archit ect ure while m inim izing t he im pact on plat form com ponent s. Specifically, support for t he x2API C archit ect ure can be im plem ent ed in t he local API C unit . All exist ing PCI / MSI capable devices and I OxAPI C unit should work wit h t he x2API C ext ensions defined in t his docum ent . The x2API C archit ect ure also provides flexibilit y t o cope wit h t he underlying fabrics t hat connect t he PCI devices, I OxAPI Cs and Local API C unit s. The ext ensions provided in t his specificat ion t ranslat e int o m odificat ions t o:

• •

t he local API C unit ,

•

t he underlying fabrics connect ing t he I OxAPI Cs t o t he local API C unit s.

t he underlying fabrics connect ing Message Signaled I nt errupt s ( MSI ) capable PCI devices t o local xAPI Cs,

1-1

INTRODUCTION

However no m odificat ions are required t o PCI or PCI e devices t hat support direct int errupt delivery t o t he processors via Message Signaled I nt errupt s. Sim ilarly no m odificat ions are required t o t he I OxAPI C. The rout ing of int errupt s from t hese devices in x2API C m ode leverages t he int errupt rem apping archit ect ure specified in t he I nt el Virt ualizat ion Technology for Direct ed I / O, Rev 1.1 specificat ion. Modificat ions t o ACPI int erfaces t o support x2API C are described in t he ACPI 4.0 specificat ion.

1.3

GLOSSARY

This docum ent uses t he t erm s list ed in t he following t able.

Table 1-1. Description of terminology Term

Description

APIC

The set of advanced programmable interrupt controller features which may be implemented in a stand-alone controller, part of a system chipset, or in a microprocessor.

local APIC

The processor component that implements the APIC functionalities. The underlying APIC registers their functionalities are documented in Chapter 8 of “Intel® 64 and IA-32 Architectures Software Developer’s Manual“, Vol. 3B. Historically, this may refer narrowly to early generations of processor component in the Pentium and P6 processors. In this document, we also use this term generically across multiple generations of processor components.

I/O APIC

The system chipset component that implements APIC functionalities to communicate with a local APIC.

xAPIC

The extension of the APIC architecture that includes messaged APIC interface over the system bus and expanding processor physical addressability from 4 bits to 8 bits.

local xAPIC

The processor component that implements the associated xAPIC functionalities. This is supported by Intel® Pentium® 4 processors, Pentium® M processors, Intel® CoreTM 2 Duo processors, and Intel® Xeon® processors based on Intel® NetBurst microarchitecture and Intel® CoreTM microarchitecture.

x2APIC

The extension of xAPIC architecture to support 32 bit addressability of processors and associated enhancements.

local x2APIC

The processor component that implements the associated x2APIC functionalities.

xAPIC mode

The operating mode of a local xAPIC unit when it is enabled, or that of a local x2APIC unit when it is enabled but not in extended mode.

x2APIC mode

The operating mode of a local x2APIC unit when it is enabled and in extended mode.

1-2

INTRODUCTION

Table 1-1. Description of terminology Term

Description

APIC ID

A unique ID that can identify individual agent in a platform (or clustered configuration). The maximum bit-width supported is 8 bit, versus 32 bits in x2APIC.

local xAPIC ID

The value configured in the local APIC ID register in xAPIC mode. This is an 8-bit value for xAPIC, and x2APIC in xAPIC mode. Because this is used to specify a target destination in physical delivery mode, it is also referred to as physical xAPIC ID. The processor initializes local xAPIC ID.

physical xAPIC ID

See “local xAPIC ID”.

logical xAPIC ID

The APIC ID value that specifies a target processor to receive interrupt delivered in logical destination mode in a local xAPIC. See documentation on logical destination register (LDR) in Section 2.4.2. This is an 8-bit value. Logical xAPIC ID is not initialized by hardware.

initial APIC ID

The value reported by CPUID.01H:EBX[31:24]. Initial APIC ID is initialized by hardware.

x2APIC ID

The 32-bit value in the local APIC ID register defined by the x2APIC architecture. The value is initialized by hardware and can be accessed via RDMSR in x2APIC mode. It is also reported by CPUID.0BH:EDX. Application can query CPUID.0BH:EDX in user mode without RDMSR.

logical x2APIC ID

The APIC ID value that specifies a target processor to receive interrupt delivered in logical destination mode in a local x2APIC. This is a 32-bit value initialized by hardware.

RsvdZ

Reads of reserved bits return zero

1.4 REFERENCES • I nt el ® 64 and I A- 32 Archit ect ures Soft ware Developer ’s Manual ( in five volum es) ht t p: / / developer.int el.com / product s/ processor/ m anuals/ index.ht m

•

I nt el Virt ualizat ion Technology for Direct ed I / O, Rev 1.1 specificat ion ht t p: / / download.int el.com / t echnology/ com put ing/ vpt ech/ I nt el( r) _VT_for_Direc t _I O.pdf

•

Det ect ing Mult i- Core Processor Topology in an I A- 32 Plat form ht t p: / / www3.int el.com / cd/ ids/ developer/ asm o- na/ eng/ recent / 275339.ht m

•

The ACPI 4.0 specificat ion ht t p: / / www.acpi.info/ spec.ht m

1-3

INTRODUCTION

This page int ent ionally left blank

1-4

LOCAL X2APIC ARCHITECTURE

CHAPTER 2 LOCAL X2APIC ARCHITECTURE 2.1

X2APIC

ENHANCEMENTS

The key enhancem ent s provided by t he x2API C archit ect ure over xAPI C are t he following:

•

Support for t wo m odes of operat ion t o provide backward com pat ibilit y and ext ensibilit y for fut ure plat form innovat ions: — I n xAPI C com pat ibilit y m ode, API C regist ers are accessed t hrough m em ory m apped int erface t o a 4K- Byt e page, ident ical t o t he xAPI C archit ect ure. — I n x2API C m ode, API C regist ers are accessed t hrough Model Specific Regist er ( MSR) int erfaces. I n t his m ode, t he x2API C archit ect ure provides significant ly increased processor addressabilit y and som e enhancem ent s on int errupt delivery.

•

I ncreased range of processor addressabilit y in x2API C m ode: — Physical xAPI C I D field increases from 8 bit s t o 32 bit s, allowing for int errupt processor addressabilit y up t o 4G- 1 processors in physical dest inat ion m ode. A processor im plem ent at ion of x2API C archit ect ure can support fewer t han 32- bit s in a soft ware t ransparent fashion. — Logical xAPI C I D field increases from 8 bit s t o 32 bit s. The 32- bit logical x2API C I D is part it ioned int o t wo sub- fields: a 16- bit clust er I D and a 16- bit logical I D wit hin t he clust er. Consequent ly, ( ( 2^ 20) - 16) processors can be addressed in logical dest inat ion m ode. Pr ocessor im plem ent at ions can support fewer t han 16 bit s in t he clust er I D sub- field and logical I D sub- field in a soft ware agnost ic fashion.

•

More efficient MSR int erface t o access API C regist ers. — To enhance int er- processor and self direct ed int errupt delivery as well as t he abilit y t o virt ualize t he local API C, t he API C regist er set can be accessed only t hrough MSR based int erfaces in t he x2API C m ode. The Mem ory Mapped I O ( MMI O) int erface used by xAPI C is not support ed in t he x2API C m ode.

•

The sem ant ics for accessing API C regist ers have been revised t o sim plify t he program m ing of frequent ly- used API C regist ers by syst em soft ware. Specifically t he soft ware sem ant ics for using t he I nt errupt Com m and Regist er ( I CR) and End Of I nt errupt ( EOI ) regist ers have been m odified t o allow for m ore efficient delivery and dispat ching of int errupt s.

The x2API C ext ensions are m ade available t o syst em soft ware by enabling t he local x2API C unit in t he " x2API C" m ode. The rest of t his chapt er provides det ails for det ect ing, enabling and program m ing feat ures of x2API C.

2-1

LOCAL X2APIC ARCHITECTURE

2.2

DETECTING AND ENABLING X2APIC

A processor ’s support t o operat e it s local API C in t he x2API C m ode can be det ect ed by querying t he ext ended feat ure flag inform at ion report ed by CPUI D. When CPUI D is execut ed wit h EAX = 1, t he ret urned value in ECX[ Bit 21] indicat es processor ’s support for t he x2API C m ode. I f CPUI D.( EAX= 01H) : ECX[ Bit 21] is set , t hen t he local API C in t he processor support s t he x2API C capabilit y and can be placed int o t he x2API C m ode. This bit is set only when t he x2API C hardware is present .

•

Syst em soft ware can place t he local API C in t he x2API C m ode by set t ing t he x2API C m ode enable bit ( bit 10) in t he I A32_API C_BASE MSR at MSR address 01BH. The layout for t he I A32_API C_BASE MSR is shown in Figure 2- 1.

63

36 35

Reserved

12 11 10 9 8 7

0

APIC Base

APIC Base—Base physical address EN—xAPIC global enable/disable EXTD—Enable x2APIC mode BSP—Processor is BSP Reserved

Figure 2-1. IA32_APIC_BASE MSR Supporting x2APIC

Table 2- 1, “ x2API C operat ing m ode configurat ions” describe t he possible com binat ions of t he enable bit ( EN - bit 11) and t he ext ended m ode bit ( EXTD - bit 10) in t he I A32_API C_BASE MSR.

Table 2-1. x2APIC Operating Mode Configurations xAPIC global enable x2APIC enable (IA32_APIC_BASE[11]) (IA32_APIC_BASE[10]) Description 0

0

local APIC is disabled

0

1

Invalid

1

0

local APIC is enabled in xAPIC mode

1

1

local APIC is enabled in x2APIC mode

Once t he local API C has been swit ched t o x2API C m ode ( EN = 1, EXTD = 1) , swit ching back t o xAPI C m ode would require syst em soft ware t o disable t he local API C unit . Specifically, at t em pt ing t o writ e a value t o t he I A32_API C_BASE MSR t hat has ( EN= 1, EXTD = 0) when t he local API C is enabled and in x2API C m ode will raise a GP except ion. Once bit 10 in I A32_API C_BASE MSR is set , t he only way t o leave x2API C m ode using I A32_API C_BASE would require a WRMSR t o set bot h bit 11 and

2-2

LOCAL X2APIC ARCHITECTURE

bit 10 t o zero. Sect ion 2.7, “ x2API C STATE TRANSI TI ONS” provides a det ailed st at e diagram for t he st at e t ransit ions allowed for t he local API C.

2.3

X2APIC

MODE REGISTER INTERFACE

I n xAPI C m ode, t he soft ware m odel for accessing t he API C regist ers is t hrough a m em ory m apped int erface. Specifically, t he API C regist ers are m apped t o a 4K- Byt e region in t he processor's m em ory address space, t he physical address base of t he 4K- Byt e region is specified in t he I A32_API C_BASE MSR ( Default value of FEE0_0000H) . I n x2API C m ode, a block of MSR address range is reserved for accessing API C regist ers t hrough t he processor ’s MSR address space. This sect ion provides det ails of t his MSR based int erface.

2.3.1

Instructions to Access APIC Registers

I n x2API C m ode, syst em soft ware uses RDMSR and WRMSR t o access t he API C regist ers. The MSR addresses for accessing t he x2API C regist ers are archit ect urally defined and specified in Sect ion 2.3.2, “API C Regist er Address Space” . Execut ing t he RDMSR inst ruct ion wit h API C regist er address specified in ECX ret urns t he cont ent of bit s 0 t hrough 31 of t he API C regist ers in EAX. Bit s 32 t hrough 63 are ret urned in regist er EDX - t hese bit s are reserved if t he API C regist er being read is a 32- bit regist er. Sim ilarly execut ing t he WRMSR inst ruct ion wit h t he API C regist er address in ECX, writ es bit s 0 t o 31 of regist er EAX t o bit s 0 t o 31 of t he specified API C regist er. I f t he regist er is a 64- bit regist er t hen bit s 0 t o 31 of regist er EDX are writ t en t o bit s 32 t o 63 of t he API C regist er. The I nt errupt Com m and Regist er is t he only API C regist er t hat is im plem ent ed as a 64- bit MSR. The sem ant ics of handling reserved bit s are defined in Sect ion 2.3.3, “ Reserved Bit Checking” .

2.3.2

APIC Register Address Space

The MSR address range bet ween 0000_0800H t hrough 0000_0BFFH is archit ect urally reserved and dedicat ed for accessing API C regist ers in x2API C m ode. Figure 2- 2 provides t he det ailed list of t he API C regist ers in xAPI C m ode and x2API C m ode. The MSR address offset specified in t he t able is relat ive t o t he base MSR address of 800H. The MMI O offset specified in t he t able is relat ive t o t he default base address of FEE00000H. There is a one- t o- one m apping bet ween t he legacy xAPI C regist er MMI O offset and t he MSR address offset wit h t he following except ions:

•

The I nt errupt Com m and Regist er ( I CR) : The t wo 32- bit I CR regist ers in xAPI C m ode are m erged int o a single 64- bit MSR in x2API C m ode.

•

The Dest inat ion Form at Regist er ( DFR) is not support ed in x2API C m ode.

2-3

LOCAL X2APIC ARCHITECTURE

•

The SELF I PI regist er is available only if x2API C m ode is enabled.

The MSR address space is com pressed t o allow for fut ure growt h. Every 32 bit regist er on a 128- bit boundary in t he legacy MMI O space is m apped t o a single MSR in t he local x2API C MSR address space. The upper 32- bit s of all x2API C MSRs ( except for t he I CR) are reserved.

Table 2-2. Local APIC Register Address Map Supported by x2APIC MSR Offset (x2APIC mode)

Register Name

0000H0010H

000H-001H

Reserved

0020H

002H

Local APIC ID Register

Read only

See Sect ion 2.7.1 for initial values.

0030H

003H

Local APIC Version Register

Read only.

Same version between extended and legacy modes. Bit 24 is available only to an x2APIC unit (in xAPIC mode and x2APIC modes, See Section 2.5.1).

0040H0070H

004H-007H

Reserved

0080H

008H

Task Priority Register (TPR)

0090H

009H

Reserved

00A0H

00AH

Processor Priority Register (PPR)

Read only.

00B0H

00BH

EOI Register

Write only.

0 is the only valid value to write. GP fault on nonzero write

00C0H

00CH

Reserved

00D0H

00DH

Logical Destination Register

Read only.

Read/Write in xAPIC mode)

00E0H

00EH

Reserved1

00F0H

00FH

Spurious Interrupt Vector Register

Read/Write. Bits 0-8, 12 Read/Write; other bits reserved.

0100H

010H

In-Service Register (ISR); bits 0:31

Read Only.

0110H

011H

ISR bits 32:63

Read Only.

MMIO Offset (xAPIC mode)

2-4

R/W Semantics

Comments

Read/Write. Bits 7:0 are RW. Bits 31:8 are Reserved.

GP fault on Read Write in x2APIC mode.

LOCAL X2APIC ARCHITECTURE

Table 2-2. Local APIC Register Address Map Supported by x2APIC (Contd.) MMIO Offset (xAPIC mode)

MSR Offset (x2APIC mode)

Register Name

R/W Semantics

0120H

012H

ISR bits 64:95

Read Only.

0130H

013H

ISR bits 96:127

Read Only.

0140H

014H

ISR bits 128:159

Read Only.

0150H

015H

ISR bits 160:191

Read Only.

0160H

016H

ISR bits 192:223

Read Only.

0170H

017H

ISR bits 224:255

Read Only.

0180H

018H

Trigger Mode Register (TMR); bits 0:31

Read Only.

0190H

019H

TMR bits 32:63

Read Only.

01A0H

01AH

TMR bits 64:95

Read Only.

01B0H

01BH

TMR bits 96:127

Read Only.

01C0H

01CH

TMR bits 128:159

Read Only.

01D0H

01DH

TMR bits 160:191

Read Only.

01E0H

01EH

TMR bits 192:223

Read Only.

01F0H

01FH

TMR bits 224:255

Read Only.

0200H

020H

Interrupt Request Register (IRR); bits 0:31

Read Only.

0210H

021H

IRR bits32:63

Read Only.

0220H

022H

IRR bits 64:95

Read Only.

0230H

023H

IRR bits 96:127

Read Only.

0240H

024H

IRR bits 128:159

Read Only.

0250H

025H

IRR bits 160:191

Read Only.

0260H

026H

IRR bits 192:223

Read Only.

Comments

0270H

027H

IRR bits 224:255

Read Only.

0280H

028H

Error Status Register

Read/Write. GP fault on non-zero writes

0290H02E0H

029H-02EH

Reserved

02F0H

02FH

Reserved

0300H0310H2

030H3

Interrupt Command Register (ICR); bits 0-63

Read/Write.

2-5

LOCAL X2APIC ARCHITECTURE

Table 2-2. Local APIC Register Address Map Supported by x2APIC (Contd.) MMIO Offset (xAPIC mode)

MSR Offset (x2APIC mode)

Register Name

R/W Semantics

0320H

032H

LVT Timer Register

Read/Write.

0330H

033H

LVT Thermal Sensor Register

Read/Write.

0340H

034H

LVT Performance Monitoring Register

Read/Write.

0350H

035H

LVT LINT0 Register

Read/Write.

0360H

036H

LVT LINT1 Register

Read/Write.

0370H

037H

LVT Error Register

Read/Write.

0380H

038H

Initial Count Register (for Timer)

Read/Write.

0390H

039H

Current Count Register (for Timer)

Read Only.

03A0H03D0H

03AH-03DH

Reserved

03E0H

03EH

Divide Configuration Register (for Timer)

Read/Write.

SELF IPI4

Write only

Not supported 03FH 040H-3FFH

Comments

Only in x2APIC mode

Reserved

NOTES: 1. Destination format register (DFR) is supported in xAPIC mode at MMIO offset 00E0H. 2. APIC register at MMIO offset 0310H is accessible in xAPIC mode only 3. MSR 831H (offset 31H) is reserved; read/write operations will result in a GP fault. 4. SELF IPI register is supported only if x2APIC mode is enabled.

2.3.3

Reserved Bit Checking

Sect ion 2.3.2 and Table 2- 2 specifies t he reserved bit definit ions for t he API C regist ers in x2API C m ode. Non- zero writ es ( by WRMSR inst ruct ion) t o reserved bit s t o t hese regist ers will raise a general prot ect ion fault except ion while reads ret urn zeros ( RsvdZ sem ant ics) .

2-6

LOCAL X2APIC ARCHITECTURE

2.3.4

Error Handling

RDMSR and WRMSR operat ions t o reserved addresses in t he x2API C m ode will raise a GP fault . ( Not e: I n xAPI C m ode, an API C error is indicat ed in t he Error St at us Regist er on an illegal regist er access.) Addit ionally reserved bit violat ions cause GP fault s as det ailed in Sect ion 2.3.3. Beyond illegal regist er access and reserved bit violat ions, ot her API C errors are logged in Error St at us Regist er. The det ails on Error St at us Regist er are in Sect ion 2.3.5.4.

2.3.5

MSR Access Semantics

To allow for efficient access t o t he API C regist ers in x2API C m ode, t he serializing sem ant ics of WRMSR are relaxed when writ ing t o t he API C regist ers. Thus, syst em soft ware should not use “ WRMSR t o API C regist ers in x2API C m ode” as a serializing inst ruct ion. Read and writ e accesses t o t he API C regist ers will occur in program order. Addit ional sem ant ics for t he WRMSR inst ruct ion expect ed by syst em soft ware for specific regist ers ( EOI , TPR, SELF I PI ) are described in Sect ion 2.3.5.3, Sect ion 2.3.5.2, and Sect ion 2.4.5. The RDMSR inst ruct ion is not serializing and t his behavior is unchanged when reading API C regist ers in x2API C m ode. Syst em soft ware accessing t he API C regist ers using t he RDMSR inst ruct ion should not expect a serializing behavior. ( Not e: The MMI O- based xAPI C int erface is m apped by syst em soft ware as an un- cached region. Consequent ly, read/ writ es t o t he xAPI C- MMI O int erface have serializing sem ant ics in t he xAPI C m ode.) There are som e sim plificat ions t o t he m eans used by syst em soft ware for accessing t he I nt errupt Cont rol Regist er via t he regist er int erface in t he x2API C m ode. These changes are described in Sect ion 2.3.5.1.

2.3.5.1

Interrupt Command Register Semantics

A processor generat es an int er- processor int errupt ( I PI ) by writ ing t o t he I nt errupt Com m and Regist er ( I CR) in t he local xAPI C unit . I n xAPI C m ode, I CR cont ains a delivery st at us bit ( bit 12) t hat indicat es t he st at us of t he delivery of t his int errupt . The field has soft ware read- only sem ant ics. A value of 0 im plies t hat t here is current ly no act ivit y while a value of 1 im plies t hat t he t ransm ission is pending. The delivery st at us bit get s cleared when t he int errupt has been t ransm it t ed. Wit h t he legacy xAPI C int erface, syst em soft ware would poll t he delivery st at us bit unt il it is clear prior t o sending an I PI . Sim ilarly if t he sem ant ics of t he send operat ion required t hat t he int errupt be sent from t he local xAPI C unit , t hen syst em soft ware would busy- wait for t he delivery st at us bit t o be cleared. I n t he x2API C m ode, t he sem ant ics of program m ing I nt errupt Com m and Regist er t o dispat ch an int errupt is sim plified. A single MSR writ e t o t he 64- bit I CR ( see Figure 25) is required for dispat ching an int errupt .

2-7

LOCAL X2APIC ARCHITECTURE

Ot her sem ant ics change relat ed t o reading/ writ ing t he I CR in x2API C m ode vs. xAPI C m ode are:

•

Com plet ion of t he WRMSR inst ruct ion t o t he I CR does not guarant ee t hat t he int errupt t o be dispat ched has been received by t he t arget ed processors. I f t he syst em soft ware usage requires t his guarant ee, t hen t he syst em soft ware should explicit ly confirm t he delivery of t he int errupt t o t he specified t arget s using an alt ernat e soft ware m echanism s. For exam ple, one possible m echanism would be having t he int errupt service rout ine associat ed wit h t he t arget int errupt delivery t o updat e a m em ory locat ion, t hereby allowing t he dispat ching soft ware t o verify t he m em ory locat ion has been updat ed.

•

A dest inat ion I D value of FFFF_FFFFH is used for broadcast of int errupt s in bot h logical dest inat ion and physical dest inat ion m odes.

•

The Delivery St at us bit of t he I CR has been rem oved. Soft ware need not poll on t he Delivery St at us bit before writ ing t he I CR.

•

I CR reads are st ill allowed t o aid debugging. However soft ware should not assum e t he value ret urned by reading t he I CR is t he last writ t en value.

2.3.5.2

Task Priority Register Semantics

I n x2API C m ode, t he layout of t he Task Priorit y Regist er has t he sam e layout as in t he xAPI C m ode. The sem ant ics for reading and writ ing t o t he TPR regist er via t he MSR int erface are ident ical t o t hose used for TPR access via t he CR8 regist er. Specifically, t he writ e t o t he TPR regist er ensures t hat t he result of any re- priorit izat ion act ion due t o t he change in processor priorit y is reflect ed t o t he processor prior t o t he next inst ruct ion following t he TPR writ e. Any deliverable int errupt s result ing from t he TPR writ e would be t aken at t he inst ruct ion boundary following t he TPR writ e.

2.3.5.3

End Of Interrupt Register Semantics

I n xAPI C m ode, t he EOI regist er is writ t en by an int errupt service rout ine t o indicat e t hat t he current int errupt service has com plet ed. Syst em soft ware perform s a writ e t o t he EOI regist er t o signal an EOI . I n t he x2API C m ode, t he writ e of a zero value t o EOI regist er is enforced. Writ es of a non- zero value t o t he EOI regist er in x2API C m ode will raise a GP fault . Syst em soft ware cont inues t o have t o perform t he EOI writ e t o indicat e int errupt service com plet ion. But in x2API C m ode, t he EOI writ e is wit h a value of zero.

2.3.5.4

Error Status Register Semantics

The Error St at us regist er ( ESR) records all errors det ect ed by t he local API C. I n xAPI C m ode, soft ware can read/ writ e t o t he ESR. A writ e ( of any value) t o t he ESR m ust be done t o updat e t he regist er before at t em pt ing t o read it . This writ e clears any previously logged errors and updat es t he ESR wit h any errors det ect ed since t he

2-8

LOCAL X2APIC ARCHITECTURE

last writ e t o t he ESR. Errors are collect ed regardless of LVT Error m ask bit , but t he API C will only issue an int errupt due t o t he error if t he LVT Error m ask bit is cleared. I n t he x2API C m ode, t he writ e of a zero value is enforced. Soft ware writ es zero’s t o t he ESR t o clear t he error st at us. Writ es of a non- zero value t o t he Error St at us Regist er in x2API C m ode will raise a GP fault . The layout of ESR is shown in Figure 2- 2. I n x2API C m ode, a RDMSR or WRMSR t o an illegal regist er address raises a GP fault . I n xAPI C m ode, t he equivalent MMI O accesses would have generat ed an API C error. So in t he x2API C m ode, t he I llegal Regist er Address field in t he Error St at us regist er will not have any errors logged. Writ e t o t he I CR ( in xAPI C and x2API C m odes) or t o SELF I PI regist er ( x2API C m ode only) wit h an illegal vect or ( vect or < = 0FH) will set t he " Send I llegal Vect or" bit . On receiving an I PI wit h an illegal vect or ( vect or < = 0FH) , t he " Receive I llegal Vect or" bit will be set . On receiving an int errupt wit h illegal vect or in t he range 0H – 0FH, t he int errupt will not be delivered t o t he processor nor will an I RR bit be set in t hat range. Only t he ESR “ Receive I llegal Vect or ” bit will be set . I f t he I CR is program m ed wit h lowest priorit y delivery m ode t hen t he " Re- direct ible I PI " bit will be set in x2API C m odes ( sam e as legacy xAPI C behavior) and t he int errupt will not be processed.

8 7 6 5 4 3 2 1 0

31

Reserved

Illegal Register Address Received Illegal Vector Send Illegal Vector Redirectible IPI Reserved MSR Address: 828H

Figure 2-2. Error Status Register (ESR)

2.3.6

x2APIC Register Availability

The local API C regist ers can be accessed via t he MSR int erface only when t he local x2API C has been swit ched t o t he x2API C m ode as described in Sect ion 2.2. Accessing any API C regist er in t he MSR address range 0800H t hrough 0BFFH via RDMSR or WRMSR when t he local API C is not in x2API C m ode will cause t he inst ruct ions t o raise a GP fault . I n x2API C m ode, t he m em ory m apped int erface is not available and any access t o t he MMI O int erface will behave sim ilar t o t hat of a legacy xAPI C in globally disabled st at e. Table 2- 3 provides t he int eract ions bet ween t he legacy & ext ended m odes and t he legacy and regist er int erfaces.

2-9

LOCAL X2APIC ARCHITECTURE

Table 2-3. MSR/MMIO Interface of a Local x2APIC in Different Modes of Operation MMIO Interface

MSR Interface

xAPIC mode

Available

GP Fault

x2APIC mode

Behavior identical to xAPIC in globally disabled state

Available

2.3.7

VM-exit Controls for MSRs and x2APIC Registers

The VMX archit ect ure allows a VMM t o specify list s of MSRs t o be loaded or st ored on VMX t ransit ions using t he VMX- t ransit ion MSR areas ( see VM- exit MSR- st ore address field, VM- exit MSR- load address filed, and VM- ent ry MSR- load address field in I nt el® 64 and I A- 32 Archit ect ures Soft ware Developer’s Manual, Volum e 3B) . The X2API C MSRs cannot t o be loaded and st ored on VMX t ransit ions. A VMX t ransit ion fails if t he VMM has specified t hat t he t ransit ion should access any MSRs in t he address range from 0000_0800H t o 0000_08FFH ( t he range used for accessing t he X2API C regist ers) . Specifically, processing of an 128- bit ent ry in any of t he VMXt ransit ion MSR areas fails if bit s 31: 0 of t hat ent ry ( represent ed as ENTRY_LOW_DW) sat isfies t he expression: “ ENTRY_LOW_DW & FFFFF800H = 00000800H”. Such a failure causes an associat ed VM ent ry t o fail ( by reloading host st at e) and causes an associat ed VM exit t o lead t o VMX abort .

2.4

EXTENDED PROCESSOR ADDRESSABILITY

This sect ion provides det ails on ext ensions t o t he physical xAPI C I D and t he logical xAPI C I D t o support ext ended processor addressabilit y. The x2API C archit ect ure also provides t wo dest inat ion m odes - physical dest inat ion m ode and logical dest inat ion m ode. Each logical processor in t he syst em has a unique physical xAPI C I D which is used for t arget ing int errupt s t o t hat processor in physical dest inat ion m ode. The local API C I D regist er provides t he physical dest inat ion m ode 8- bit or 32- bit I D for t he processor, depending on xAPI C m ode or x2API C m ode. Sect ion 2.4.1 describes t he 32- bit x2API C I D in x2API C m ode. Each logical processor in t he syst em also can have a unique logical xAPI C I D which is used for t arget ing int errupt s t o t hat processor in logical dest inat ion m ode. The Logical Dest inat ion Regist er specified in Sect ion 2.4.2. I t cont ains t he logical x2API C I D for t he processor in x2API C m ode.

2.4.1

Local APIC ID Register

I n x2API C m ode, t he local API C I D regist er is increased t o 32 bit s wide. This enables 2^ 32 - 1 processors t o be addressable in physical dest inat ion m ode. This 32- bit value is referred t o as “ x2API C I D”. A processor im plem ent at ion m ay choose t o support less

2-10

LOCAL X2APIC ARCHITECTURE

t han 32 bit s in it s hardware. Syst em soft ware should be agnost ic t o t he act ual num ber of bit s t hat are im plem ent ed. All non- im plem ent ed bit s will ret urn zeros on reads by soft ware. The API C I D value of FFFF_FFFFH and t he highest value corresponding t o t he im plem ent ed bit- widt h of t he local API C I D regist er in t he syst em are reserved and cannot be assigned t o any logical processor. I n x2API C m ode, t he local API C I D regist er is a read- only regist er t o syst em soft ware and will be init ialized by hardware. I t is accessed via t he RDMSR inst ruct ion reading t he MSR at address 0802H. Figure 2- 3 provides t he layout of t he Local x2API C I D regist er.

MSR Address: 802H 31

0

x2APIC ID

Figure 2-3. Local APIC ID Register in x2APIC Mode

Each logical processor in t he syst em ( including clust ers wit h a com m unicat ion fabric) m ust be configured wit h an unique x2API C I D t o avoid collisions of x2API C I Ds. On DP and high- end MP processors t arget ed t o specific m arket segm ent s and depending on t he syst em configurat ion, it is possible t hat logical processors in different and " unconnect ed" clust ers power up init ialized wit h overlapping x2API C I Ds. I n t hese configurat ions, a m odel- specific m eans m ay be provided in t hose product segm ent s t o enable BI OS and/ or plat form firm ware t o re- configure t he x2API C I Ds in som e clust ers t o provide for unique and non- overlapping syst em wide I Ds before configuring t he disconnect ed com ponent s int o a single syst em .

2.4.2

Logical Destination Register

I n x2API C m ode, t he Logical Dest inat ion Regist er ( LDR) is increased t o 32 bit s wide. I t is a read- only regist er t o syst em soft ware. This 32- bit value is referred t o as “ logical x2API C I D”. Syst em soft ware accesses t his regist er via t he RDMSR inst ruct ion reading t he MSR at address 80DH. Figure 2- 4 provides t he layout of t he Logical Dest inat ion Regist er in x2API C m ode.

2-11

LOCAL X2APIC ARCHITECTURE

MSR Address: 80DH 31

0

Logical x2APIC ID

Figure 2-4. Logical Destination Register in x2APIC Mode

I n t he xAPI C m ode, t he Dest inat ion Form at Regist er ( DFR) t hrough MMI O int erface det erm ines t he choice of a flat logical m ode or a clust ered logical m ode. Flat logical m ode is not support ed in t he x2API C m ode. Hence t he Dest inat ion Form at Regist er ( DFR) is elim inat ed in x2API C m ode. The 32- bit logical x2API C I D field of LDR is part it ioned int o t wo sub- fields:

• •

Clust er I D ( LDR[ 31: 16] ) : is t he address of t he dest inat ion clust er Logical I D ( LDR[ 15: 0] ) : defines a logical I D of t he individual local x2API C wit hin t he clust er specified by LDR[ 31: 16] .

This layout enables 2^ 16- 1 clust ers each wit h up t o 16 unique logical I Ds - effect ively providing an addressabilit y of ( ( 2^ 20) - 16) processors in logical dest inat ion m ode. I t is likely t hat processor im plem ent at ions m ay choose t o support less t han 16 bit s of t he clust er I D or less t han 16- bit s of t he Logical I D in t he Logical Dest inat ion Regist er. However syst em soft ware should be agnost ic t o t he num ber of bit s im plem ent ed in t he clust er I D and logical I D sub- fields. The x2API C hardware init ializat ion will ensure t hat t he appropriat ely init ialized logical x2API C I Ds are available t o syst em soft ware and reads of non- im plem ent ed bit s ret urn zero. This is a read- only regist er t hat soft ware m ust read t o det erm ine t he logical x2API C I D of t he processor. Specifically, soft ware can apply a 16- bit m ask t o t he lowest 16 bit s of t he logical x2API C I D t o ident ify t he logical address of a processor wit hin a clust er wit hout needing t o know t he num ber of im plem ent ed bit s in clust er I D and Logical I D sub- fields. Sim ilarly, soft ware can creat e a m essage dest inat ion address for clust er m odel, by bit- Oring t he Logical X2API C I D ( 31: 0) of processors t hat have m at ching Clust er I D( 31: 16) . To enable clust er I D assignm ent in a fashion t hat m at ches t he syst em t opology charact erist ics and t o enable efficient rout ing of logical m ode lowest priorit y device int errupt s in link based plat form int erconnect s, t he LDR are init ialized by hardware based on t he value of x2API C I D upon x2API C st at e t ransit ions. Det ails of t his init ializat ion are provided in Sect ion 2.4.4.

2-12

LOCAL X2APIC ARCHITECTURE

2.4.3

Interrupt Command Register

I n x2API C m ode, t he layout of t he I nt errupt Com m and Regist er is shown in Figure 25. The lower 32 bit s of I CR in x2API C m ode is ident ical t o t he lower half of t he I CR in xAPI C m ode, except bit 12 ( Delivery St at us) is not used since it is not needed in X2API C m ode. 1 The dest inat ion I D field is expanded t o 32 bit s in x2API C m ode. 63

32

Destination Field

20 19 18 17 16 15 14 13 12 11 10

31

Reserved

Destination Shorthand 00: No Shorthand 01: Self 10: All Including Self 11: All Excluding Self

Reserved Unused

Address: 830H (63 - 0) Value after Reset: 0H

8 7

0

Vector

Delivery Mode 000: Fixed 001: Reserved 010: SMI 011: Reserved 100: NMI 101: INIT 110: Start Up 111: Reserved Destination Mode 0: Physical 1: Logical

Level 0 = De-assert 1 = Assert Trigger Mode 0: Edge 1: Level

Figure 2-5. Interrupt Command Register (ICR) in x2APIC Mode

A single MSR writ e t o t he I nt errupt Com m and Regist er is required for dispat ching an int errupt in x2API C m ode. Wit h t he rem oval of t he Delivery St at us bit , syst em soft ware no longer has a reason t o read t he I CR. I t rem ains readable only t o aid in

1.

WRMSR to the ICR MSR ignores bit 12 of its source operand. The value returned by RDMSR from the ICR MSR into bit 12 of its destination is undefined.

2-13

LOCAL X2APIC ARCHITECTURE

debugging; however, soft ware should not assum e t he value ret urned by reading t he I CR is t he last writ t en value. A dest inat ion I D value of FFFF_FFFFH is used for broadcast of int errupt s in bot h logical dest inat ion and physical dest inat ion m odes.

2.4.4

Deriving Logical x2APIC ID from the Local x2APIC ID

I n x2API C m ode, t he 32- bit logical x2API C I D, which can be read from LDR, is derived from t he 32- bit local x2API C I D. Specifically, t he 16- bit logical I D sub- field is derived by shift ing 1 by t he lowest 4 bit s of t he x2API C I D, i.e. Logical I D = 1 < < x2API C I D[ 3: 0] . The rest of t he bit s of t he x2API C I D t hen form t he clust er I D port ion of t he logical x2API C I D: Logical x2API C I D = [ ( x2API C I D[ 31: 4] < < 16) | ( 1 < < x2API C I D[ 3: 0] ) ] The use of lowest 4 bit s in x2API C I D im plies t hat at least 16 API C I Ds are reserved for logical processors wit hin a socket in m ult i- socket configurat ions. I f m ore t han 16 API C I DS are reserved for logical processors in a socket / package t hen m ult iple clust er I Ds can exist wit hin t he package. The LDR init ializat ion occurs whenever t he x2API C m ode is enabled. This is described in Sect ion 2.7.

2.4.5

SELF IPI register

SELF I PI s are used ext ensively by som e syst em soft ware. The xAPI C archit ect ure provided a m echanism for sending an I PI t o t he current local API C using t he " self- I PI " short- hand in t he int errupt com m and regist er ( see Figure 2- 5) . The x2API C archit ect ure int roduces a new regist er int erface. This new regist er is dedicat ed t o t he purpose of sending self- I PI s wit h t he int ent of enabling a highly opt im ized pat h for sending self- I PI s. Figure 2- 6 provides t he layout of t he SELF I PI regist er. Syst em soft ware only specifies t he vect or associat ed wit h t he int errupt t o be sent . The sem ant ics of sending a self- I PI via t he SELF I PI regist er are ident ical t o sending a self t arget ed edge t riggered fixed int errupt wit h t he specified vect or. Specifically t he sem ant ics are ident ical t o t he following set t ings for an int er- processor int errupt sent via t he I CR - Dest inat ion Short hand ( I CR[ 19: 18] = 01 ( Self ) ) , Trigger Mode ( I CR[ 15] = 0 ( Edge) ) , Delivery Mode ( I CR[ 10: 8] = 000 ( Fixed) ) , Vect or ( I CR[ 7: 0] = Vect or) .

2-14

LOCAL X2APIC ARCHITECTURE

MSR Address: 083FH 31

8 7

Reserved

0

Vector

Figure 2-6. SELF IPI register

The SELF I PI regist er is a writ e- only regist er. A RDMSR inst ruct ion wit h address of t he SELF I PI regist er will raise a GP fault . The handling and priorit izat ion of a self- I PI sent via t he SELF I PI regist er is archit ect urally ident ical t o t hat for an I PI sent via t he I CR from a legacy xAPI C unit . Specifically t he st at e of t he int errupt would be t racked via t he I nt errupt Request Regist er ( I RR) and I n Service Regist er ( I SR) and Trigger Mode Regist er ( TMR) as if it were received from t he syst em bus. Also sending t he I PI via t he Self I nt errupt Regist er ensures t hat int errupt is delivered t o t he processor core. Specifically com plet ion of t he WRMSR inst ruct ion t o t he SELF I PI regist er im plies t hat t he int errupt has been logged int o t he I RR. As expect ed for edge t riggered int errupt s, depending on t he processor priorit y and readiness t o accept int errupt s, it is possible t hat int errupt s sent via t he SELF I PI regist er or via t he I CR wit h ident ical vect ors can be com bined.

2.5

X2APIC

ENHANCEMENTS TO LEGACY XAPIC ARCHITECTURE

The x2API C archit ect ure also provides enhanced feat ures for a local x2API C unit operat ing in xAPI C m ode. This sect ion describes x2API C enhancem ent s t hat are com m on t o xAPI C m ode and x2API C m ode.

2.5.1

Directed EOI

To support level t riggered int errupt s, t he legacy xAPI C archit ect ure broadcast s EOI m essages for level t riggered int errupt s over t he syst em int erconnect t o all t he I OxAPI Cs in t he syst em indicat ing t hat t he int errupt has been serviced. Broadcast ing t he EOI s can lead t o syst em inefficiencies on a link- based syst em int erconnect . Also, in syst em s wit h m ult iple I OxAPI Cs, where different I OxAPI Cs have been program m ed wit h t he sam e vect or but different processor dest inat ions, t he broadcast ing of t he EOI m essage can lead t o duplicat e int errupt s being delivered t o t he local xAPI C for t he sam e event on an I O device.

2-15

LOCAL X2APIC ARCHITECTURE

Direct ed EOI capabilit y is int ended t o enable syst em soft ware t o perform direct ed EOI s t o specific I OxAPI Cs in t he syst em . Syst em soft ware desiring t o perform a direct ed EOI would do t he following:

•

inhibit t he broadcast of EOI m essage by set t ing bit 12 of t he Spurious I nt errupt Vect or Regist er, and

•

following t he EOI t o t he local x2API C unit for a level t riggered int errupt , perform a direct ed EOI t o t he I OxAPI C generat ing t he int errupt by writ ing t o it s EOI regist er.

Support ing direct ed EOI capabilit y would require syst em soft ware t o ret ain a m apping associat ing level t riggered int errupt s wit h I OxAPI Cs in t he syst em . Bit 12 of t he Spurious I nt errupt Vect or Regist er ( SVR) in t he local x2API C unit cont rols t he generat ion of t he EOI broadcast if t he Direct ed EOI capabilit y is support ed. This bit is reserved t o 0 if t he processor doesn't support Direct ed EOI . I f SVR[ bit 12] is set , a broadcast EOI is not generat ed on an EOI cycle even if t he associat ed TMR bit is indicat ing t he current int errupt is a level t riggered int errupt . Layout of t he Spurious I nt errupt Vect or Regist er is shown in Figure 2- 7.

31

12 11

9 8 7

0

Reserved

EOI Broadcast Disable APIC Software Enable/Disable 0: APIC Disabled 1: APIC Enabled Spurious Vector MMIO Address: FEE0 00F0H MSR Address: 080FH

Figure 2-7. Spurious Interrupt Vector Register (SVR) of x2APIC

The default value for SVR[ bit 12] is clear, indicat ing t hat an EOI broadcast will be perform ed. The support for Direct ed EOI capabilit y can be det ect ed by m eans of bit 24 in t he Local API C Version Regist er. This feat ure is support ed in bot h t he xAPI C m ode and

2-16

LOCAL X2APIC ARCHITECTURE

x2API C m odes of a local x2API C unit . Layout of t he Local API C Version regist er is as shown in Figure 2- 8. The Direct ed EOI feat ure is support ed if bit 24 is set t o 1. 31

25 24 23

Reserved

16 15

Max LVT Entry

0

8 7

Reserved

Vector

Directed EOI Support MMIO Address: FEE0 0030H MSR Address: 0803H

Figure 2-8. Local APIC Version Register of x2APIC

2.6

INTERACTION WITH PROCESSOR CORE OPERATING MODES

Sim ilar t o t he xAPI C archit ect ure, t he API C regist ers defined in t he x2API C archit ect ure are accessible in t he following operat ing m odes of t he processor: Prot ect ed Mode, Virt ual- 8086 Mode, Real Mode, and I A- 32e m ode ( bot h 64- bit and com pat ibilit y sub- m odes) .

2.7

X2APIC

STATE TRANSITIONS

This sect ion provides a det ailed descript ion of t he x2API C st at es of a local x2API C unit , t ransit ions bet ween t hese st at es as well as int eract ions of t hese st at es wit h I NI T and RESET.

2.7.1

x2APIC States

The valid st at es for a local x2API C unit is list ed in Table 2- 1:

• • • •

API C disabled: I A32_API C_BASE[ EN] = 0 and I A32_API C_BASE[ EXTD] = 0 xAPI C m ode: I A32_API C_BASE[ EN] = 1 and I A32_API C_BASE[ EXTD] = 0 x2API C m ode: I A32_API C_BASE[ EN] = 1 and I A32_API C_BASE[ EXTD] = 1 I nvalid: I A32_API C_BASE[ EN] = 0 and I A32_API C_BASE[ EXTD] = 1

The st at e corresponding t o EXTD= 1 and EN= 0 is not valid and it is not possible t o get int o t his st at e. Values writ t en t o t he I A32_API C_BASE_MSR t hat at t em pt a t ransit ion from a valid st at e t o t his invalid st at e will cause a GP fault . Figure 2- 9 shows t he com prehensive st at e t ransit ion diagram for a local x2API C unit . On com ing out of RESET, t he local x2API C unit is enabled and is in t he xAPI C m ode: I A32_API C_BASE[ EN] = 1 and I A32_API C_BASE[ EXTD] = 0. The API C regist ers are init ialized as:

2-17

LOCAL X2APIC ARCHITECTURE

•

The local API C I D is init ialized by hardware wit h a 32 bit I D ( x2API C I D) . The lowest 8 bit s of t he x2API C I D is t he legacy local xAPI C I D, and is st ored in t he upper 8 bit s of t he API C regist er for access in xAPI C m ode.

•

The following API C regist ers are reset t o all zeros for t hose fields t hat are defined in t he xAPI C m ode: — I RR, I SR, TMR, I CR, LDR, TPR, Divide Configurat ion Regist er ( See Chapt er 8 of “ I nt el® 64 and I A- 32 Archit ect ures Soft ware Developer ’s Manual“ , Vol. 3B for det ails of individual API C regist ers) , — Tim er init ial count and t im er current count regist ers,

• • • • •

The LVT regist ers are reset t o 0s except for t he m ask bit s; t hese are set t o 1s. The local API C version regist er is not affect ed. The Spurious I nt errupt Vect or Regist er is init ialized t o 000000FFH. The DFR ( available only in xAPI C m ode) is reset t o all 1s. SELF I PI regist er is reset t o zero.

Reset

Disabled EN = 0 Extd = 0

Init EN =1

xAPIC Mode EN=1, Extd=0

Reset

Extd = 1

Init

EN = 0

EN = 0 Extd = 0

Illegal Transition Extd = 1 Illegal Transition Extd = 1

Illegal Transition Extd = 0

Invalid State

EN = 0 Illegal Transition EN = 0

Extended

Mode EN=1, Extd=1

Reset Init

Figure 2-9. Local x2APIC State Transitions with IA32_APIC_BASE, INIT, and RESET

2-18

LOCAL X2APIC ARCHITECTURE

2.7.1.1

x2APIC After RESET

The valid t ransit ions from t he xAPI C m ode st at e are:

•

t o t he x2API C m ode by set t ing EXT t o 1 ( result ing EN= 1, EXTD= 1) . The physical x2API C I D ( see Figure 2- 3) is preserved across t his t ransit ion and t he logical x2API C I D ( see Figure 2- 4) is init ialized by hardware during t his t ransit ion as docum ent ed in Sect ion 2.4.4. The st at e of t he ext ended fields in ot her API C regist ers, which was not init ialized at RESET, is not archit ect urally defined across t his t ransit ion and syst em soft ware should explicit ly init ialize t hose program m able API C regist ers.

•

t o t he disabled st at e by set t ing EN t o 0 ( result ing EN= 0, EXTD= 0) .

The result of an I NI T in t he xAPI C st at e places t he x2API C in t he st at e wit h EN= 1, EXTD= 0. The st at e of t he local API C I D regist er is preserved ( t he 8- bit xAPI C I D is in t he upper 8 bit s of t he API C I D regist er) . All t he ot her API C regist ers are init ialized as a result of I NI T. A RESET in t his st at e places t he x2API C in t he st at e wit h EN= 1, EXTD= 0. The st at e of t he local API C I D regist er is init ialized as described in Sect ion 2.7.1. All t he ot her API C regist ers are init ialized described in Sect ion 2.7.1.

2.7.1.2

x2APIC Transitions From x2APIC Mode

From t he x2API C m ode, t he only valid x2API C t ransit ion using I A32_API C_BASE is t o t he st at e where t he x2API C is disabled by set t ing EN t o 0 and EXTD t o 0. The x2API C I D ( 32 bit s) and t he legacy local xAPI C I D ( 8 bit s) are preserved across t his t ransit ion. A t ransit ion from t he x2API C m ode t o xAPI C m ode is not valid and t he corresponding WRMSR t o t he I A32_API C_BASE MSR will raise a GP fault . A RESET in t his st at e places t he x2API C in xAPI C m ode. All API C regist ers ( including t he local API C I D regist er) are init ialized as described in Sect ion 2.7.1. An I NI T in t his st at e keeps t he x2API C in t he x2API C m ode. The st at e of t he local API C I D regist er is preserved ( all 32 bit s) . However, all t he ot her API C regist ers are init ialized as a result of t he I NI T t ransit ion.

2.7.1.3

x2APIC Transitions From Disabled Mode

From t he disabled st at e, t he only valid x2API C t ransit ion using I A32_API C_BASE is t o t he xAPI C m ode ( EN= 1, EXTD = 0) . Thus t he only m eans t o t ransit ion from x2API C m ode t o xAPI C m ode is a t wo- st ep process:

•

first t ransit ion from x2API C m ode t o local API C disabled m ode ( EN= 0, EXTD = 0) ,

•

followed by anot her t ransit ion from disabled m ode t o xAPI C m ode ( EN= 1, EXTD= 0) .

Consequent ly, all t he API C regist er st at es in t he x2API C, except for t he x2API C I D ( 32 bit s) , are not preserved across m ode t ransit ions.

2-19

LOCAL X2APIC ARCHITECTURE

A RESET in t he disabled st at e places t he x2API C in t he xAPI C m ode. All API C regist ers ( including t he local API C I D regist er) are init ialized as described in Sect ion 2.7.1. An I NI T in t he disabled st at e keeps t he x2API C in t he disabled st at e.

2.7.1.4

State Changes From xAPIC Mode to x2APIC Mode

Aft er API C regist er st at es have been init ialized by soft ware in xAPI C m ode, a t ransit ion from xAPI C m ode t o x2API C m ode does not affect m ost of t he API C regist er st at es, except t he following:

• •

The Logical Dest inat ion Regist er is not preserved.

•

The high half of t he I nt errupt Com m and Regist er is not preserved.

Any API C I D value writ t en t o t he m em ory- m apped local API C I D regist er is not preserved.

2.8

CPUID EXTENSIONS AND TOPOLOGY ENUMERATION

For I nt el 64 and I A- 32 processors t hat support x2API C, t he CPUI D inst ruct ion provides addit ional m echanism for ident ifying processor t opology inform at ion. Specifically, a value of 1 report ed by CPUI D.01H: ECX[ 21] indicat es t hat t he processor support s x2API C and t he ext ended t opology enum erat ion leaf ( CPUI D.0BH) . The ext ended t opology enum erat ion leaf can be accessed by execut ing CPUI D wit h EAX = 0BH. Soft ware can det ect t he availabilit y of t he ext ended t opology enum erat ion leaf ( 0BH) by perform ing t wo st eps:

•

Check m axim um input value for basic CPUI D inform at ion by execut ing CPUI D wit h EAX= 0. I f CPUI D.0H: EAX is great er t han or equal or 11 ( 0BH) , t hen proceed t o next st ep

•

Check CPUI D.EAX= 0BH, ECX= 0H: EBX is non- zero.

I f bot h of t he above condit ions are t rue, ext ended t opology enum erat ion leaf is available. The presence of CPUI D leaf 0BH in a processor does not guarant ee support for x2API C. I f CPUI D.EAX= 0BH, ECX= 0H: EBX ret urns zero and m axim um input value for basic CPUI D inform at ion is great er t han 0BH, t hen CPUI D.0BH leaf is not support ed on t hat processor. The ext ended t opology enum erat ion leaf is int ended t o assist soft ware wit h enum erat ing processor t opology on syst em s t hat requires 32- bit x2API C I Ds t o address individual logical processors. The basic concept of processor t opology enum erat ion using 8- bit init ial API C I D ( CPUI D.01H: EBX[ 31: 24] ) on legacy syst em s is sim ilar t o using 32- bit x2API C I D report ed by CPUI D leaf 0BH: apply appropriat e bit m asks on unique I Ds t o sort out levels of t opology in a syst em . Legacy processor enum erat ion algorit hm is based on exam ining t he init ial API C I Ds and addit ional inform at ion from CPUI D leaves 01H and 04H t o infer syst em - wide

2-20

LOCAL X2APIC ARCHITECTURE

processor t opology. The relevant inform at ion in CPUI D leaves 01H and 04H do not direct ly m ap t o individual levels of t he t opology, but m erely relat e t o t he sharing charact erist ics below different levels. The ext ended t opology enum erat ion leaf of CPUI D provides t opology inform at ion and dat a t hat sim plify t he algorit hm t o sort out t he processor t opology wit hin a physical package from a 32- bit x2API C I D. Each level of t he processor t opology is enum erat ed by specifying a “ level num ber“ in ECX as input when execut ing CPUI D.EAX= 0BH. This enum erat ion by level num ber allows t he CPUI D.0BH leaf t o support m ore sophist icat ed t opology t han t he lim it at ion of legacy t opology definit ions ( SMT, core, package) . The bit fields report ed by CPUI D.EAX= 0BH include t he x2API C I D of t he current logical processor ( in EDX) , an encoded value of hierarchy referred t o as “ level t ype“ ( in ECX[ 15: 8] ) , t he num ber of enabled logical processors at each queried level t ype ( below it s im m ediat e parent level t ype) , and a bit- vect or lengt h field t o sim plify t he parsing of 32- bit x2API C I D int o hierarchical com ponent s. The det ailed bit field definit ions for CPUI D.0BH leaf are shown in Table 2- 4.

Table 2-4. CPUID Leaf 0BH Information Initial EAX Value

Information Provided about the Processor CPUID leaves > 3 < 80000000 are visible only when IA32_MISC_ENABLES.BOOT_NT4[bit 22] = 0 (default). Extended Topology Enumeration Leaf NOTE: Most fields of leaf 0BH output depends on the initial value in ECX. EDX output do not vary with initial value in ECX. ECX[7:0] output always reflect initial value in ECX. All other output value for an invalid initial value in ECX are 0.

0BH

EAX

Bits 4-0: Number of bits to shift x2APIC ID right to get unique topology ID of next level type*. All logical processors with same next level ID share current level Bits 31-5: Reserved

EBX

Bits 15-00: Number of enabled logical processors at this level type. The number reflects configuration as shipped by Intel** Bits 31-16: Reserved

ECX

Bits 07-00: Level number. Same value as input Bits 15-08: Level Type*** Bits 31-16: Reserved.

EDX

Bits 31-0: x2APIC ID of the current logical processor

2-21

LOCAL X2APIC ARCHITECTURE

Table 2-4. CPUID Leaf 0BH Information (Contd.) Initial EAX Value

Information Provided about the Processor NOTES: * Software should use this field (EAX[4:0]) to enumerate processor topology of the system. ** Software must not use EBX[15:0] to enumerate processor topology of the system. This value in this field (EBX[15:0]) is only intended for display/diagnostic purposes. The actual number of logical processors available to BIOS/OS/Applications may be different from the value of EBX[15:0], depending on software and platform hardware configurations. ***The value of Level Type field is not related to level numbers in any way, higher level type values do not mean higher levels. Level Type field has the following encoding: 0 = Invalid 1 = SMT 2 = Core 3-255 = Reserved

The lowest level num ber is zero. Level num ber = 0 is reserved t o specify SMT- relat ed t opology inform at ion ( see Hyper-Threading Technology in Sect ion 7.8 of “ I nt el® 64 and I A- 32 Archit ect ures Soft ware Developer ’s Manual“ , Vol. 3A) . I f SMT is not present in a processor im plem ent at ion but CPUI D leaf 0BH is support ed, CPUI D.EAX= 0BH, ECX= 0 will ret urn EAX = 0, EBX = 1 and level t ype = 1. Num ber of logical processors at t he core level is report ed at level t ype = 2. CPUI D.0BH leaf can report “ level t ype“ and “ level num ber“ in any order. Each level t ype defines a specific t opology configurat ion wit hin t he physical package. Thus t here is no level t ype corresponding t o “ package“ for CPUI D.0BH leaf. The Level Type encodings indicat e t he t opology level and need not correspond t o any Level num ber except level num ber 0 is reserved for level t ype SMT. The legacy processor t opology enum erat ion fields in CPUI D.01H and CPUI D.04H will cont inue t o report correct t opology up t o t he m axim um values support ed by t he fields and 8- bit init ial API C I D. For fut ure processors wit h t opology t hat exceeds t he lim it s of CPUI D.01H: EBX[ 23: 16] ,CPUI D.01H: EBX[ 31: 24] , CPUI D.EAX= 04H, ECX= 0H: EAX[ 31: 26] , t hese legacy fields will report t he respect ive m odulo m axim um values. I f CPUI D.0BH ret urns EBX= 0 when input ECX= 0 t hen assum e t hat CPUI D.0BH leaf dat a for ext ended processor t opology enum erat ion is not support ed on t his processor. Use CPUI D.01H and CPUI D.04H leaves for t opology inform at ion.

2-22

LOCAL X2APIC ARCHITECTURE

2.8.1

Consistency of APIC IDs and CPUID

The consist ency of physical x2API C I D in MSR 802H in x2API C m ode and t he 32- bit value r et urned in CPUI D.0BH: EDX is facilit at ed by processor hardware. CPUI D.0BH: EDX will report t he full 32 bit I D, in xAPI C and x2API C m ode. This allows BI OS t o det erm ine if a syst em has processors wit h I Ds exceeding t he 8- bit init ial API C I D lim it ( CPUI D.01H: EBX[ 31: 24] ) . I nit ial API C I D ( CPUI D.01H: EBX[ 31: 24] ) is always equal t o CPUI D.0BH: EDX[ 7: 0] . I f t he values of CPUI D.0BH: EDX report ed by all logical processors in a syst em are less t han 255, BI OS can t ransfer cont rol t o OS in xAPI C m ode. I f t he values of CPUI D.0BH: EDX report ed by som e logical processors in a syst em are great er or equal t han 255, BI OS m ust support t wo opt ions t o hand off t o OS:

•

I f BI OS enables logical processors wit h x2API C I Ds great er t han 255, t hen it should enable X2API C in Boot St rap Processor ( BSP) and all Applicat ion Processors ( AP) before passing cont rol t o t he OS. Applicat ion requiring processor t opology inform at ion m ust use OS provided services based on x2API C I Ds or CPUI D.0BH leaf.

•

I f a BI OS t ransfers cont rol t o OS in xAPI C m ode, t hen t he BI OS m ust ensure t hat only logical processors wit h CPUI D.0BH.EDX value less t han 255 are enabled. BI OS init ializat ion on all logical processors wit h CPUI D.0B.EDX values great er t han or equal t o 255 m ust ( a) disable API C and execut e CLI in each logical processor, and ( b) leave t hese logical processor in t he lowest power st at e so t hat t hese processors do not respond t o I NI T I PI during OS boot . The BSP and all t he enabled logical processor operat e in xAPI C m ode aft er BI OS passed cont rol t o OS. Applicat ion requiring processor t opology inform at ion can use OS provided legacy services based on 8- bit init ial API C I Ds or legacy t opology inform at ion from CPUI D.01H and CPUI D 04H leaves.

2.9

SYSTEM TRANSITIONS

This sect ion describes im plicat ions for t he x2API C across syst em st at e t ransit ions specifically init ializat ion and boot ing. The default will be for t he BI OS t o pass t he cont rol t o t he OS wit h t he local x2API Cs in xAPI C m ode if all x2API C I Ds report ed by CPUI D.0BH: EDX are less t han 255, and in x2API C m ode if t here are any logical processor report ing it s x2API C I D at 255 or great er.

2.10

LEGACY XAPIC CLARIFICATIONS

The x2API C archit ect ure elim inat es/ deprecat es som e of t he feat ures provided by t he legacy xAPI C and som e of t he legacy xAPI C feat ures t hat were not used by prevailing com m ercial syst em soft ware. This sect ion provides a list of t he feat ures/ capabilit ies t hat are not support ed in t he x2API C archit ect ure.

2-23

LOCAL X2APIC ARCHITECTURE

•

2-24

Re- direct ible/ Lowest Priorit y int er- processor int errupt s are not support ed in t he x2API C archit ect ure.

LOCAL X2APIC ARCHITECTURE

This page int ent ionally left blank

2-25

LOCAL X2APIC ARCHITECTURE

2-26

I N D EX A APIC. . . . . . . . . . . . . . . . . . . . . . . 1, 2, 1, 6, 7, 9, 17 APIC ID. . . . . . . . . . . . . . . . . . . . . . . . . 3, 11, 14, 23

C CPUID instruction deterministic cache parameters leaf . . . . . . . . 21

D DFR Destination Format Register . . . . . . . . . 3, 12, 18

E EOI End Of Interrupt register. . . . . . . . . . . 1, 4, 7, 15 ESR Error Status Register . . . . . . . . . . . . . . . . . . 5, 7

I ICR Interrupt Command Register . . . 3, 13, 14, 15, 18 Initial APIC ID . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 20 Interrupt Command Register. . . . . . . . . . . . . . . . . . 3 IRR Interrupt Request Register . . . . . . . . . . 5, 15, 18 ISR In Service Register . . . . . . . . . . . . . . 1, 4, 15, 18 I/O APIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

L LDR Logical Destination Register . . . 3, 10, 11, 14, 18 Local APIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 4 register address map . . . . . . . . . . . . . . . . . . . . 4 Local x2APIC . . . . . . . . . . . . 2, 1, 12, 15, 16, 17, 23 Local xAPIC . . . . . . . . . . . . . . . . . . . . . . . . . 1, 2, 15 Local xAPIC ID . . . . . . . . . . . . . . . . . . . . . . . . . 3, 18 Logical x2APIC ID . . . . . . . . . . . . . . . 3, 1, 10, 12, 14 Logical xAPIC ID . . . . . . . . . . . . . . . . . . . . . . 3, 1, 10

M MSR Model Specific Register . . . . . . . . . . . . . 1, 2, 3, 7

P Physical xAPIC ID . . . . . . . . . . . . . . . . . . . . . 3, 1, 10

R RsvdZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 6

Index-1

S SELF IPI register . . . . . . . . . . . . . . . . . . . . . . . . 4, 7 SVR Spurious Interrupt Vector Register . . . . . . . . . 16

T TMR Trigger Mode Register . . . . . . . . . . 5, 15, 16, 18 TPR Task Priority Register. . . . . . . . . . . . . . . 4, 7, 18

X x2APIC . . . . . . . . . . . . . . . . . . . . . . . 2, 1, 2, 15, 23 x2APIC ID . . . . . . . . . . 3, 10, 11, 12, 14, 18, 20, 23 x2APIC Mode2, 1, 2, 3, 6, 7, 9, 10, 11, 13, 14, 15, 17, 23 xAPIC . . . . . . . . . . . . . . . 1, 2, 1, 3, 7, 9, 14, 17, 23 xAPIC Mode . . . . . 2, 3, 7, 10, 12, 13, 15, 16, 17, 23

Index-2

This page int ent ionally left blank

Index-3