Hot-Plug PCI and Windows

ZZ: http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx#ET

Hot-Plug PCI and Windows

更新日期： 2003年09月26日

本页内容

	Hot-Plug PCI Functions and Support
	Windows Hot-Plug PCI Roadmap
	Preparing Drivers for Hot-Plug PCI
	Implementing ACPI-based Hot-Plug PCI in Systems
	Example Namespace for Hot-Plug PCI
	Connecting General Purpose Events
	Windows Logo Program Timeline
	Call to Action
	Related Information

Hot-Plug PCI Functions and Support

Hot-Plug PCI allows users to install and remove PCI devices while the computer is running. Microsoft Windows 2000, Windows XP, and Windows Server 2003 support Hot-Plug PCI through ACPI.

To take advantage of Hot-Plug PCI support on Windows operating systems, manufacturers of hot-pluggable PCI devices and Hot-Plug PCI controllers should develop standard Plug and Play drivers for their devices, and implement insertion and removal notifications as defined in ACPI 1.0b. Hot-Plug PCI controllers should also implement the _HPP object as defined in ACPI 2.0 for Windows XP and Windows Server 2003, and follow standard rules for implementing ACPI events when connecting to General Purpose Events (GPEs), as described in this article.

Support for Standard Hot Plug Controller (SHPC) as defined in PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0, is planned for Windows Vista.

Manufacturers of SHPCs should ensure that their devices comply with the specification, as described in this paper and with Microsoft Windows Logo Program requirements. Windows Vista will include in-box support through a single SHPC driver. This driver will support all SHPCs that are designed to these requirements. SHPC implementations will not require ACPI insertion and removal notifications.

返回页首

Windows Hot-Plug PCI Roadmap

Hot-Plug PCI refers to the technology that allows users to install and remove PCI devices while the computer is running. Hot-Plug PCI should not be confused with fail-over functionality that allows automatic switching to a redundant device in the case of a failure. Hot-Plug PCI in this paper refers strictly to inserting and removing PCI devices in a running system. The information in this paper does not apply to CompactPCI, which is a different hardware technology that also provides hot-plug and fail-over functionality.

The PCI Hot-Plug Specification describes the hardware requirements and interfaces to use when designing Hot-Plug PCI devices. This specification is published by the PCI Special Interest Group (PCI SIG) and is available online at http://www.pcisig.com 

Although the PCI Hot-Plug Specification describes hardware requirements, it currently does not define a complete software interface for handling insertion and removal events. Therefore, the software interface Windows 2000 supports for Hot-Plug PCI is the Advanced Configuration and Power Interface (ACPI) specification, Revision 1.0b. The software interface that Windows XP supports is ACPI 1.0b along with one additional object introduced in ACPI 2.0 (the _HPP object). All insert, eject, and removal events can be handled through ACPI 1.0b on Windows 2000 and Windows XP systems. Note that these are the same mechanisms Windows 2000 and Windows XP use for supporting hot-docking of mobile PCs. Hardware manufacturers who are familiar with hot-docking can use their knowledge to implement Hot-Plug PCI. The ACPI specification is available at http://www.acpi.info/ 

The PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0, defines standard hot-plug interfaces so that all SHPCs can use a single driver and usage model. This specification is available at http://www.pcisig.com .

The rest of this section describes native Hot-Plug PCI support implemented in Windows 2000, Windows XP, and Windows Server 2003, and it describes planned support for SHPC in Windows Vista.

Windows 2000. Hot-Plug PCI support in Windows 2000 consists of the following:

•	Insertion and removal notifications as defined in the ACPI specification, Revision 1.0b
•	Single-level resource re-allocation The operating system can re-allocate hardware resources (I/O and memory apertures) at runtime on a single bus segment only. The operating system can start a device that is hot-plugged behind a bridge only if the resources allocated to the bridge are sufficient to accommodate the new device. If resources allocated to the bridge are not sufficient to accommodate the new device, the operating system cannot reconfigure PCI-to-PCI bridges at runtime to address the device resource requirements. For information about memory and I/O resource allocations for PCI-to-PCI bridges, see the resources listed at the end of this article.
•	Optional vendor-supplied filter driver Hardware manufacturers can supply an optional filter driver to support hot-plug features of a device, such as a proprietary LED display for providing output to users.

