Windows Native Performance Control

8/12/2019 Windows Native Performance Control

1/23

Windows Platform Design NotesDesigning Hardware for the Micros oftWindowsFamily of Operating System s

Windows Native Processor PerformanceControl

Abstract:Microsoft Windows XP and the Windows Server 2003 family include built-in

processor performance control to take advantage of microprocessors that utilize performance

states to operate the processor more efficiently when it is not fully utilized. This paper outlines the

new BIOS implementations needed to expose this capability in Windows. This paper also details

the functionality and policies employed by Windows for processor performance control.

The current version of this paper is available on the web at

http://www.microsoft.com/hwdev/tech/onnow/ProcPerfCtrl.asp

Versio n 1.1aNovem ber 12, 2002

Contents

Introduction .............................................................................................................................. 4Windows Processor Performance Control ............................................................................... 4

The Processor Driver Architecture ...................................................................................... 4Processor Performance Control Policy................................................................................ 5

Dynamic Throttling Policy Details ................................................................................... 6Performance State Changes Outside the Scope of Policy ............................................. 6Parameters to P-state policy .......................................................................................... 7

Processor Performance State Transition Latency Issues .................................................... 8Parameters to C-State Policy .............................................................................................. 9

C-State Control Registry Key ....................................................................................... 10Implementing Processor Performance Control for Windows .................................................. 11

Support using ACPI 2.0 Processor Objects....................................................................... 11ACPI 2.0 Processor Objects Design Guidelines for Windows ...................................... 11

Supporting Systems with Intel SpeedStep and Enhanced SpeedStep Technology .......... 13Supporting Intel SpeedStep Technology using ACPI 2.0 Objects ................................ 13Supporting Enhanced Intel SpeedStep Technology ..................................................... 14Supporting the Intel SpeedStep Legacy Applet Interface ............................................. 18

Supporting Systems with AMD PowerNow! Technology ................................................... 20

Implementing for the K6/2+ .......................................................................................... 20Implementing for the K7 ............................................................................................... 20Supporting Systems with Transmeta LongRun Technology .............................................. 21

"Designed for Windows XP" Logo Program Requirements .................................................... 21Call To Action ......................................................................................................................... 22References............................................................................................................................. 22

Appendix A............................................................................................................................. 22Processor Driver Capabilities Method (_PDC) Definition .................................................. 22
http://www.microsoft.com/hwdev/tech/onnow/ProcPerfCtrl.asphttp://www.microsoft.com/hwdev/tech/onnow/ProcPerfCtrl.asphttp://www.microsoft.com/hwdev/tech/onnow/ProcPerfCtrl.asp


2/23

Windows Native Processor Performance Control 2

2001- 2002 Microsoft Corporation. All rights reserved.


3/23



Discla imer:Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or otherintellectual property rights covering subject matter in this document. The furnishing of this document does not give youany license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided inany written license agreement from Microsoft Corporation.

This is a preliminary document and may be changed substantially prior to final public release. This document is providedfor informational purposes only and Microsoft makes no warranties, either express or implied, in this document.Information in this document, including URL and other Internet Web site references, is subject to change without notice.

The entire risk of the use or the results of the use of this document remains with the user. Unless otherwise noted, theexample companies, organizations, products, people and events depicted herein are fictitious and no association withany real company, organization, product, person or event is intended or should be inferred. Complying with all applicablecopyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document maybe reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission ofMicrosoft Corporation.

Portions of this document specify software that is still in development. Some of the information in this documentationmay be inaccurate or may not be an accurate representation of the functionality of final documentation or software.Microsoft assumes no responsibility for any damages that might occur directly or indirectly from these inaccuracies.

Microsoft does not make any representation or warranty regarding specifications in this document or any product or itemdeveloped based on these specifications. This document is provided to you on an AS IS basis. Microsoft disclaims allexpress and implied warranties, including but not limited to the implied warranties or merchantability, fitness for aparticular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does notmake any warranty of any kind that any item developed based on these specifications, or any portion of a specification,will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in anycountry. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shallnot be liable for any damages of any kind arising out of or in connection with the use of these specifications, includingwithout limitation, any direct, indirect, incidental, consequential (including any lost profits), punitive or special damages,whether or not Microsoft has been advised of such damages. . Some states do not allow the exclusion or limitation ofliability or consequential or incidental damages; the above limitation may not apply to you.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussedas of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpretedto be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented.This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INTHIS DOCUMENT.

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the UnitedStates and/or other countries. Other product and company names mentioned herein may be the trademarks of theirrespective owners.

2001-2002 Microsoft Corporation. All rights reserved.


4/23



IntroductionHistorically, processors for mobile PC systems ran at lower voltages than processors for desktop

PCs; consequently, processors for mobile PC systems also had to run at slower clock speeds.

This was not usually an issue because mobile PCs have relatively slow disk and memory

subsystems. Mobile PC processors are usually idle when most business applications are being

used.

