Windows Native Performance Control

Windows Platform Design Notes
Designing Hardware for the Microsoft Windows Family of Operating Systems

Windows Native Processor Performance
Control
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
Version 1.1a November 12, 2002
Contents
Introduction .............................................................................................................................. 4
Windows Processor Performance Control ............................................................................... 4
The Processor Driver Architecture ...................................................................................... 4
Processor Performance Control Policy................................................................................ 5
Dynamic Throttling Policy Details ................................................................................... 6
Performance State Changes Outside the Scope of Policy ............................................. 6
Parameters to P-state policy .......................................................................................... 7
Processor Performance State Transition Latency Issues .................................................... 8
Parameters to C-State Policy .............................................................................................. 9
C-State Control Registry Key ....................................................................................... 10
Implementing Processor Performance Control for Windows .................................................. 11
Support using ACPI 2.0 Processor Objects....................................................................... 11
ACPI 2.0 Processor Objects Design Guidelines for Windows ...................................... 11
Supporting Systems with Intel SpeedStep and Enhanced SpeedStep Technology .......... 13
Supporting Intel SpeedStep Technology using ACPI 2.0 Objects ................................ 13
Supporting Enhanced Intel SpeedStep Technology ..................................................... 14
Supporting the Intel SpeedStep Legacy Applet Interface ............................................. 18
Supporting Systems with AMD PowerNow! Technology ................................................... 20
Implementing for the K6/2+ .......................................................................................... 20
Implementing for the K7 ............................................................................................... 20
Supporting Systems with Transmeta LongRun Technology .............................................. 21
"Designed for Windows XP" Logo Program Requirements .................................................... 21
Call To Action ......................................................................................................................... 22
References............................................................................................................................. 22
Appendix A............................................................................................................................. 22
Processor Driver Capabilities Method (_PDC) Definition .................................................. 22

Windows Native Processor Performance Control 2
2001- 2002 Microsoft Corporation. All rights reserved.

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

This is a preliminary document and may be changed substantially prior to final public release. This document is provided
for 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, the
example companies, organizations, products, people and events depicted herein are fictitious and no association with
any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may
be 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 of
Microsoft Corporation.

Portions of this document specify software that is still in development. Some of the information in this documentation
may 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 item
developed based on these specifications. This document is provided to you on an AS IS basis. Microsoft disclaims all
express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a
particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not
make 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 any
country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall
not be liable for any damages of any kind arising out of or in connection with the use of these specifications, including
without 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 of
liability 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 discussed
as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted
to 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, IN
THIS DOCUMENT.

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

2001-2002 Microsoft Corporation. All rights reserved.

Introduction
Historically, 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 Control
The 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 power
managers 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 kernel
power 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
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 as processor dynamic throttling policies, for
processor performance control:
Constant Always runs at lowest performance state
Adaptive 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 processor
dynamic throttling policies.
Power Scheme AC Power DC Power
Home/Office Desk None Adaptive
Portable/Laptop Adaptive Adaptive
Presentation Adaptive Degrade
Always On None None
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.
Adaptive
This 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
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 processor
to 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 policy
manager 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.
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 the
OS 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 other
than 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
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 data
structures. 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.
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 after
the 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.
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 for
Windows
The 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 allow
processor performance control switching by the operating system without additional BIOS
support. The ACPI 2.0 processor objects supported by Windows include:
_PSS Performance Supported States
_PCT Performance Control
_PPC Performance Present Capabilities
_CST C 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
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 () {
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.
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 Technology
Windows 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 SMI
interface. 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 processor
0x00, // A unique ID given to each processor
0x1010, // ACPI P_BLK address = ACPIBASE + 10
0x06) // 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 0
Package(){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)
{
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.sys using a _PCT with an I/O space
address. Due to an eratta, the gv3.sys driver 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.sys using a _PCT with an FFH address. NOTE: gv3.sys is not included in
Windows XP SP1, but will be made available to OEMs via a QFE, and placed on
Windows 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.sys driver 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.
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 BIOS
takes 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)
{
//
// 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.
//

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()
{
})
}
}
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.sys driver, 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 generic processr.sys driver 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.sys driver only supports the FFH interface reported in the _PCT and _PSS. On
systems the report only the I/O mapped interface with gv3.sys installed, processor
performance state control will not function.
A system running Windows XP RTM with processr.sys that is later upgraded to Windows
XP SP1 or subsequent versions is capable of running the gv3.sys driver 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:
aslhelp@microsoft.com
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.
Windows uses the INT15H/AX=E980h interface defined in the Mobile Pentium III Processor
Featuring Intel SpeedStep Technology BIOS Writers Guide to obtain the Command Data Value
and the Command Port Address.
Important: Windows uses the same performance state switching mechanisms through the SMI
port as the Intel SpeedStep applet to do performance switching. For systems that implement the
recommendations set forth in the Mobile Pentium III Processor Featuring Intel SpeedStep
Technology BIOS Writers Guide, the Command Data Value should equal 82h (the Applet CMD
value). The Command Port Address should equal B2h. Native Windows processor performance
control will not automatically be enabled on systems that use the legacy applet interface unless
the registry modifications explained in the next section are implemented. The registry entries will
be required for all systems using the legacy applet interface that carry the Designed for Windows
XP logo. Under the logo requirements, systems must use only the native Windows processor
performance control. The Intel SpeedStep Applet cannot be used on systems shipping Windows.
Enabling Native Performance Control
For systems that use the legacy applet interface, performance control must be enabled through a
registry key. The registry key used enable the legacy Intel SpeedStep applet interface is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\HackFlags

HackFlags definitions: Bit 0 : Use SpeedStep Applet interface
Bit 1 : Reserved
Bit 2 : System can support all modes when
running on battery
Bit 3-31 : Reserved

NOTE: All registry key values listed are DWORD values.
Overriding Command Values via the Registry
For systems shipped with wrong values in the INT15/E980 or without the INT15/E980, the
command values can be entered through registry keys. The registry keys used to override
INT15/E980 values or report nonexistent values are:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\HackFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdPort==SMI Cmd
Data Port
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdData==SMI Cmd
Data Value

For systems following the Mobile Pentium III Processor Featuring Intel SpeedStep Technology
BIOS Writers Guide, the entries will be:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\HackFlags==0x1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdPort==0xb2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdData==0x82
Registry entry for a system that can only run the highest performance state on AC would be:

Registry entry for a system that can support all performance states on battery would be:

After this registry key entry is made, Windows will assume processor performance control upon
next boot.
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 for
Windows Processor Driver Application Note Revision 1.04. The mechanism for 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)} // Control
Buffer () {
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 () {
0, // B6-Reserved

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-state
control 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 () {
0, // B6-Reserved
0x0,0,0,0,0,0,0,0, // B7:14-register address, _ADR (64 bits)

"Designed for Windows XP" Logo Program
Requirements
Requirements 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 at http://www.microsoft.com/winlogo/hardware
From Microsoft Windows Logo Program System and Device Requirements, Version 2.0:
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 management
technologies such as processor performance state controls.
Work to reduce performance state transition latencies.
References
For 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) Definition
The 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.
Result Code:
None

Windows Native Performance Control

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows Native Performance Control

Uploaded by

Copyright:

Available Formats

Windows Platform Design Notes

Designing Hardware for the Microsoft Windows Family of Operating Systems

You might also like