Supporting multiple methods for device hotplug in a single computer

A computer-implemented method is disclosed for use in a computer system. The method includes: (A) receiving an indication of a first hotplug event for a first operating system executing in the computer system; (B) identifying, among a plurality of hotplug handling methods, a first hotplug handling method associated with the first operating system; and (C) handling the first hotplug event using the first hotplug handling method.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to a concurrently-filed and commonly-owned U.S. patent application entitled, “Event Generation for Device Hotplug,” which is hereby incorporated by reference.

BACKGROUND

Computers often contain internal devices, such as network cards and video cards, that may be detached from the I/O bus to which they are connected. For example, if a device malfunctions, it may be necessary to detach the device from the bus and to attach a new device to the bus. Similarly, it may be desirable to detach a device from the bus to replace the device with a different, superior, device.

Detaching a device from the I/O bus of an older computer system while the computer system was running would cause serious damage to the computer system. As a result, detaching a device from such a system required powering down the system, detaching the device (and replacing it with a new device, if appropriate), and powering up the system again. This was tedious and time-consuming. Furthermore, the computer system could not be used for other functions (such as running application programs that did not require the detached device) while it was powered down. This would decrease the productivity of the computer's users. If the computer was a server or other computer that was required for use by multiple users simultaneously, detaching a single device from the computer could disrupt the work being performed by all of those users.

As a result, techniques were developed which made it possible to detach and attach devices to a computer system while the system was running. This ability is referred to as “hotplugging” or “hotswapping” to indicate that the computer is “hot” (powered on) while devices are added to and removed from it.

ACPI (Advanced Configuration and Power Interface) is an open industry specification that is one example of a technology for facilitating hotplugging. ACPI defines a variety of firmware, hardware, and operating system interfaces for accomplishing system configuration, power management, plug 'n play, and a variety of other system-specific behaviors. For example, ACPI defines interfaces for performing hotplug of devices connected to PCI buses.

ACPI uses “general purpose events” (GPEs) for a variety of purposes, including signaling that the user desires to perform a hotplug. GPE events are typically implemented as follows. To signal the occurrence of an incident (such as the pressing of a doorbell) that should trigger a GPE event, a hardware device stores a predetermined value in a pre-designated hardware register in a block of registers referred to as a “GPE block.” This causes a GPE event to be generated and transmitted to the operating system. Each GPE is associated with a firmware method. In response to receiving a GPE event, the operating system executes the associated firmware method. For example, if the event is a doorbell event, then the associated method prepares the device from the corresponding slot to be added/removed.

Older versions of ACPI (such as version 1.0b) only supported a single GPE block, divided into two sub-blocks. Although a single GPE block may have been sufficient for small, single-partition computer systems, it often is not sufficient for multi-partition systems.

For example, a single GPE block, consisting of two sub-blocks, can support a maximum of two sets of 128 GPE events each. Such a GPE block can therefore support at most two cells, each with 128 GPEs. In a multi-partition computer, a partition may contain more than two cells in which GPEs occur, and the total number of events may exceed 256. In such a system, a single GPE block per partition is insufficient to support hotplug in all cells. In some systems, a single GPE block is provided in every cell to simplify wiring and configuration of partitions, but in such systems an operating system that supports older versions of ACPI can still only support hotplug events in a single one of the cells.

ACPI version 2.0 began to support multiple GPE blocks, thereby solving the problem just described. Some operating systems, such as variants of Unix (including the Linux and HP-UX® operating systems), support these newer versions of ACPI. Some operating systems, however, such as some versions of Microsoft Windows operating systems, do not support this and newer versions of ACPI, and therefore cannot take advantage of multiple GPE blocks.

A single computer may include a plurality of “cells,” each of which has its own processor, set of PCI slots, and other hardware. Such a computer may be logically subdivided into a plurality of partitions, each of which may include one or more cells. Consider, for example, a 16-cell computer that may be divided into 1, 2, 4, 8, or 16 partitions having 16, 8, 4, 2, or 1 cell each, respectively. Each partition in such a multi-partition computer may execute a different operating system, some of which support the newer versions of ACPI and some of which do not. Therefore, it is possible for a single complex to include a plurality of operating systems, some of which provide support for multiple GPE blocks and some of which do not.