Windows XP. ACPI hot-plug support provided in Windows XP is an incremental improvement over Windows 2000. The following hot-plug support is included in Windows XP (and Windows Server 2003):

•	Insertion and removal notifications as defined in the ACPI specification, Revision 1.0b  Same as in Windows 2000
•	Single-level resource re-allocation Same as in Windows 2000
•	Optional vendor-supplied filter driver Same as Windows 2000
•	New _HPP object defined in the ACPI 2.0 specification  This object improves the operating system’s ability to optimally configure devices inserted into hot-plug slots. The _HPP object in the ACPI BIOS must be associated with a PCI-PCI bridge. The object informs the operating system of the default settings that should be used for add-in cards inserted into hot-plug slots located behind the bridge. These parameters will also be used by the operating system to program hot-plugged devices and devices that are inserted before system boot but not configured by the BIOS. The default settings addressed by the _HPP object are: • Cache-line size configuration register • Latency timer configuration register • SERR ENABLE bit in the PCI configuration command register • PARITY ERROR RESPONSE bit in the PCI configuration command register

Although Windows XP supports the _HPP object from ACPI 2.0, it is not considered an ACPI 2.0-compliant operating system because it does not support all ACPI 2.0 enhancements. For example, Windows XP does not support the new event notifications defined in the ACPI 2.0 Specification.

ACPI hot-plug support is consistent for both 32-bit and 64-bit versions of Windows XP.

Future Support Microsoft is investigating the following native support for Hot-Plug PCI in Windows Vista:

•

Operating system support for SHPC  For Windows Vista SHPCs must be designed to conform to the guidelines listed in PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0, and the Windows Logo Program requirements for the SHPC driver. SHPCs that have been designed to meet these requirements do not need any ACPI implementations or vendor-supplied filter drivers. SHPCs will be required for systems running Windows Vista that provide Hot-Plug PCI support.

•

Dynamic configuration of PCI-to-PCI bridges Support for dynamic configuration of PCI-to-PCI bridges is planned for Windows Vista. This support will permit the operating system to reallocate resources among multiple bus segments and dynamically reconfigure resource allocations for PCI-to-PCI bridges at run time. This means that, assuming sufficient resources are available system-wide, the operating system can reallocate resources as needed to any device that is hot-plugged into the system, whether or not that device is behind a bridge and whether or not the bridge has sufficient resources for the hot-plugged device. To support dynamic configuration of PCI-to-PCI bridges, drivers must respond correctly as specified in the Windows DDK to query stop, stop, and start IRPs. Dynamic configuration will exercise code paths that currently might not be exercised completely in Windows 2000 and Windows XP, so drivers that work on Windows 2000 and Windows XP might fail on later versions of Windows operating systems unless properly implemented.

返回页首

Preparing Drivers for Hot-Plug PCI

Hot-Plug PCI is implemented through standard operating system Plug and Play mechanisms. Drivers for devices that can be hot-plugged have no additional requirements beyond the standard Plug and Play support that every Windows driver must have. At a minimum, a Windows Plug and Play driver must implement the following routines:

•	A DriverEntry routine that allocates memory and initializes driver data structures
•	An AddDevice routine that initializes a device
•	A DispatchPnP routine that must handle the following IRPs and may handle additional optional IRPs: • IRP_MN_START_DEVICE The operating system sends this IRP to initialize the hardware and begin using the device. • IRP_MN_QUERY_STOP_DEVICE IRP_MN_STOP_DEVICE IRP_MN_CANCEL_STOP_DEVICE The operating system sends these IRPs to stop the device temporarily for resource rebalancing. • IRP_MN_QUERY_REMOVE_DEVICE IRP_MN_REMOVE_DEVICE IRP_MN_CANCEL_REMOVE_DEVICE IRP_MN_SURPRISE_REMOVAL The operating system sends these IRPs to handle scenarios in which the device is removed. This is particularly necessary for any device on a hot-pluggable bus such as USB, any device capable of Hot-Plug PCI, and any device that may be found in a portable or docking station. • A DispatchPower routine that handles IRPs for power operations • An Unload routine that removes any driver-specific resources set up by DriverEntry