The situation is different if high bandwidth I/O subsystems are implemented or if the user is doing

something that has high CPU utilization and low I/O bandwidth requirements. This can be the

case with many games, and also with DVD playback. Many games will try to use all available

CPU. The DVD playback case is different because most soft DVD players will only use about

500MHz of the processor capability.

Understanding these limitations in a market environment where speed is an important sales

factor, CPU manufacturers have introduced processors that employ performance states. These

CPUs provide high voltage/high frequency states for use when processor utilization is high, and

low voltage/low frequency states to conserve battery life. This technology gives OEMs the ability

to design a system that can compete both in the speed and battery life benchmark tests.

Windows XP and the Windows Server 2003 family include native support for control of processor

performance states. This paper explains the implementation details needed to use Windows

native support, and outlines the policies that Windows uses for processor performance control.

The paper covers implementation of generic ACPI 2.0 support, and specific details for Intel

SpeedStep, Enhanced Intel SpeedStep, AMD PowerNow!, and Transmeta LongRun processor

performance control technologies.

Windows Processor Performance ControlThe Native support for processor performance control in Windows consists of two components:

the kernel power policy manager, and a processor driver. The kernel power manager is

responsible for managing processor performance control policy, which is the set of rules used to

determine the appropriate performance state to be used at any given time. The kernel powermanagers processor performance control policy algorithms make decisions based on several

inputs, including:

Current power policy and processor dynamic throttling algorithm

Heuristics such as processor utilization, current battery level, use of processor idle states,

and inrush current events

Thermal conditions and events

Current platform capabilities, as conveyed by system firmware

System standby and resume transitions

Processor performance control is implemented using a processor driver architecture. The kernelpower manager calls into the processor driver to invoke changes on the kernels behalf. The

processor driver does not make decisions about when to change performance states, except as

noted later in this paper.

The Processor Driver Architecture

Windows provides support for different manufacturers processors by abstracting specific

implementation details in a processor driver that provides a unified interface to the kernel power


5/23



manager. The processor driver architecture allows Windows to take full advantage of individual

technologies from different CPU vendors, and allow for support of future advances in processors

by providing an easy update path for new functionalities and technologies via development of a

new processor driver.

Windows supports processor performance control described by the Processor Objects defined in

the Advanced Configuration and Power Interface (ACPI) specification, version 2.0, and legacy

interfaces defined by Intel, AMD, and Transmeta. Implementation details for products from each

CPU vendor are provided later in this paper.

All processor drivers are based on and statically linked against a common library, proclib.lib,

which forms the basis of each driver and represents the majority of the functionality. Routines

specific to each processor model reside in the driver for that processor family, and may add to the

functionality common to all processor drivers.

Windows provides a generic processor driver,processr.sys, which is capable of supporting

processors, whose processor performance control interface is described using the ACPI 2.0

processor performance control objects, where the _PCT object is defined using and I/O address

space.

Additional drivers specific to processor families may also be developed. These processor-specific drivers may contain code to support legacy interfaces, or have knowledge about

advanced features and performance afforded by a particular vendors processor performance

control technologies. This includes processor families whose processor performance control

interface is implemented using Functional Fixed Hardware, as described in the ACPI 2.0

specification.

Processor Performance Control Policy

In Windows, the processor performance control policy is linked to the Power Scheme setting in

the Windows control panel power options applet. No additional UI is required to set the policy.

Windows defines four control policies, known asprocessor dynamic throttling policies, for

processor performance control:

Constant Always runs at lowest performance state

Adapt ive Performance state chosen based on CPU demand

Degrade Starts at lowest performance state, then uses linear performance reduction

(stop clock throttling) as battery discharges

None Always runs at the highest available performance state

NOTE:The term stop clock throttling refers to linear clock reduction as described by the

DUTY_WIDTH and DUTY_OFFSET values in the FADT, and defined in the ACPI 2.0

specification, sections 4.7.3.5.1 and 8.1.1.

The following table shows the relationship between Power Policy Schemes and processordynamic throttling policies.

Power Scheme AC Power DC Power

Home/Office Desk None Adaptive

Portable/Laptop Adaptive Adaptive

Presentation Adaptive Degrade

Always On None None


6/23



Power Scheme AC Power DC Power

Minimal Power Management Adaptive Adaptive

Max Battery Adaptive Degrade

Dynamic Throttling Policy Details

The processor dynamic throttling policies used by Windows are explained in more detail below.

NOTE:All policies will always respect the highest available performance state currently available

as reported in the _PPC method by system firmware, when using the ACPI 2.0 interface.

None

This policy always runs the processor at the highest performance state currently available. When

using this policy, the only reason that Windows will lower the performance of the processor is in

response to a thermal event, with the exception of the cases noted later in this paper in the

section titled Performance State Changes Outside the Scope of Policy.

AdaptiveThis policy tries to match the performance of the processor to current demand. Adaptive will use

all available voltage/frequency (performance) states. Adaptive will lower the performance of the