Operating systems, such as Microsoft Windows operating systems, which support only a single GPE block, do not support “distributed GPEs,” which allow a GPE block in each cell. As a result, such operating systems do not support GPE events in more than two cells of a partition. (ACPI allows a single GPE block to be subdivided into two sub-blocks at two addresses, thereby effectively allowing two cells to have GPE blocks.)

Using conventional architectures, such operating systems do not support hotplug in more than two cells in a partition, because the required GPE events cannot be supported in all cells. It is desirable to support hotplug in all cells in a partition, regardless of the number of cells in the partition and the capabilities of the operating system executing in the partition. Furthermore, it is desirable to support hotplug in all cells of all partitions in a computer system, regardless of the number of partitions and the mixture of operating systems executing in those partitions.

SUMMARY

A computer-implemented method is disclosed for use in a computer system. The method includes: (A) receiving an indication of a first hotplug event for a first operating system executing in the computer system; (B) identifying, among a plurality of hotplug handling methods, a first hotplug handling method associated with the first operating system; and (C) handling the first hotplug event using the first hotplug handling method.

DETAILED DESCRIPTION

Referring toFIG. 1A, a block diagram is shown of one embodiment of a computer system100a.The computer system100aincludes a hardware layer102, a hardware interface layer104, an operating system layer106, and an application program layer107. The operating system and application programs in the computer system100aexecute on hardware in the hardware layer102. The “layers”104,106, and107illustrated inFIG. 1Ado not, therefore, represent physical layers of components which are physically layered on top of the hardware layer102. Rather, the computer system100ais illustrated as consisting of layers102,104,106, and107as an aid to explaining the interactions among hardware and software in the computer system100a.In particular, it is common to conceptualize and illustrate computer systems in terms of such layers to highlight the dependence of elements at a higher layer on elements at lower layers, and to illustrate the flow of control and data among layers.

The hardware layer102comprises the physical components of the computer system100a.Such physical components may include, for example, a processor108, memory storage components110a-c,internal buses and signal lines116-119, bus controllers120a-b,and various peripheral interface cards124-129. The processor108is an instruction-execution device that executes a stream of instructions obtained from memory components110a-c.The processor108contains internal memory storage components referred to as registers130that can be accessed much more quickly than the memory components110a-c.The processor108reads and writes data and instructions from and to the memory components110a-cvia internal buses116and117and the bus controller120a.Far greater data storage capacity resides in peripheral data storage devices such as disk drives, CD-ROM drives, DVD drives, and other such components that are accessed by the processor108via internal buses116,118, and119, bus controllers120a-b,and one or more of the peripheral device interconnect cards124-129. For example, the stored instructions of a large program may reside on a disk drive for retrieval and storage in memory components110a-con an as-needed basis during execution of the program. More sophisticated computers may include multiple processors with correspondingly more complex internal bus interconnections and additional components.

The operating system layer106is a logical layer which includes a software program112referred to as an operating system, which is capable of controlling the hardware components in the hardware layer102. Modern operating systems are relatively large and complex, typically consisting of a large number of sub-programs executing concurrently. At its core, however, the operating system112includes program code which may be utilized by application programs to cause the hardware components in the hardware layer102to perform functions such as reading from and writing to memory and peripheral devices.

The hardware interface layer104, as its name suggests, acts as an interface between the operating system layer106and the hardware layer102. The hardware interface layer104may include hardware, software, firmware, or any combination thereof. One purpose of the hardware interface layer104may be to provide a single abstract interface through which the operating system layer106may communicate with the processor108and other components in the hardware layer102, regardless of the particular manner in which such components are implemented.

The hardware interface layer104includes system firmware132. As will be described in more detail below, the system firmware132performs functions such as writing and reading the values of system-wide parameters.