For complete details about these and other aspects of Plug and Play and power support, see the Windows DDK.

Important: Hot-plug PCI devices can be installed at runtime, after the system firmware has booted the computer. When these devices are installed at runtime, option ROMs on the card will not be executed. As a result, Hot-Plug PCI hardware and drivers must be able to function without having run any option ROMs. 
Therefore, in addition to implementing complete Plug and Play support, the designer for a hot-plug device must ensure support for completed device functionality without running an option ROM.

返回页首

Implementing ACPI-based Hot-Plug PCI in Systems

As previously stated, systems that support Hot-Plug PCI use ACPI to inform the operating system of insertion and removal events. ACPI handles Hot-Plug PCI devices the same way it handles any other type of removable device. The following checklist will help in designing systems:

1.	Create device objects for each Hot-Plug PCI slot on its appropriate bus in the ACPI namespace. Because a PCI device might have eight functions on that device, the namespace must list eight device objects for each slot.
2.	For each device object, include the following: • _ADR to identify the PCI address of the slot. As defined in the ACPI specification, the high WORD contains the PCI device number for the slot and the low WORD contains the function number of the device. • _EJ0 control method to indicate that the device is hot-ejectable. When run, this control method should eject the device: It should engage motors, release solenoids, set indicator lights, and so on. This method must not return until the hardware has been completely ejected and status bits have been updated accordingly. • _STA control method. This method indicates whether a device is present in the slot. • _SUN object to identify which physical slot the device is in as indicated on the back of the machine. • _PS0 and _PS3. These optional control methods turn on and off power to the slot if the hardware has power controls available.
3.	Ensure that a pin that signals insertion and eject requests is wired to an ACPI GPE bit.
4.	Create an _Lxx or _Exx control method to handle the GPE bits associated with Hot-Plug PCI.

返回页首

Example Namespace for Hot-Plug PCI

The following ACPI Source Language (ASL) example describes two Hot-Plug PCI slots behind a PCI-to-PCI bridge. The insertion and removal events for both cards are wired to the same GPE (bit 0x0a) in the chip set. Proprietary status bits in the Hot-Plug PCI controller indicate to control methods the presence of devices in a given slot, whether an event is for device insertion or removal, and which slot the event is for.

Scope(\_SB) {
    Device(PCI0) {    // Root PCI Bus 
        Name(_HID, EISAID("PNP0A03"))    // _HID for root device
        Name(_ADR,0)    // Device 0 on this bus
        Method (_CRS,0){    // Need current resources for root dev
            // Return current resources for root bridge 0
        }
        Name(_PRT, Package(){    // Need PCI IRQ routing for PCI bridge
            // Package with PCI IRQ routing table information
        })

        // First PCI-to-PCI bridge (No Hot-Plug slots)
        Device (P2P1) {        
            Name(_ADR,0x000C0000)    // Device#Ch, Func#0 on bus PCI0
            Name(_PRT, Package(){    // Need PCI IRQ routing for PCI bridge
                // Package with PCI IRQ routing table information
            })
        } // end P2P1

        // Second PCI-to-PCI bridge (Bus contains Hot-Plug slots)
        Device (P2P2) {        
            Name(_ADR,0x000E0000)    // Device#Eh, Func#0 on bus PCI0
            Name(_PRT, Package(){    // Need PCI IRQ routing for PCI bridge
                // Package with PCI IRQ routing table information
            })
            Name(_HPP, Package(){0x08,0x40, 0x01, 0x00})    
                //_HPP only implemented in Windows XP

            // Device definitions for Slot 1- HOT PLUG SLOT
            Device (S1F0) {    // Slot 1, Func#0 on bus P2P2
                Name(_ADR,0x00020000)
                Method(_EJ0, 1) {    
                    //Code to eject device - remove all power to device
                }
                Name(_SUN,0x00000001)
            }
            Device (S1F1) {    // Slot 1, Func#1 on bus P2P2
                Name(_ADR,0x00020001)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }
            Device (S1F2) {    // Slot 1, Func#2 on bus P2P2
                Name(_ADR,0x00020002)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }
            Device (S1F3) {    // Slot 1, Func#3 on bus P2P2
                Name(_ADR,0x00020003)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000000)
            }
            Device (S1F4) {    // Slot 1, Func#4 on bus P2P2
                Name(_ADR,0x00020004)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }
            Device (S1F5) {    // Slot 1, Func#5 on bus P2P2
                Name(_ADR,0x00020005)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }
            Device (S1F6) {    // Slot 1, Func#6 on bus P2P2
                Name(_ADR,0x00020006)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }
            Device (S1F7) {    // Slot 1, Func#7 on bus P2P2
                Name(_ADR,0x00020007)
                Method(_EJ0, 1) { S1F0._EJ0}
                Name(_SUN,0x00000001)
            }

            // Device definitions for Slot 2- HOT PLUG SLOT
            Device (S2F0) {    // Slot 2, Func#0 on bus P2P2
                Name(_ADR,0x00030000)
                Method(_EJ0, 1) {    
                    //Code to eject device - remove all power to device 
                }
                Name(_SUN,0x00000002)
            }
            Device (S2F1) {    // Slot 2, Func#1 on bus P2P2
                Name(_ADR,0x00030001)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F2) {    // Slot 2, Func#2 on bus P2P2
                Name(_ADR,0x00030002)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F3) {    // Slot 2, Func#3 on bus P2P2
                Name(_ADR,0x00030003)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F4) {    // Slot 2, Func#4 on bus P2P2
                Name(_ADR,0x00030004)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F5) {    // Slot 2, Func#5 on bus P2P2
                Name(_ADR,0x00030005)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F6) {    // Slot 2, Func#6 on bus P2P2
                Name(_ADR,0x00030006)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }
            Device (S2F7) {    // Slot 2, Func#7 on bus P2P2
                Name(_ADR,0x00030007)
                Method(_EJ0, 1) { S2F0._EJ0}
                Name(_SUN,0x00000002)
            }

        }    // end P2P2
    }    // end PCI0
}    // end Scope (\_SB)