processor to the lowest voltage/frequency state available whenever there is not enough demand

on the processor to justify the use of a higher state. Adaptive will not utilize linear stop clock

throttle states, except in response to thermal events.

Constant

This policy always runs the processor in the lowest available voltage/frequency (performance)

state. Constant will not utilize linear stop clock throttle states, except in response to thermal

events.

Degrade

The Degrade policy always runs the processor in the lowest available voltage/frequency

(performance) state. Additionally, Degrade will utilize linear stop clock throttling under the

following conditions:

When the battery remaining capacity drops below a certain threshold (configurable in the

registry), AND

The system is not using the C3 idle state effectively; that is, the system is too busy to

spend a certain length of time (configurable in the registry) in the C3 state.

The Degrade policy will never throttle below a minimum level, also configurable in the registry.

See the following section for details.

Performance State Changes Outside the Scope of Policy

There are several instances where either the kernel power policy manager or processor driver will

request a performance state transition outside the scope of the processor dynamic throttling

policies. These include:

In a thermal event, where the temperature has crossed a passive trip point (_PSV), the

kernel thermal throttling code will successively use any available lower voltage/frequency


7/23



states to cool the system. If the thermal condition persists and all available performance

states have been exhausted, the kernel will then use linear stop clock throttling states.

When entering any system sleep state (ACPI Sx state), the processor driver will first save

the current performance state, and then set the processor to the lowest voltage/frequency

state available prior to entering the system shutdown handler.

When resuming from any system sleep state, the kernel will temporarily set the processorto the highest available performance state to ensure fast resume performance. Once the

system has awakened, the performance state saved prior to entering sleep is restored,

and the current processor policy then takes effect.

When the OS is starting a device that indicates to the OS that transitioning the device to

the working state causes a significant start up in-rush current load, the kernel power

policy manager will temporarily transition the processor to the lowest voltage/frequency

state available until the device has been started. In-rush current serialization

requirements are conveyed to the OS via the presence of the_IRC object under the

scope of the device in the ACPI name space, or if the DO_POWER_INRUSH flag is set

in the devices driver device object.

Parameters to P-state policy

Several parameters to Windows processor performance state controls are configurable via

registry keys. These keys are provided with the intent that OEMs and system designers may

tune the performance of Windows processor power management features to best suit specific

platform designs, and allow adjustment to help achieve maximum battery life and realize the best

system performance.

NOTE: These parameters are statically adjustable; that is, they are read once during the kernel

initialization code. Adjustments made to these values will not take place until the next system

reboot.

The following registry keys are found in:

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Throttle

Registry Key Name Default Value Description

PerfTimeDelta Hardware

Transition Latency

This value influences the frequency with

which the OS will re-evaluate appropriate

performance state in the idle loop.

PerfCriticalTimeDelta 300000 (300ms) An application may use so much of the

CPUs time that the OS will never enter the

idle loop. In order to make sure that we will

increase the performance of the CPU in this

situation, the processor power policymanager sets a timer that will interrupt the

application. This value influences the time

that must pass before the timer will fire.

PerfIncreasePercentModifier 20 (%) This value scales the threshold at which the

OS increases the performance of the

processor.


8/23



Registry Key Name Default Value Description

PerfIncreaseAbsoluteModifier 1 (%) This value offsets the threshold at which the

OS increases the performance of the

processor.

PerfDecreasePercentModifier 30 (%) This value scales the threshold at which theOS decreases the performance of the

processor.

PerfDecreaseAbsoluteModifier 1 (%) This value offsets the threshold at which the

OS decreases the performance of the

processor.

PerfIncreaseTimeValue 10000 (10ms) This value influences the amount of time that

may pass before the OS will increase

performance. This time is also influenced by

the processors transition latency.

PerfIncreaseMinimumTime 150000 (150ms) This value sets a minimum amount of time

that must pass before any increase in

performance will be considered.

PerfDecreaseTimeValue 10000 (10ms) This value influences the amount of time that

may pass before the OS will decrease

performance. This time is also influenced by

the processors transition latency.

PerfDecreaseMinimumTime 500000 (500ms) This value sets a minimum amount of time

that must pass before any decrease in

performance will be considered.

PerfDegradeThrottleMinCapacity 50 (%) This value sets a minimum performance

level that will be used for any reason otherthan a thermal condition.

PerfMaxC3Frequency 50 (%) This value is the threshold at which the OS

will stop using stop-clock throttling and just

use idle states; i.e., if the machine is using

the Degrade policy and the battery is low, the

OS will throttle the CPU, unless the machine

is spending at least this amount of its time in

the ACPI C3 state. If the machine is

spending at least this amount of time in C3,

then no throttling will be done, unless there is

a thermal condition.

Processor Performance State Transition Latency Issues

Since the launch of Windows, there have been several problem sightings linked to processor

performance state transition latencies. Typically, problems can arise with USB audio playback,

video capture or streaming, and soft audio or soft modem implementations. The problems occur