The application programming layer107includes one or more application programs. Two application programs134a-billustrated inFIG. 1Afor ease of illustration and explanation. The operating system112allocates virtual memory regions136a-bto application programs134a-b,respectively. Note that the virtual memory regions136a-bare not additional regions of physical memory, but rather are logical regions which are mapped to memory locations in the memory components110a-c.Requests by the application programs134a-bto access the corresponding virtual memory regions136a-bare passed through the operating system112, which performs the requested read/write operation on the appropriate location(s) in the memory components110a-c.In addition, the operating system112denies any request by the application programs134a-bto access memory addresses outside of their respective virtual memory regions136a-b.

Referring toFIG. 1B, a block diagram is shown of a different view100bof the computer system100aillustrated inFIG. 1A. The views100aand100bshown inFIGS. 1A and 1Bmay be referred to herein collectively as “the computer system100.”FIG. 1Bdepicts the computer system100not in terms of a series of layers, but instead in terms of a plurality of cells142a-plogically grouped into partitions140a-b.More specifically, there are sixteen cells142a-p,logically subdivided into two partitions140a-bof eight cells each. These particular numbers and distributions of cells and partitions are provided merely for purpose of example.

Note that for ease of illustration and explanation,FIG. 1Aillustrates only a subset of the computer system100. For example, the hardware layer102shown inFIG. 1Aincludes the hardware typically provided in a single one of the cells142a-pshown inFIG. 1B. The computer system100bas illustrated inFIG. 1B, therefore, includes a plurality of hardware layers, one for each of the cells142a-p.Similarly, the operating system layer106shown inFIG. 1Acorresponds to one of the operating systems146a-bshown inFIG. 1B. The computer system100bas illustrated inFIG. 1B, therefore, includes a plurality of operating systems146a-b,one for each of the partitions140a-b.

The computer system100balso includes a manageability processor152. A manageability processor is a processor commonly used in servers to perform system management functions such as accessing the OS console or managing system events. As will be described in more detail below, the manageability processor152itself is not contained within any particular partition or cell and can provide services across cells and partitions. It may present devices within particular partitions or be connected to existing devices within the partition.

The 16-cell computer system100bshown inFIG. 1Bmay, for example, be logically divided into two or more logical partitions, each of which may contain one or more cells. In the example shown inFIG. 1B, the computer system100bis logically subdivided into two partitions140a-b,each of which contains eight cells. Each of these partitions140a-baggregates the computing resources of its cells and provides the behavior of a distinct computer system. For example, partition140aexecutes operating system146aon the cells142a-h,while partition140bexecutes a second operating system146bon the cells142i-p.Techniques for implementing multi-cell, multi-partition computer systems are well-known to those having ordinary skill in the art, and will therefore not be described in detail herein.

A single cell in each partition may be designated as that partition's “root cell” (also referred to as a “core cell”). For example, cell142ahas been designated as the root cell of partition140a,and cell142ihas been designated as the root cell of partition140b.The root cell may be chosen arbitrarily from among a partition's cells. The root cell may perform special functions and contain partition-wide resources for the partition, such as ACPI hardware that is used in generating hotplug events, as will be described in more detail below. Alternatively, there may be no root cell, and partition-wide resources may be located anywhere in the partition.

In the example shown inFIG. 1B, the operating system146aexecuting in partition140ais an operating system that does not support ACPI version 2.0 or greater. For example, the operating system146amay be a version of the Microsoft Windows family of operating systems. In the example shown inFIG. 1B, the operating system146bexecuting in partition140bis an operating system that supports ACPI version 2.0 or greater. For example, the operating system146bmay be a version of the Linux or HP-UX operating systems.

The cells142a-pare provided with corresponding GPE blocks144a-p.Recall that the operating system146asupports only a single GPE block, which may be subdivided into two sub-blocks. Techniques will be described below for enabling the operating system146ato handle hotplug events in any of the cells142a-husing only a single one of the GPE blocks144a-h(such as the GPE block144ain the root cell142a). Recall that the operating system146bsupports multiple GPE blocks. The operating system146bmay, therefore, handle hotplug events in the cells142i-pusing the corresponding GPE blocks144i-p.Techniques will be described below for enabling the computer system100to handle hotplug events correctly in any cell in any partition, regardless of whether the operating system executing in the partition supports the use of multiple GPE blocks.