Scope(\_GPE) {
    Method(_L0A,0){
        //Check proprietary bit in Hot-Plug controller
        if(//insertion on slot 1){
            Notify(\_SB.PCI0.P2P2,0)
        }
        if(//insertion on slot 2){
            Notify(\_SB.PCI0.P2P2,0)
        }
        if(//ejection request on slot 1){
            Notify(\_SB.PCI0.P2P2,3)
        }
        if(//ejection request on slot 2){
            Notify(\_SB.PCI0.P2P2,3)
        }
    } //end Method (_L0A, 0)
} //end Scope (\_GPE)

返回页首

Connecting General Purpose Events

ACPI discovers hardware events when a GPE is asserted and a System Control Interrupt (SCI) is raised. Hot-Plug PCI controllers must therefore be wired to the GPE bits of the core chip set. Because of the flexibility of GPEs, there are a number of implementations: a single GPE bit could be used for all Hot-Plug PCI events in the system; another implementation could wire up a GPE bit for each event on each slot.

Regardless of how the events are shared on GPEs, the standard rules for ACPI events must be followed. For more information, see the following sources:

•	Section 5.6.2.2 of the ACPI specification, Revision 1.0b.

Event Flow for Insertion. When a device is inserted into the system, the following takes place:

1.	User: The user inserts the hardware in the slot.
2.	Hot-Plug PCI controller (HPPC): Asserts a GPE.
3.	Core chip set: Raises an SCI.
4.	ACPI driver: Clears the GPE event and runs the _Lxx method associated with the GPE.
5.	_Lxx method: Reads status bits from the HPPC to determine that the event was an insertion event and which slot the event took place on.
6.	_Lxx method: Executes Notify(,0) on the PCI bus that the slot is on.
7.	ACPI driver: Executes _STA methods for the devices specified in Notify() in the previous step.
8.	_STA: Returns 0x0a; that is, the device is present but not enabled.
9.	ACPI driver: Tells the PCI driver to enumerate the bus.
10.	PCI driver: Reads configuration space to identify the device.
11.	PCI driver/PNP subsystem: Loads and starts the drivers for all functions of the device.
12.	Device drivers: Request the functions be turned on.
13.	ACPI driver: Executes _PS0 methods, if present.
14.	PCI driver: Writes to configuration space to turn on the device according to PCI Power Management specifications.
15.	Device driver: Begins using the device normally.