due to excessive latency in performance state transitions. Since access to main system memory

must be temporarily interrupted during the transition to a new performance state, DMA transfers


9/23



may suffer from buffer underrun conditions, causing bus master agents to be starved for data.

Excessive overhead incurred in legacy SMM transition routines has been identified as

contributing to this condition. Microsoft encourages system designers to take full advantage of

the high performance transition characteristics afforded by the MSR interface available in many

mobile processors, and work with CPU Vendors to reduce performance state transition latencies

in system firmware.

Parameters to C-State Policy

In Windows, all of the parameters for C-state policy are stored as part of the data included in

power policy schemes. Each power scheme has values for use on both AC (utility power) and

DC (battery). When the user chooses a power scheme in the Power Options control panel

applet, new C-state policies are loaded along with the rest of the settings included in the power

scheme.

All C-state parameters are dynamically adjustable in Windows via the API exposed by

powrprof.dll. Any changes made to these policy parameters will take effect immediately, without

requiring a reboot.

These parameters are stored in an array of three PROCESSOR_POWER_POLICY_INFO datastructures. This array of structures is a member of the PROCESSOR_POWER_POLICY

structure. There is one structure for each of the three ACPI processor sleep states defined in

ACPI 1.0b (C1, C2, and C3).

NOTE:For details on using the power API, refer to the Power Management section of the

Platform SDK, available at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/power/base/power_management.asp

Policy Value Description

TimeCheck Defines the time, in microseconds, that must expire

before promotion or demotion is considered.

DemoteLimit Defines the minimum amount of time, in

microseconds, that must be spent in the idle loop to

avoid demotion.

PromoteLimit Defines the time, in microseconds, that must be

exceeded to cause promotion to a deeper idle state.

DemotePercent This value, expressed as a percentage, scales the

threshold at which the power policy manager

decreases the performance of the processor.

PromotePercent This value, expressed as a percentage, scales the

threshold at which the power policy manager

increases the performance of the processor.

AllowDemotion When set, allows the kernel power policy manager to

demote from the current state.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/power_management.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/power_management.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/power_management.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/power_management.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/power_management.asp


10/23



Policy Value Description

AllowPromotion When set, allows the kernel power policy manager to

promote from the current state.

C-State Control Registry Key

In order to better utilize the power savings typically offered by the C3 state, Microsoft

Windows employs a more aggressive C3 entry algorithm than did Windows 2000. This more

aggressive use of C3 has caused stability issues with a very small subset of laptop computers.

Additionally, there are some systems that may have known platform-level problems when

attempting to use C-states.

To facilitate control of the use of C-states, Windows provides the following registry key.

NOTE: This registry key is statically adjustable; that is, it is read once during the processor driver

initialization code. Adjustments made to this value will not take place until the next system

reboot.

NOTE: This key does not apply to C-states described using the ACPI 2.0 _CST object.

The C-state registry key is:

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Processor\CStateFlags

Registry Key Name Bit Value Description

CStateFlags:REG_DWORD Bit 0 Not Used

Bit 1 When set, C2 is disabled

Bit 2 When set, C3 is disabled

Bit 3 When set, enables Windows 2000 C3 behavior

Using _CST to Describe C-States

ACPI 2.0 introduced the _CST object as an alternative and expansion to the C-state description

methods in ACPI 1.0b. For details, refer to the ACPI 2.0 specification, section 8.3.2. Windows

XP and the Windows Server 2003 family both support the ACPI 2.0 _CST object. When using

states marked in the _CST as having the same CSTATE_TYPE, Windows will always choose the

state indicating the lowest power consumption.

BIOS Handoff to Operating System Control

It may be necessary or desirable to have the BIOS control C-state transitions immediately afterthe system boots, or in the absence of an operating system capable of controlling C-states. Once

an operating system capable of controlling C-state transitions has loaded the BIOS must

relinquish control of C-states to the OS. To facilitate this exchange of control between system

firmware and the OS, ACPI 2.0 defines the CST_CNT field in byte offset 95 of the Fixed ACPI

Description Table (FADT).

NOTE:Byte offset 95 was reserved in ACPI 1.0b.


11/23



During the processor driver initialization phase, if CST_CNT is non-zero, the processor driver will

write the value present in the CST_CNT field to the SMI_CMD port to assume control of C-state

transitions from the BIOS.

This is the only modification needed to the FADT to support C-state control.

NOTE: The FADT revision field should not be set equal 3, because it is not an ACPI 2.0 table; it

is still an ACPI 1.0b table with a reserved field used.

Implementing Processor Performance Control forWindowsThe following sections outline the implementation details required in system firmware to properly

support and utilize native processor performance controls in Windows and the Windows

Server 2003 family.

Support using ACPI 2.0 Processor Objects

In addition to supporting ACPI 1.0b, Windows utilizes some of the processor objects defined in

section 8.3.3 of the ACPI 2.0 specification. The objects were defined in ACPI 2.0 to allowprocessor performance control switching by the operating system without additional BIOS