Referring toFIG. 2, a flowchart is shown of a method200that may be used to initialize the computer system100shown inFIGS. 1A-1B. The method200is performed for each partition in the computer system100. Each partition in the computer system100amay operate in one of two “hotplug modes”: single-block mode or multi-block mode. Operating systems (such as Microsoft Windows Server 2003) that only support ACPI versions 1.0b and lower and therefore only support a single GPE block are referred to herein as “single-block operating systems.” A partition running a single-block operation system may operate in single-block hotplug mode.

Similarly, operating systems (such as Linux and HP-UX) that support ACPI versions 2.0 and higher and therefore support multiple GPE blocks are referred to herein as “multi-block operating systems.” A partition running a multi-block operating system may operate in multi-block hotplug mode.

Partitions140a-bincludes hotplug mode flags148a-bthat indicate whether the partition is operating in single-block mode or multi-block mode. The flags148a-bmay, for example, be stored in firmware.

Returning toFIG. 2, when the computer system100boots up, the value of the hotplug mode flag in each partition may be set by the system firmware132as follows. A user indicates, during partition creation or reconfiguration, whether the current partition is to operate in single-block mode or multi-block mode (step202). The user may provide this indication in any of a variety of ways, such as by specifying the version of ACPI (e.g., 1.0 or 2.0) that the partition's operating system supports, by specifying the operating system to boot into the partition, or by expressly specifying whether the selected operating system supports multiple GPE blocks.

The system firmware132determines, based on the input provided by the user in step202, whether the current partition is to operate in multi-block mode (step204). The system firmware132stores the value of the hotplug mode flag in the current partition based on the outcome of the determination made in step204. For example, assume that the hotplug mode flag has two possible values: MULTI (for multi-block mode) and SINGLE (for single-block mode). Because the flag has only two possible values, the flag may be implemented in a single bit, such as a bit in an auxiliary register in system firmware132. If the user specified that the partition is to operate in multi-block mode, then the value of the flag is set to MULTI (e.g., 0) (step206). Otherwise, the value of the flag is set to SINGLE (e.g., 1) (step208).

Examples of techniques will now be described for supporting hotplug in all cells of a partition regardless of the number of cells in the partition and regardless of whether the operating system executing in the partition is a multi-block operating system. Referring toFIG. 3, a flowchart is shown of a method300that is performed by the computer system100in one embodiment to handle hotplug events for any of the operating systems146a-bexecuting in the computer system100. The method300handles hotplug events in any cell regardless of whether the corresponding operating system supports multiple GPE blocks. Referring toFIG. 4, a dataflow diagram is shown illustrating the flow of data among relevant elements of the computer system100(FIGS. 1A-1B) during execution of the method300shown inFIG. 3.

The manageability processor152receives a hotplug event402from the hardware layer102of one of the cells144a-p,such as cell142b(step302). The hotplug event402is destined for the operating system146ain the same partition140aas the cell142bfrom which the hotplug event402originated. The manageability processor152identifies a hotplug handling method associated with the partition140a(step304). For example, in one embodiment, there are two hotplug handling methods406a-b,one for multi-block partitions and one for single-block partitions. To identify the hotplug handling method, therefore, the manageability processor152may determine whether the partition140ais operating in multi-block mode (step306). The manageability processor152may then select the multi-block handling method406aif the partition140ais operating in multi-block mode (step308) and select the single-block handling method406botherwise (step310).

The manageability processor152handles the hotplug event402using the hotplug handling method identified in step304(step312). As will be described in more detail below, this may involve transmitting a modified version404of the hotplug event402to the operating system146aexecuting in the partition140ain accordance with the hotplug handling method (step314).

Examples of techniques will now be described for implementing the different hotplug handling methods described above with respect toFIGS. 3-4. Recall that, for purposes of example, operating system146ais a single-block operating system and operating system146bis a multi-block operating system. As a result, although each of the cells144a-hin partition140ahas a GPE block, the operating system146acan only access GPE events generated by at most two of the cells144a-h(because a GPE block may be sub-divided into two sub-blocks). To address this problem and enable the operating system146ato access GPE events generated by all of the cells144a-h,in one embodiment the operating system146ais given exposure to GPE events in the root cell142aof the partition140aand the manageability processor152forwards (remaps) GPE events generated in any of the cells144a-hto the root cell142a.In this way the operating system146ais given access to GPE events generated by all cells144a-heven if the operating system146acan only directly access GPE events in the root cell142a.