Event Flow for Removal. When the user requests to eject a device, the following steps take place. These steps assume that the hardware has an eject button associated with each device. If it does not, then the user must use the Add/Remove Hardware Wizard to eject a device. In this case, the process would start at step 8 in this list:

1.	User: The user presses the eject button for the slot.
2.	HPPC: Asserts a GPE.
3.	Core chip set: Raises an SCI.
4.	ACPI driver: Clears the GPE event and runs the _Lxx method associated with the GPE.
5.	_Lxx method: Reads status bits from the HPPC to determine that the event was an eject request and which slot the event took place on.
6.	_Lxx method: Executes Notify(,3) function 0 of the slot that is requesting eject.
7.	ACPI driver: Requests the Plug and Play system to eject the device.
8.	PNP: Queries all drivers for all functions of the device, and if successful, tells the drivers to unload.
9.	PCI driver: Writes to configuration space to turn off the device per PCI Power Management specifications.
10.	ACPI driver: Executes _PS3 methods, if present.
11.	ACPI driver: Executes _EJ0.
12.	_EJ0: Engages motors, solenoids, lights, and so on to eject the device. When the device has been ejected and status bits updated accordingly, it returns.
13.	ACPI driver: Executes _STA to verify the device ejected successfully.
14.	_STA: Returns 0x00 (device not present). Had the device not ejected successfully, _STA would have returned 0x05 (that is, present but not functioning).
15.	ACPI driver: Complete cleanup. Had _STA returned 0x05, the ACPI driver would have told the operating system that there was a problem and an error dialog would pop up on the user's screen.

返回页首

Windows Logo Program Timeline

If implemented, SHPCs must conform to the PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0,and to the Windows Logo requirements listed in this section, to take advantage of the built-in support planned for Windows Vista and future versions of Windows. This planned support will eliminate the need for ACPI implementations and vendor-supplied filter drivers. The following requirements are being considered for addition to the Windows Logo Program for Vista.

•	The Manual Retention Latch (MRL) Sensor is described in section 2.2.3 of the SHPC Specification, Revision 1.0. The MRL Sensor is a switch, optical device or other type of sensor that reports the position of a slot’s MRL to the SHPC.  Section 2.3.2 of the SHPC Specification provides for alternatives to the MRL Sensor, such as documentation that describes the proper sequence for insertion and removal of Hot Plug cards.
•	Separate indicators are described in section 2.2.1 of the SHPC Specification. Separate indicators show the attention and power states of SHPC slots.  Section 2.3.1 of the SHPC specification allows for a single indicator under some circumstances.
•	The Attention Button is described in section 2.2.5 of the SHPC Specification.  Section 2.2.5 of the SHPC specification stipulates that this button is optional for the platform; however, support for it must be included in the SHPC driver.

返回页首

Call to Action

Manufacturers of hot-pluggable PCI devices and Hot-Plug PCI controllers should:

•	Develop standard Plug and Play drivers for hot-pluggable devices as specified in the Windows DDK.
•	Implement insertion and removal notifications as defined in the ACPI Specification Revision 1.0b.
•	Implement the _HPP object as defined in the ACPI Specification revision 2.0 for Windows XP.
•	Follow standard rules for implementing ACPI events when connecting to GPE events
•	Be aware of upcoming revisions to the PCI Hot-Plug Specification to include native support for insertion events, removal events and other hot-plug functionality required of standard Hot-Plug PCI controllers.
•	Be aware of resource rebalancing issues for hot-plug devices and PCI-to-PCI bridges. For information, see the list of resources at the end of this article.
•	Be aware of Windows Logo Program for Hardware requirements related to Hot-Plug PCI. For information, see the requirements available on Windows Logo Program Requirements.
•	Plan to develop and support SHPCs for Windows Vista as defined in this white paper.
•	Be aware of upcoming Windows Logo Program for Hardware requirements related to SHPCs.

返回页首

Related Information

•	PCI Hot-Plug Specification at  http://www.pcisig.com
•	ACPI Specifications, Revisions 1.0b and 2.0 at  http://www.acpi.info/
•	Windows DDK
•	PCI-to-PCI Bridges and Cardbus Controllers on Windows