support. The ACPI 2.0 processor objects supported by Windows include:

_PSSPerformance Supported States

_PCTPerformance Control

_PPC Performance Present Capabilities

_CSTC States

The _PTC object is not supported in Windows or the Windows Server 2003 family.

NOTE:The Windows and Windows Server 2003 operating systems do not support all of the ACPI

2.0 specification.

ACPI 2.0 Processor Objects Design Guidelines for Windows

When adding the ACPI 2.0 processor objects to your ACPI 1.0b BIOS, place processor objects in

the processor objects object list under the \_PR scope. The object list should include:

_PCT

_PSS

_PPC

_CST (optional)

Other than location, use the objects exactly as defined in the ACPI 2.0 specification.

BIOS Handoff to Operating System Control

It may be necessary or desirable to have the BIOS control performance state transitions

immediately after the system boots, or in the absence of a performance state control-aware

operating system. Once an operating system capable of controlling processor performance state

transitions has loaded the BIOS must relinquish control of processor performance states to the


12/23



OS. To facilitate this exchange of control between system firmware and the OS, ACPI 2.0

defines the PSTATE_CNT field in byte offset 55 of the Fixed ACPI Description Table (FADT).

NOTE:Byte offset 55 was reserved in ACPI 1.0b.

During the processor driver initialization phase, if PSTATE_CNT is non-zero, the processor driver

will write the value present in the PSTATE_CNT field to the SMI_CMD port to assume control of

processor performance state transitions from the BIOS.

This is the only modification needed to the FADT to support processor performance state control.

NOTE: The FADT revision field should not be set equal 3, because it is not an ACPI 2.0 table; it

is still an ACPI 1.0b table with a reserved field used.

Coding the _PCT

The _PCT is defined in the ACPI 2.0 specification to use the Generic Register Descriptor. The

ASL macro for the Generic Register Descriptor is not implemented in any of the current Microsoft

ASL assemblers, dictating that the ASL code for _PCT generate the data.

The following sample illustrates a _PCT that returns the data in the Generic Register Descriptor

format.