Such forwarding of GPE events to the root cell of single-block partitions is an example of a first “hotplug handling method” as that term is used herein. For example, in the method300ofFIG. 3, if the manageability processor152determines that the partition in which a hotplug event was generated is a single-block partition, the manageability processor152may forward the hotplug event to the root cell of the partition. If the manageability processor152determines that the partition is a multi-block partition, the manageability processor152may allow the hotplug event to be processed normally. This is an example of a second hotplug handling method.

The techniques described above with respect toFIGS. 3 and 4require the manageability processor152to know whether a partition is operating in single-block or multi-block mode. This may require, for example, the manageability processor152to know which operating system is executing in the partition. In practice it may be difficult or inefficient to provide the manageability processor152with this knowledge. In another embodiment, therefore, the computer system100is provided with the ability to handle hotplug events in all cells of all partitions, regardless of the number of cells in a partition and regardless of whether multi-block operating systems are executing in the partitions.

In general, in this embodiment, whenever a cell generates a hotplug event, the manageability processor152replicates the event and forwards it (or a modified version of it) to the root cell of the cell partition. In other words, two different hotplug events are fired using two different methods. The manageability processor152, therefore, does not need to know which method is appropriate for use with the executing operating system. Instead, the computer system100is pre-configured (based on the firmware tables and methods passed to the operating system by the system firmware132) to expose the operating system only to the hotplug event that is transmitted to it using the appropriate method.

Examples of ways to implement this technique will now be described in more detail. Assume for purposes of example that each of the GPE blocks144a-pis capable of representing 256 values, numbered from 0-255. In one embodiment, the “original” hotplug events that are generated by a cell use event numbers in the range 0-63. Note that such hotplug events need not use all event numbers in this range. When a hotplug event is forwarded to the root cell of a partition, the “forwarded” event is remapped to an event number in the range 64-255. As a result, both an original and a forwarded hotplug event can be generated without having overlapping event numbers. Note that the particular range (0-255) and breakdown of values (0-63 and 64-255) are provided herein merely as examples and do not constitute limitations of the present invention.

In this embodiment, a single-block operating system is only exposed to hotplug events in the range 64-255 in the root cell of the operating system's partition, while a multi-block operating system is only exposed to hotplug events in the range 0-63 in each of the cells in the operating system's partition. As a result, although two hotplug events are fired whenever the user initiates a hotplug operation, the corresponding operating system will only be exposed to a single hotplug event, regardless of whether the operating system is a single-block or multi-block operating system.

More specifically, if an original hotplug event in the range 0-63 is generated in a cell of a partition with a single-block operating system, that event will be forwarded to the root cell of the partition as an event in the range 64-255. The operating system will only see the forwarded event, because events in the range 0-63 have been masked from the operating system. Similarly, if an original hotplug event in the range 0-63 is generated in a cell of a partition with a multi-block operating system, that event will be forwarded to the root cell of the partition as an event in the range 64-255. The operating system will only see the original event, because events in the range 64-255 have been masked from the operating system.

To initialize this scheme, each operating system is informed of a range of valid event numbers at bootup. Returning toFIG. 2, if the operating system in the current partition supports multiple GPE blocks, then the system firmware132exposes to the operating system: (1) hotplug events in a first range (e.g., 0-63); and (2) methods for handling only those events (step208). If the operating system in the current partition supports only a single GPE block, then the system firmware132exposes to the operating system: (1) hotplug events in a second range (e.g., 64-255); and (2) methods for handling only those events (step212). The methods exposed in step212are aware of additional steps required in the single-block implementation, as will be described in more detail below with respect toFIG. 5. As is well-known to those having ordinary skill in the art, the system firmware132exposes GPE blocks using standard ACPI tables that are passed to the operating system during system startup.

The method200shown inFIG. 2may be performed for each of the partitions140a-bin the computer system100b.Upon completion of the method200for all of the partitions140a-b,the hotplug mode flags148a-bcontain appropriate values and the operating systems146a-bhave exposure to appropriate ranges of GPE events. In addition to only exposing appropriate events in steps210and212, the system firmware132may perform additional steps to hide events from the operating systems146a-bexecuting in the computer system100. For example, the system firmware132may disable events that are out of range for an operating system, such as by setting the GPE enable/disable bit to “disable” for those events. In other words, in step210the system firmware132may disable GPE events in the second range (e.g., events 64-255), while in step212the system firmware132may disable GPE events in the first range (e.g., events 0-63).

Note that steps210and212need not be performed if the manageability processor152knows which operating system is executing in each partition, since in such a case it is possible for the manageability processor152to transmit only a single GPE event to each operating system (as described above in conjunction withFIGS. 3 and 4).

Referring toFIG. 5, a flowchart is shown of a method500that is performed by the computer system100in one embodiment to handle hotplug events for any of the operating systems146a-bexecuting in the computer system100. The method500handles hotplug events in any cell regardless of whether the corresponding operating system supports multiple GPE blocks, and does not require the manageability processor152to know which operating system is executing in any partition. Referring toFIG. 6, a dataflow diagram is shown illustrating the flow of data among relevant elements of the computer system100(FIGS. 1A-1B) during execution of the method500shown inFIG. 5.

Upon powering up the computer system100, the manageability processor152may present the user608with a manageability user interface (UI)616. In general, the user608may provide commands620to the manageability processor152through the manageability UI616, in response to which the manageability processor152may execute the commands620. Examples of embodiments of the manageability UI616are described in more detail in the above-referenced patent application entitled, “Event Generation for Device Hotplug.”

If the user608desires to add a device to or remove a device from the computer system100, the user608may provide an appropriate command620, referred to herein as a “hotplug command,” to the manageability interface616(FIG. 5, step502). The management processor152identifies the type of the hotplug event specified by the hotplug command620(step504). Examples of hotplug event types include add, remove, and replace. The manageability processor152stores the event type in an event type indicator in the corresponding partition (step506). The computer system100may, for example, include an auxiliary register in each cell or each partition. Each of the hotplug event type indicators150a-bmay be represented as a bit in the auxiliary register.

Use of the event type indicators150a-ballows a larger number of hotplug events to be recognized. For example, if a hotplug event range of 0-255 were used to represent both add and remove events, then at most 128 slots could be supported because of the need to have two events (add and remove) per slot. If instead the auxiliary register is used to specify whether an event is an add or remove event, then each event in the range 0-255 may be used for both add and remove events for a single device slot.

The manageability processor152generates an original hotplug event602is generated in the cell containing the device slot specified by the user608in the hotplug command620, such as cell142bin partition140a(step508). Examples of techniques for generating a hotplug event are described in the above-referenced patent application entitled, “Event Generation for Device Hotplug.” Note that a hotplug event may be generated in response to user input other than input provided through the manageability UI616. For example, a hotplug event may be triggered when the user608presses a physical doorbell or other switch in the computer system100.

Recall that the operating system146aexecuting in the partition140asupports only a single GPE block (i.e., the GPE block144ain the root cell). Assume that the original hotplug event has event number 9 in the GPE block144bof cell142b.This GPE event will not, however, be seen by the operating system146abecause that GPE block, which is in a non-root cell, was not exposed at bootup to the operating system146a,which is operating in single-block mode. Furthermore, even if the GPE event, having event number 9, had fired in the root cell, only GPE events in the range 64-255 were exposed to the operating system146aduring bootup (seeFIG. 2), and the event would therefore not be seen by the operating system146a.Techniques for exposing this event to the operating system146ausing alternate means will be described below.

The manageability processor152translates the event number of the original hotplug event602to a new event number for use in a forwarded hotplug event604(step510). The purpose of this translation is to map event numbers used by multi-block operating systems to event numbers that do not overlap with those used by multi-block operating systems. If, for example, as described above, multi-block operating systems use the event number range 0-63, the translation step308may translate event numbers from the range 0-63 to the range 64-255. Note that some of the event numbers in range 0-63 may be unused or not used for hotplug events. For example, in one embodiment, there are 16 cells, each with 12 slots having 12 corresponding events, for a total of 192 events.