Name (_PCT, Package (2) // Performance Control Object

{

// ResourceTemplate () {Register(SystemIO, 8, 0, 0xB2)} // Control

Buffer () {

0x82, // B0-Generic Register Descriptor (section 6.4.3.7)

0xC,0, // B1:2-length (from _ASI thru _ADR fields)

1, // B3-Address space ID, _ASI, SystemIO

8, // B4-Register Bit Width, _RBW

0, // B5-Register Bit Offset, _RBO

0, // B6-Reserved

0xB2,0,0,0,0,0,0,0, // B7:14-register address, _ADR (64bits)

0x79,0}, // B15:16-End Tag (section 6.4.2.8)

// ResourceTemplate () {Register(SystemIO, 8, 0, 0xB3)} // Status

Buffer () {

0x82, // B0-Generic Register Descriptor (section 6.4.3.7)

0xC,0, // B1:2-length (2 bytes)

1, // B3-Address space ID, _ASI, SystemIO



0, // B6-Reserved

0xB3,0,0,0,0,0,0,0, // B7:14-register address, _ADR (64bits)


}) // End of _PCT object

Coding the _PPC

When coding _PPC, please note that Windows implements an adaptive performance control

policy to take advantage of the higher-performance states when CPU utilization is high.


13/23



Important:If a system can support the higher performance states when on battery, do not

report in _PPC that only the lower power states are supported. Windows will always use the

evaluated value of _PPC to determine the number of performance states currently available.

Supporting Systems with Intel SpeedStep and Enhanced

SpeedStep TechnologyWindows can support Intel SpeedStep using the legacy SpeedStep applet interface or the ACPI

2.0 processor performance objects. System designers should observe the following guidelines:

Systems based on the 440BX chipset should use the legacy applet interface

All other platforms should describe processor performance states using the ACPI 2.0

objects

Supporting Intel SpeedStep Technology using ACPI 2.0 Objects

ICH-based based systems should use the ACPI 2.0 processor performance control objects to

describe the performance states and control data. For performance state switching on current

ICH-based systems, Windows uses a SMI interface similar to the Intel SpeedStep applet SMIinterface. However, the ports and data values will now be defined using the processor

performance control objects as defined in ACPI 2.0.

NOTE: It is highly recommended to follow the Intel BIOS writers guide for the chipset in the

system when implementing the SMI interface.

Example ASL for ICH-based Systems

Scope(\_PR){

Processor(CPU0, // A unique name given to each processor0x00, // A unique ID given to each processor0x1010, // ACPI P_BLK address = ACPIBASE + 100x06) // ICH has a P_BLK length of 6 bytes.{

Name(_PCT, Package(){// return a _PCT containing I/O mapped// STATUS/CONTROL registers)}

Name (_PSS, Package(){// State 0Package(){750, 22000, 250, 200, 0x83, 0x00},// State 1

Package(){600, 10000, 250, 200, 0x84, 0x01}})

Method (_PPC, 0){

// This routine should reflect// the capabilities// of the platform. If all states can be// utilized, always report 0

If (ACON)


14/23



{Return(0) // All states available}

Else{Return(1) // Only state one available}

}}

} // End _PR

FADT PSTATE_CNT Value

To allow the operating system to assume control of performance state transitions from the BIOS,

provide the proper control value in the PSTATE_CNT field of the Fixed ACPI Description Table

(FADT) at byte offset 55. As described in the Intel BIOS Writers Guide, this value should be set

to 80h to disable the SpeedStep Applet interface.

The FADT revision field should not be set to 3.

Supporting Enhanced Intel SpeedStep Technology

Intel has recently announced the latest version of Enhanced Intel SpeedStep Technology, which

will first be supported on Intel's next-generation mobile architecture, codenamed Banias.

Enhanced Intel SpeedStep Technology will be supported on Windows XP as follows:

Windows XP build RTM (build 2600) will support Enhanced Intel SpeedStep Technology

using the generic processor driver,processr.sysusing a _PCT with an I/O space

address. Due to an eratta, the gv3.sysdriver can not be properly detected and installed

on Windows XP RTM.

Windows XP SP1 will support Enhanced Intel SpeedStep Technology via the processor

driver gv3.sysusing a _PCT with an FFH address. NOTE:gv3.sysis not included in

Windows XP SP1, but will be made available to OEMs via a QFE, and placed onWindows Update. SP1 systems that do not have the gv3.sys driver will be supported by,

processr.sys, using a _PCT with an I/O space address.

OEMs wishing to include gv3.sys in their factory pre-load image on systems which use Enhanced

Intel SpeedStep Technology should contact their Microsoft Technical Account Manager.

IMPORTANT:The gv3.sysdriver will only support a _PCT of type 0x7F (Functionally Fixed

Hardware). This allows the driver to invoke performance state transitions using the Enhanced

Intel SpeedStep Technology MSR interface directly, negating the need for a BIOS SMM handler

and avoiding the performance penalty associated with this approach (see the preceding section

titled Processor Performance State Transition Latency Issues). No support for I/O mapped

control registers is provided.

Enhanced Intel SpeedStep Technology BIOS Requirements

To fully and seamlessly support Enhanced Intel SpeedStep Technology on platforms that may

run several versions of the Windows operating system and still take advantage of the fast

transition performance offered by Enhanced Intel SpeedStep Technology, it is necessary for the

system firmware to switch between presenting legacy I/O mapped control/status registers and

MSR interfaces described using FFH, based on the presence of a system driver that can take

advantage of the MSR interface.


15/23



To facilitate this interface switch, Microsoft has proposed a new ACPI control method for inclusion

in the next iteration of the ACPI specification. This method, _PDC or Processor Driver

Capabilities, allows platform firmware to accurately determine the presence of a processor driver

that supports a specific processor feature set.

Using the _PDC Method

NOTE: For a complete definition of _PDC, refer to Appendix A at the end of this white paper.

_PDC is guaranteed to be evaluated by the processor driver prior to its evaluating any other

processor objects. _PDC takes an argument containing one or more capabilities DWORDS.

Each bit in the capabilities DWORD is a flag that is intended to represent a feature supported by

the processor driver. These bits are defined by the CPU manufacturer. The processor driver will

set the capabilities DWORD to reflect the features it supports. Using _PDC, the system firmware

can modify the _PSS and _PCT based on the presence of a processor driver that can correctly

support each interface.

_PDC is intended to be used as follows. By default, the BIOS describes the _PCT and _PSS

using I/O mapped control and status registers. If no processor driver evaluates _PDC, or the

BIOS does not recognize the capabilities flag(s) passed in when _PDC is evaluated, the BIOStakes no additional action, and processor performance states are controlled using I/O mapped

registers. If the processor driver passes the correct flag(s) into _PDC, the BIOS reconfigures the

_PCT and _PSS to use Functional Fixed Hardware (FFH), and the driver invokes transitions

using FFH.

By implementing _PDC, system designers can be assured end users will always benefit from

having processor performance controls function correctly on all supported versions of Windows

operating systems across all upgrade and clean install scenarios, while still taking full advantage

of the greatly enhanced transition performance afforded by Enhanced Intel SpeedStep

Technology.

Example ASL for Enhanced Intel SpeedStep Technology and _PDC

//

// TYPE stores the type of interface present (I/O or FFH).

//

Name(TYPE, 0) // default to using I/O if _PDC is never evaluated

//

// PDCR holds the expected revision of the processor driver capability

// structure.

//

Name(PDCR, 1)

//

// PDCM holds a mask that is applied to the contents of the processor

// driver capability structure when determining whether FFH is supported.

//

Name(PDCM, 0x01) // bit 0 = 1 for GV3

Method(_PDC, 1)


16/23



{

//

// Compute the size of the input buffer (in bytes) and store it

// in Local0.

//

Store(SizeOf(Arg0), Local0)

//

// Declare a local copy of the processor driver capability buffer

// and copy Arg0 into it.

//

Name(PDCB, Buffer(Local0) {})

Store(Arg0, PDCB)

//

// Point REV and SIZE to the first and second DWORDs in the buffer.

// These DWORDs define the revision of the structure and the number

// of capabilities DWORDs, respectively.//

CreateDWordField(PDCB, 0, REV)

CreateDWordField(PDCB, 4, SIZE)

//

// Exit if this is an unsupported revision of the capabilities

// structure.

//

If(LNotEqual(REV, PDCR))

{

Return

}

//

// Exit if the first capabilities DWORD isn't present.

//

If(LLess(SIZE, 1))

{

Return

}

//// Point DAT0 at the first capabilities DWORD in the structure.

//

CreateDWordField(PDCB, 8, DAT0)

//

// If bit 0 in PDCM is set in the capabilities DWORD,

// then transition to FFH based performance control.

//


17/23



If(And(DAT0, PDCM))

{

Store(1, TYPE)

}

}

Method(_PTC)

{

If(LEqual(TYPE, 0))

{

//

// Return I/O mapped _PTC.

//

Return(

Package()

{

})

}Else

{

//

// Return FFH mapped _PTC.

//

Return(

Package()

{

})

}

}

Method(_PSS)

{

If(LEqual(TYPE, 0))

{

//

// Return I/O mapped _PSS.

//

Return(

Package()

{

})}

Else

{

//

// Return FFH mapped _PSS.

//

Return(

Package()


18/23



{

})

}

}

FADT Entries

Provide the control value in the PSTATE_CNT field of the Fixed ACPI Description Table (FADT)

at byte offset 55. This nonzero value will be written for Windows XP to assume control of

performance states. This value should be 80h to disable the SpeedStep Applet interface as

described in the Intel BIOS Writers Guide.

The FADT revision field should not be set to 3.

Legacy Support and Upgrade Scenarios

To ensure the best end user experience on all supported Windows operating systems, OEMs and

system designers must carefully plan and implement firmware support for systems supporting the

latest Enhanced Intel SpeedStep Technology. It is important to understand the possible

ramifications and limitations involved with various design approaches. To circumvent unforeseen

issues and provide the best end user experience, designers should be aware of the following

facts:

Applets that control processor performance states on Windows 2000 will be removed or

disabled upon upgrade to Windows XP.

Windows XP RTM (build 2600) will not be able to install and run gv3.sys.

Windows XP SP1 or later is capable of installing and running the gv3.sysdriver, if

acquired by the end user from Windows Update, or when supplied by the OEM in their

OS software preload image.

Windows XP RTM (build 2600) can support Enhanced Intel SpeedStep Technology using

the genericprocessr.sysdriver if system firmware implements an I/O based _PCT and

_PSS. On systems that implement the _PCT and _PSS using only the FFH interface,processor performance state control will not function.

The gv3.sysdriver only supports the FFH interface reported in the _PCT and _PSS. On

systems the report only the I/O mapped interface with gv3.sysinstalled, processor

performance state control will not function.

A system running Windows XP RTM withprocessr.sys that is later upgraded to Windows

XP SP1 or subsequent versions is capable of running the gv3.sysdriver if installed, and,

if the system firmware reports only the I/O mapped interface, processor performance

control will not function.

Getting Help with Enhanced Intel SpeedStep Technology Implementations

For assistance with questions or issues regarding details on supporting Enhanced Intel

SpeedStep Technology on Windows platforms, you may contact Microsoft at:

[email protected]

Supporting the Intel SpeedStep Legacy Applet Interface

For systems that were developed and shipped before the Windows XP release, and for all

440BX-based systems, performance switching will be done through the legacy applet interface.
mailto:[email protected]:[email protected]:[email protected]


19/23


20/23



Supporting Systems with AMD PowerNow! Technology

Windows and the Windows Server 2003 family support processor performance control on both

AMD K6/2+ and K7 PowerNow!-capable processors. The K6/2+ implementation uses the SMI

interface and BIOS description table to read capabilities. The K7 is only supported via the ACPI

2.0 objects. Once processor capabilities are determined, Windows will perform all performance

state control directly, with no additional support needed from the system BIOS.

Implementing for the K6/2+

The K6/2+ processor driver in Windows uses the SMI interface and the Gemini BIOS Descriptor

Table (GBDT) as defined in the Gemini SMI API Specification version 0.80, available from AMD.

The SMI interface is used to query the processors capabilities. If the processor is K6 PowerNow!

enabled, the driver will then locate the GBDT and read the performance states supported and

control values associated with each state in the system.

Implementing for the K7

Windows requires the ACPI 2.0 objects for systems with K7 PowerNow! processors. The

implementation is straightforward and documented in detail by AMD in the BIOS Support forWindows Processor Driver Application Note Revision 1.04. The mechanismfor control and

status of the K7 PowerNow! processors are defined in Model Specific Registers (MSRs). This

dictates that when defining the _PCT in the namespace use the Functional Fixed Hardware

(FFixedHW) address type.

Coding the _PCT

This is a sample _PCT for FFixedHW as described in the ACPI 2.0 specification, which returns

the data in the Generic Register Descriptor format.


{

// ResourceTemplate () {Register(FFixedHW, 0, 0, 0)} // ControlBuffer () {

0x82, // B0-Generic Register Descriptor(section6.4.3.7)


0x7F, // B3-Address space ID, _FFixedHW



0, // B6-Reserved

0x0,0,0,0,0,0,0,0, // B7:14-register address, _ADR (64bits)


// ResourceTemplate () {Register(FFixedHW, 0, 0, 0)} // Status

Buffer () {


0xC,0, // B1:2-length (2 bytes)




0, // B6-Reserved




21/23




Supporting Systems with Transmeta LongRun Technology

Windows supports processor performance control on Transmeta Crusoe processors with

Transmeta LongRun Power Management technology. The Crusoe is supported through the ACPI

2.0 processor objects. After Windows determines processor capabilities, it will perform all P-statecontrol directly with no support needed from the system BIOS.

For details about implementing the _PSS method for Crusoe processors, contact your Transmeta

technical sales representative for the appropriate Transmeta documents and collateral material.

Coding the _PCT

The following code shows a sample _PCT method for FFixedHW as described in the ACPI 2.0

specification. This method returns the data in the Generic Register Descriptor format.


{

// ResourceTemplate () {Register(FFixedHW, 0, 0, 0)} // Control

Buffer () {






0, // B6-Reserved



// ResourceTemplate () {Register(FFixedHW, 0, 0, 0)} // Status

Buffer () {

0x82, // B0-Generic Register Descriptor (section 6.4.3.7)0xC,0, // B1:2-length (2 bytes)




0, // B6-Reserved

0x0,0,0,0,0,0,0,0, // B7:14-register address, _ADR (64 bits)



"Designed for Windows XP" Logo Program

RequirementsRequirements for the Windows Logo Program for hardware that apply specifically for systems or

peripherals that will receive the "Designed for Windows Whistler" are defined in Microsoft

Windows Logo Program System and Device Requirements, Version 2.0,

available on the web site athttp://www.microsoft.com/winlogo/hardware

From Microsoft Windows Logo Program System and Device Requirements, Version 2.0:
http://www.microsoft.com/winlogo/hardwarehttp://www.microsoft.com/winlogo/hardwarehttp://www.microsoft.com/winlogo/hardwarehttp://www.microsoft.com/winlogo/hardware


22/23



Windows XP:Systems implementing processor performance states must use native

Windows support. This means that all performance policy and switching must be done by the

operating system.

Call To Action

Design mobile systems to take advantage of advanced processor power managementtechnologies such as processor performance state controls.

Work to reduce performance state transition latencies.

ReferencesFor information about implementing ACPI processor performance objects as described in this

paper, see the Advanced Configuration and Power Interface Specification version 2.0, available

at:

http://www.acpi.info/index.html

Contact the processor manufacturer to obtain copies of the BIOS writers guides mentioned in this

paper:

Mobile Pentium III Processor Featuring Intel SpeedStep Technology BIOS Writers Guide,

available from Intel

Geyserville III BIOS Porting Guide, available from Intel

Gemini SMI API Specification version 0.80, available from AMD

BIOS Support for Windows XP Processor Driver Application Note, Publication Identification

Number: 24723A, Rev 1.04, available from AMD

Appendix A

Processor Driver Capabilities Method (_PDC) DefinitionThe proposed _PDC method is to be defined as follows.

This optional object is a method that is used by OSPM to communicate to the platform the level of

support currently provided by OSPM for processor power management. This object is a child object

of the processor device it is describing. This method will be evaluated by OSPM prior to evaluating

any other processor power management objects containing configuration information.

The intent of this method is to provide OSPM a mechanism in which to convey to the platform the

capabilities supported by OSPM for processor power management. This allows the platform to

modify the ACPI namespace objects containing configuration information for processor power

management based on the level of support currently provided by OSPM. Using this method

provides a mechanism for OEMs to provide support for new technologies on legacy OSs, while also

allowing OSPM to leverage new technologies on platforms capable of supporting them.

Arguments:

Arg0 (buffer):

DWORD 0: Revision Id

DWORD 1: Number of capabilities DWORDs in buffer

DWORD 2-n: Capabilities DWORDs, where each bit defines capabilities and features

supported by the OSPM for processor power management.

The definitions and meaning of each capabilities bit is vendor specific, and shared with OSPM by

the vendor.
http://www.acpi.info/index.htmlhttp://www.acpi.info/index.htmlhttp://www.acpi.info/index.html


23/23


Result Code:

None

Documents

Windows Native Performance Control