One example of a technique for translating the event number of the original hotplug event602to the event number of the forwarded hotplug event604is as follows. Let CELL_NUMBER be the number of the cell in which the original hotplug event occurred, and let SLOT_IN_CELL be the slot (e.g., PCI slot) at which the original hotplug event occurred. Assume for purposes of example that each cell has 12 slots, and that the range of 192 GPE event numbers is divided into two sets of 96 event numbers, corresponding to the two halves of the associated GPE block.

Let GPE_SET_NUMBER indicate whether an event number is in the first or second set of 96 events. Let GPE_NUMBER_IN_SET indicate the number of the event within its set. For example, GPE_SET_NUMBER=0 and GPE_NUMBER_IN_SET=34 refers to event number 34 in the first set of 96 events. Similarly, GPE_SET_NUMBER=1 and GPE_NUMBER_IN_SET=56 refers to event number 56 in the second set of 96 events. Values of GPE_NUMBER_IN_SET and GPE_SET_NUMBER may be derived from CELL_NUMBER and SLOT_IN_CELL using Equation 1 and Equation 2:
GPE_NUMBER_IN_SET=((CELL_NUMBER*12)+SLOT_IN_CELL) % 96   Equation 1
GPE_SET_NUMBER=FLOOR(((CELL_NUMBER*12)+SLOT_IN_CELL)/96)   Equation 2

The event number of the forwarded event may then be generated using Equation 3:
FORWARDED_EVENT_NUMBER=64+GPE_SET_NUMBER*96+GPE_NUMBER_IN_SET   Equation 3

The manageability processor152then triggers the forwarded hotplug event604in the root cell142aof the same partition as the original hotplug event602, but with the translated event number (step512). This effectively forwards the original event602from the original cell142bto the root cell142aof the same partition140a.

Although two hotplug events have now been generated within the partition140a,the operating system146aexecuting within the partition140awill only receive a single one of these events602and604. Recall that the operating system146ais a single-block operating system in the present embodiment. As described above, the operating system146ais only exposed to events in the range 64-192 as a result of step212inFIG. 2. The operating system146a,therefore, does not see the original event602because its event number is in the range 0-63. Furthermore, as described above, the original event602may be disabled by the system firmware132. When the event number of the original event602, however, is translated to the range 64-192 and forwarded as the forwarded event604to the root cell142a,the operating system146asees the forwarded event604.

Now consider an alternative example in which a hotplug event is generated in one of the cells142i-pin partition140b.Recall that the operating system146bexecuting in the partition140bsupports GPE blocks in all of the cells142i-p.

Now assume that a user triggers an original GPE event in cell142k,such as by pressing a doorbell for the device installed in slot12(not shown) in cell142k.Assume for purposes of example that this original GPE event is signaled in the GPE block144kof cell142kand has event number 12. This original GPE event will be seen by the operating system146bbecause GPE events numbered 0-63 were exposed to the operating system146bduring bootup (seeFIG. 2).

When the event number of the original event, however, is translated to the range 64-192 and forwarded to the root cell142i,the operating system146bdoes not see the forwarded event because its event number is outside of the exposed range 0-63. Furthermore, as described above, the forwarded event may be disabled by the system firmware132.

Returning toFIG. 5, the operating system146ahandles the event that it sees using the corresponding firmware method (step514). Techniques for associating hotplug events with corresponding firmware methods, and for executing such methods, are well-known to those having ordinary skill in the art. When the method is executed in single-block mode, the system firmware132reads the auxiliary register to identify the event type (e.g., add or delete) and performs the method appropriately.

The firmware event handling methods that are exposed to the operating system146amay be programmed with the ability to determine whether the partition of the hotplug events602and604is operating in single-block mode. If the partition is operating in single-block mode, then the event handling method identifies the cell and slot number of the original hotplug event602. To do this, the method decodes the event number of the forwarded hotplug event604. Assume again, for example, that the range of 192 hotplug events (numbered 64-255) is subdivided into two groups of 96 events each. In such a case, the mapping described above may be reversed as shown in Error! Reference source not found. Equation 4 and Equation 5:
CELL_NUMBER=FLOOR((FORWARDED_EVENT_NUMBER−64)/12)   Equation 4
SLOT_IN_CELL=(FORWARDED_EVENT_NUMBER−64) % 12   Equation 5

One the values of CELL_NUMBER and SLOT_IN_CELL have been identified, the event handling method may handle the hotplug event using conventional techniques.

Among the advantages of the invention are one or more of the following. In general, techniques disclosed herein enable a single computer system to support device hotplug in all cells of all partitions in a multi-partition computer system, regardless of the number of cells in each partition and regardless of whether any particular operating system in the computer system supports multiple GPE blocks. The computer system may include a plurality of operating systems, some of which support ACPI version 1.0b or lower (and therefore do not support multiple GPE blocks) and some of which support ACPI version 2.0 or higher (and therefore do support multiple GPE blocks). As a result, the computer system may include both kinds of operating systems without sacrificing the ability to provide full support for device hotplug in all cells of the computer system.

The techniques disclosed herein eliminate the need to use different hardware or firmware for each operating system to support hotplug for those operating systems. Instead, a single set of hardware/firmware in the manageability processor152may support hotplugging on multiple operating systems even when those operating systems handle hotplug in a variety of ways. Furthermore, the same techniques may be applied to forwarding not only hotplug events but any kind of event.

Furthermore, the techniques disclosed herein may be implemented in a computer system without modifying the operating system of the computer system. Rather, it is only necessary that some component or components of the computer system (such as the manageability processor152) be modified to implement the techniques disclosed herein. By eliminating the need to modify operating systems, the techniques disclosed herein therefore enable computer systems to be equipped with enhanced hotplugging capabilities at lower cost than would be possible if it were necessary to modify one or more operating systems executing on the computer systems.

Furthermore, the techniques disclosed herein simplify the implementation of hotplug events in partitionable computer systems. In such a system, the hardware may be logically subdivided into multiple partitions, each of which may include multiple cells, each of which may include multiple chasses, each of which may include multiple I/O slots. Centralizing the handling of hotplug events in the manageability processor152allows the system to avoid the need to perform complicated routing of hotplug events within such a computer system.

Although certain functions are described herein as being performed by the manageability processor152, this is not required. Rather, such functions may be performed by other components, whether in hardware, software, firmware, or any combination thereof.

The term “hotplug” is used generically herein to refer to the act of adding, removing, or replacing a device in a computer system while the computer system is running. Various terms may be used herein to refer to installing a device in a computer system, and should all be considered to have the same meaning herein: “add,” “install,” “insert,” and “activate.” Similarly, various terms are used herein to refer to uninstalling a device from a computer system, and should all be considered to have the same meaning herein: “remove,” “de-install,” “uninstall,” and “deactivate.”

Although certain examples herein may refer to PCI buses and devices connected to such buses, this is merely an example. The techniques disclosed herein may be used in conjunction with any kind of bus and device. Similarly, although certain examples herein refer to particular operating systems (such as the Microsoft Windows family of operating systems), these are merely examples. The techniques disclosed herein may be used in conjunction with any kind of operating system.

Although certain embodiments described above use a “root” cell, embodiments of the present invention are not limited to those involving the use of a root cell. Rather, the techniques disclosed herein may be used to handle hotplug events using different methods in a single complex even when no cells are designated as a “root” cell. Furthermore, the techniques disclosed herein may be used to forward (remap) hotplug events to cells that contain the necessary ACPI resources, even if such cells are not designated as “root” cells.

The techniques described above may be implemented, for example, in hardware, software, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on a programmable computer including a processor, a storage medium readable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output. The output may be provided to one or more output devices.

Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions include, for example, all forms of non-volatile memory, such as semiconductor memory devices, including EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable Gate Arrays). A computer can generally also receive programs and data from a storage medium such as an internal disk (not shown) or a removable disk. These elements will also be found in a conventional desktop or workstation computer as well as other computers suitable for executing computer programs implementing the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor, or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.