Emulating a USB host controller

In at least some embodiments, a method comprises emulating a Universal Serial Bus (USB) host controller at a computer system. The method further comprises using the emulated USB host controller to interface a remote management console with the computer system.

BACKGROUND

This invention relates in general to the field of electronics and more particularly to emulating a Universal Serial Bus (USB) host controller. The Universal Serial Bus (USB) is a host-centric bus in which the host initiates all of the transactions. USB has enjoyed broad adoption in part because it makes personal computer (PC) peripheral expansion very easy to accomplish.

Virtual devices can be used in remote administration applications in order to manage/monitor a computer system such as a server from a remote location. Some previous implementations of virtual devices have utilized a USB device core included in the management subsystem that had to be connected to the monitored system's USB host controller and controlled by firmware running on the management subsystem. Because it is a single device core, only one device can be emulated at a given time. Also, the virtual device requires real USB device hardware as well as a port on the system's USB host controller to be implemented.

For a background on the operation of a conventional USB host controller, a design guide entitled “Universal Host Controller Interface (UHCI) Design Guide,” Revision 1.1., March 1996, by Intel Corporation provides a good background on a UHCI's design and operation and is hereby incorporated by reference. A discussion on USB virtual devices can be found in U.S. Pat. No. 6,636,929, entitled “USB Virtual Devices” by Frantz et al. which is also incorporated by reference as if fully set forth herein.

NOTATION AND NOMENCLATURE

DETAILED DESCRIPTION

Embodiments of the invention are configured to emulate a Universal Serial Bus (USB) host controller as well as USB peripheral devices and USB hubs. The emulated USB host controller acts as an interface between a remote management console and a host computer system. Thus, when the host computer system receives data from the remote management console, the host computer system recognizes the data as if received from a USB peripheral device via a USB host controller. By emulating USB hubs, simultaneous recognition of a plurality of emulated USB peripheral devices (e.g., a keyboard, a mouse, a floppy drive, a CD-ROM drive, a flash memory device or a printer) by the host computer system is possible. Emulating the different USB peripheral devices enables the host computer system to receive data from the remote management console in different USB-compatible formats (e.g., a keyboard data format, a mouse data format, a floppy drive data format, a CD-ROM drive format, a Flash memory data format, or a printer data format). The USB drivers implemented by the host computer system to interpret data from the emulated USB host controller and the emulated USB peripheral devices are compatible with existing USB protocols (i.e., designing and installing new drivers to recognize data received from the remote management console is unnecessary).

In at least some embodiments, emulation of the USB host controller, the USB hubs, and the USB peripheral devices is provided by a baseboard management controller (BMC) of the host computer system. The BMC also may provide remote management capabilities such as supporting a graphic interface that is used to interface the host computer system with the remote management console. In at least some embodiments, the BMC couples to a communication bus interface of the host computer system other than the serial communication links described in the USB protocol specifications (e.g., the communication bus may be based on a Peripheral Component Interconnect (PCI) protocol or some other protocol). In such embodiments, the data received from the remote management console by the baseboard management controller is converted from one communication protocol (e.g., a USB protocol) to another communication protocol (e.g., a PCI protocol) for use by the host computer system.

In at least some embodiments, the BMC supplies the host operating system (OS) with hot-plug events via Universal Host Controller Interface (UHCI) registers such as port status and control registers “PORTSC1” and “PORTSC2.” In a real UHCI controller, the PORTSC1and PORTSC2registers represent physical, wired links to USB devices. However, in at least some embodiments presented herein, these registers represent connections to virtual devices (there is no actual wiring or bus connections involved). The BMC firmware can determine which device the host system is trying to communicate with by examining the address in the transfer descriptor (TD) token field and the connect and enable status of the PORTSC registers.

In at least some embodiments, a virtual keyboard is associated with PORTSC1and a virtual hub is associated with PORTSC2. To notify a host system to recognize the virtual keyboard and virtual hub, a Connect bit (bit0) and possibly a change-in-connect bit (bit1) is asserted for each port. In response to the asserted connect bits, the host system detects the virtual devices and attempts to enumerate (i.e., assign an address) and configure the virtual devices.

Initially (before the virtual devices have been given addresses by the host system's USB driver), both the virtual keyboard and the virtual hub have the address “zero.” In this state, communication with the virtual devices based on address alone is problematic because both virtual devices have the same address. To overcome the addressing problem, the host system can choose which device to communicate with by enabling or disabling each PORTSC register (bit2of the PORTSC registers). Because the BMC firmware can determine the values of the bits in the PORTSC registers, data can be transferred to the appropriate virtual device. Once a virtual device has been enumerated (e.g., given a USB address other than zero), the port for that virtual device can be enabled permanently or temporarily (e.g., until the next reset event) and the BMC firmware can find the virtual device using its associated address.

If desired, additional virtual devices can be added through the virtual hub. Like the PORTSC registers, the virtual hub is simply a representation of more connection points (i.e., wires and busses are not necessary to represent additional USB devices). In at least some embodiments, the virtual hub provides a standardized interface for representing more connected devices. Like the PORTSC registers, virtual devices “attached” to the hub go through the enumeration process, and like the PORTSC registers, the virtual hub ports provide a Connect signal or bit. In this manner, the host OS is able to enumerate and communicate with virtual USB devices that are virtually attached to the virtual hub.

Referring now to the drawings and in particular toFIG. 1, there is shown a system100in accordance with embodiments of the inventions. As shown, the system100comprises a computer101(such as a server) coupled to a remote management console130via a network140. The computer101comprises a plurality of central processing units (CPUs)102,104coupled to a bus bridge, commonly referred to in the computer industry as a “North Bridge”108. The North Bridge108couples the CPUs102,104to system memory106and to other components of the computer101. The North Bridge108has a significant impact on the computer's performance given that it defines the speed at which data flows between the CPUs102,104and the system memory106.

As shown, the North Bridge108couples to an input/output (I/O) bridge150via a “fast” serial bus link (compared to a legacy bus link) having, in some embodiments, eight serial communication channels (×8). This bus may be a proprietary chipset interconnect or may be consistent with an established industry standard such as PCI-Express. In at least some embodiments, the I/O bridge150couples to PCI slots152,154via a PCI 66/64 communication interface. The PCI slots152,154may be configured to support insertable/removable PCI cards that enhance the functionality of the computer system101.

The North Bridge108also couples to an I/O bridge170via another “fast” bus link (compared to a legacy bus link) having, in some embodiments, eight communication channels (×8). As shown, the I/O bridge170couples to a Small Computer System Interface (SCSI) module160via a PCI Express (PCI-E) communication bus. The SCSI module160supports several storage disks162,164,166based on a SCSI communication protocol. The I/O bridge170also couples to a Network Interface Card (NIC)124via a PCI-E communication bus. The NIC124enables the computer system101to communicate with other computers or network devices based on a network communication protocol such as Ethernet or Transmission Control Protocol/Internet Protocol (TCP/IP). The I/O bridge170also couples to PCI-E slots172(e.g., via a communication bus having, in some embodiments, four communication channels (×4)). The PCI-E slots are configured to support insertable/removable PCI-E cards that enhance the functionality of the computer system101. Those skilled in the art will appreciate that the width of the fast bus links as well as PCI-E connections for slots and devices are chosen based on the anticipated bandwidth of the connected devices. Other interconnects as well as other lane widths may be chosen by the system designer.

As shown, the North Bridge108also couples to a South Bridge115via a legacy communication bus link. This bus link may be a proprietary chipset interconnect or may be consistent with an established industry standard such as PCI-Express. In at least some embodiments, the South Bridge115comprises a USB host controller116that couples to and supports USB peripheral devices such as a USB mouse117, a USB keyboard (KB)118and a USB printer119. Those skilled in the art will appreciate that these devices may be coupled through USB connectors (not shown) and may be optional for the proper functioning of the server. The South Bridge115also couples to and supports a compact disk read-only memory (CD-ROM) drive180. The South Bridge115also couples to a Super input/output (I/O) interface174via a low-pin-count (LPC) bus. The Super I/O (SIO)174couples to and supports a Flash ROM176as well as a floppy drive190, a legacy keyboard (KB)192, a legacy mouse194and Universal Asynchronous Receiver/Transmitters (UARTs)196. Like the USB devices mention above, the SIO174provides interfaces to which the enumerated legacy devices may be attached. The presence of a physical legacy keyboard or mouse may not be required for proper server operation.

As shown, the South Bridge115also couples to and supports a video card112which may optionally (selectively) be coupled to a monitor113. The South Bridge115also couples to and supports a baseboard management controller (BMC)114. In at least some embodiments, the video card112and the BMC114couple to the South Bridge115via a PCI 33/32 communication bus. Alternatively, the BMC may be coupled to the host via another suitable communication interface such as PCI-Express, PCI-X, 66/64, LPC, or the like. The BMC114provides remote management capabilities for the computer system101. One example of a BMC114is referred to as an Integrated Lights-Out (iLO) processor. Examples of remote management capabilities include, but are not limited to console redirection, temperature monitoring, fan control/monitoring, remote power management, and remote media redirection.

In at least some embodiments, the BMC114enables a remote management console (e.g., another computer)130to communicate with and control functions of the computer system101via a network140. The network140may be a local area network (LAN) or a wide area network (WAN). In at least some embodiments, the remote management console130communicates with the computer system101via a UNIX-based communication protocol such as Telnet. In such embodiments, data that is transferred from the remote management console130to the BMC114may be converted from one communication protocol (e.g., a network protocol such as TCP/IP) to another communication protocol (e.g., a USB protocol).

As shown, the BMC114comprises software/firmware/hardware126configured or programmed as an emulated USB host controller127(i.e., the software/firmware/hardware126pretends to be a USB host controller). In at least some embodiments, the software/firmware/hardware126is also configured or programmed as emulated USB peripheral devices and emulated USB hubs128(i.e., the firmware/hardware126also pretends to be one or more USB peripheral devices and, if necessary, USB hubs). The emulated USB host controller126is configured to provide some or all of the functions provided by a USB host controller. Since the emulated host controller126needs only to serve as a compatible communication interface with the host, it may exclude logic that is required to communicate with actual USB devices. This advantageously makes the emulated host controller126smaller and less complex. There are a plurality of USB-compatible host controllers that could be emulated by the BMC114. In the embodiments described herein, the emulated USB host controller127is based on a Universal Host Controller Interface (UHCI) specification. Alternatively, the emulated USB host controller127could be based on an Open Host Controller Interface (OHCI) specification or an Enhanced Host Controller Interface (EHCI) specification.

The emulated USB host controller127and the emulated USB peripheral devices/hubs128of the BMC114enable data received from the remote management console130to be recognized by the computer system101(the host computer system) based on existing USB drivers. As shown, the South Bridge115of the computer system101already comprises a USB host controller116that supports USB peripheral devices117,118,119. Thus, the USB drivers that support the USB host controller116and the USB peripheral devices117,118,119(e.g., the USB drivers enable the USB host controller116and the USB peripheral devices117,118,119to communicate with other components of the computer system101) can also support the emulated USB host controller127and the emulated USB peripheral devices/hubs128. In this manner, data from the remote management console130is recognized by the computer system101.

As an example, the remote management console130may be monitoring the operation and performance of the computer101. If the computer101is a “headless” device (e.g., a server), the remote management console130can display information regarding the condition of the computer101on a real-time basis. Using the emulation capabilities of the BMC114, the remote management console130and peripheral devices of the remote management console (e.g., a floppy drive, a CD-ROM drive) can, for example, allow the computer101to reboot from a remotely mounted device if an emergency or maintenance condition occurs requiring a reboot. If such a condition occurs, the computer101is able to recognize an emulated floppy drive or emulated CD/ROM drive provided the BMC114and use one of the emulated drives as the boot-up device (even if a real floppy drive or CD/ROM drive of the computer101is unavailable).

Thus, the remote management console130or a user of a remote management console130is able to control the boot-up process of the computer101from a remote location (e.g., via an Internet or other network connection). In at least some embodiments, an administrator at the remote management console130can communicate with the BMC114via a network connection (e.g., via a web page interface) and select a “virtual device” from a menu in order to emulate the floppy drive, the CD-ROM drive or other USB peripheral devices at the managed computer101. If a user selects to emulate multiple USB peripheral devices, the BMC114is able to emulate one or more USB hubs such that the host computer system101is able to simultaneously recognize the plurality of emulated USB peripheral devices. Using software, the BMC114is able to emulate as many USB hubs and USB peripheral devices as desired. Thereafter, the administrator at the remote management console130is able to control the boot-up process, memory access or other remote management tasks via the BMC114.

If the data from the remote management console130is transmitted using a communication protocol that is not USB-compliant (e.g., a Network protocol), the BMC114is also configured to convert data from the non-compliant protocol to a USB-compliant protocol. In one embodiment, the BMC114examines transfer descriptors and other linked list data structures created by the host in system memory consistent with the USB host controller interface specification. Through these data structures, the BMC114may discern operations requested by the host CPU. For example, if the emulated device is a USB mass storage device, the BMC may discern a block read or block write command to the USB media. This discerned operation may be relayed to the remote management console130through the network140. Software running on the remote management console130may receive the command and deliver a response through communication packets on the network140. The BMC114may receive the response, and fill in the data structures accordingly. For example, if the discerned operation was a block read, the BMC114may begin transferring the requested block data to the host through a means consistent with the desired USB host controller interface specification. The format of the packets used to communicate between the BMC114and remote management console130may be chosen based on the system designer's requirements. Preferably, a guaranteed delivery protocol is chosen, such as Transmission Control Protocol (TCP).

As described above, software/firmware/hardware126of the BMC114provides an emulated USB host controller127. In at least some embodiments, a combination of hardware and software is implemented to emulate the different functions of a USB host controller. For example, one function of a USB host controller relates to performing “list walking.” In order to communicate with the USB host controller, the host builds a linked list in host memory106. Elements in the linked list contain a pointer to the next element as well as command/status/data. As used herein, list walking means reading the next element from host memory, and determining whether it needs processing (some elements are queue heads which just contain pointers to other elements, and some are transfer descriptors that are inactive). If it does not need processing the next element is loaded (based on the pointer). This continues until an active transfer descriptor is found that needs to be handled. In at least some embodiments, hardware components of the BMC114implement all list walking states of a USB host controller up to and including the “Fetch TD” state of the USB host controller and software emulates all list walking states after the Fetch TD state of a USB host controller. Alternatively, other combinations of hardware and software may be used to implement the list walking states of the emulated USB host controller127.

In embodiments which use a software-only solution for list walking, the BMC processor's ability to perform other duties for the BMC114decreases (i.e., the processor is being used to execute software). In embodiments which use a hardware-only solution for list walking, such as a real USB host controller, flexibility is limited. In some embodiments, both hardware and software are implemented for list walking to reduce the above-mentioned disadvantages. For example, if the “Fetch TD” state is selected as the transition point between hardware and software, the BMC's processor could be offloaded from performing the “mindless” searching of the list and other hardware could perform the searching. Once a TD is found that requires flexibility, software could be executed by the BMC's processor to provide the desired flexibility.

FIG. 2shows a state diagram200that is performed by the emulated USB host controller127in accordance with embodiments of the invention. The state diagram200contains transitions for standalone transfer descriptors (TDs) as well as queued TDs. TDs are descriptors that provide information on the characteristics of a transaction requested on the USB by a client. The state diagram200allows for TDs and QHs to be referenced from any link pointer which may be encountered by the emulated USB host controller127. Most of the states referenced in the state diagram200inFIG. 2follow a USB schedule list traversal decision table as discussed in the reference UHCI design guide (see table9in the design guide). As previously mentioned the emulated USB host controller127could alternatively follow OHCI or EHCI design guides.

In some embodiments, the entire state diagram200(i.e., the list walking function of a USB host controller based on UHCI) is emulated using software that is stored and executed by the BMC114. In alternative embodiments, a combination of hardware and software emulates the state diagram200. For example, all the states up to the “Execute TD” state may be performed with the assistance of hardware components of the BMC114, while the rest of the states may be performed using software that is stored and executed by the BMC114.

FIG. 3shows a USB host controller register set150in accordance with embodiments of the invention. InFIG. 3, the USB host controller register set150is described as a component of the BMC114ofFIG. 1although other embodiments are possible. As shown inFIG. 3, the USB host controller register set150couples to host interface logic361. The host interface logic361interfaces the USB host controller register set150with a host computer system (e.g., the computer system101ofFIG. 1). In some embodiments, the host interface logic361is compatible with a PCI interface. This is due to the design of the BMC114, which (inFIG. 1) is configured to reside on a peripheral communication bus (PCI 33/32). Alternatively, the host interface logic361could be compatible with other communication busses such as PCI Express (PCI-E) in accordance with other BMC embodiments (i.e., BMC embodiments could be configured to reside on any existing or future communication bus).

In at least some embodiments, the host computer system has limited access to the USB host controller register set150as indicated by the “bus” arrows364,365connecting the host interface logic361only to the PCI Configuration registers300and the UHCI specification registers320. The host computer system also can be accessed by a USB host controller walker engine395through a “bus” connection366. The USB host controller walker engine395accesses host memory (e.g., the system memory106ofFIG. 1) through the host interface logic361.

The USB host controller register set150also couples to BMC interface logic371. The BMC interface logic371interfaces the USB host controller register set150with other components of the BMC114such as firmware/hardware components (e.g., the software/firmware/hardware126) that are being used to emulate USB peripheral devices and USB hubs. As shown, the BMC interface logic371has access to all of the USB host controller register set150as indicated by the “bus” arrow connecting to the full USB host controller register set block150.

The USB host controller register set150comprises PCI configuration registers300and USB host controller I/O registers310. The PCI configuration registers300are common to any PCI function. In at least some embodiments, the PCI configuration registers300are configured to identify the USB host controller register set150as a USB host controller. In this manner, the operating system of a host computer system (e.g., the computer system101) recognizes the USB host controller register set150as an actual USB host controller (even though some or all of the USB host controller functions provided by the USB host controller register set150are emulated).

The USB host controller I/O registers310comprise all of the registers that are specific to embodiments of the invention. As shown, the USB host controller I/O registers310comprise UHCI specification registers320and virtual (emulated) USB host controller registers330. The UHCI specification registers320are simply the registers that are required by the UHCI specification. In alternative embodiments, the UHCI specification registers320could be replaced by OHCI or EHCI specification registers. As shown, the port status and control registers327A-327N can be replicated to provide as many ports as needed. In at least some embodiments, the port status and control registers327A-327N comprise 8 ports.

The virtual USB host controller registers330provide an emulated USB host controller (e.g., the emulated USB host controller127ofFIG. 1). In some embodiments, the virtual USB host controller registers330are associated with firmware/hardware (e.g., the software/firmware/hardware126) of the BMC114that emulates a USB host controller. As shown, the virtual USB host controller registers330comprise a PCI interrupt (INT) vector register331, an input/output processor (IOP) INT vector register332, and an IOP INT mask register333that will later be described. The virtual USB host controller registers330also comprise an optional walker block348having USB host controller walker registers340that are used to control and receive status from USB host controller walker engine395that interfaces with the host computer system via the host interface logic361.

Based on the USB host controller walker registers340, the USB host controller walker engine395examines linked lists in host memory. In at least some embodiments, the USB host controller walker engine395is linked to the UHCI specification registers320. In this manner, the USB host controller walker engine395is able to determine the frame number (by accessing bits in the frame number register323) that the USB host controller walker engine395is currently processing (e.g., the current frame number is shown as the value “i” in the state diagram200shown inFIG. 2). Also, the USB host controller walker engine395is able to determine the frame address (by accessing bits in the frame list base address register324) and whether or not to “walk” in the first place (by accessing a run/stop bit in the USB command host controller command register322).

In at least some embodiments, the USB host controller walker registers340provide a way for software/firmware of the BMC114to control and monitor the USB host controller walker engine395. For example, the USB host controller walker command register341contains initialize (init), run, and interrupt clear bits. The init, run, and interrupt clear bits enable the USB host controller walker engine395to start, to stop and to re-initialization as needed. The USB host controller walker status register342contains a number of error bits for use by BMC firmware in the event of an error on the host. The error bits enable the USB host controller walker status register342to track error conditions. For example, in some embodiments, a standard set of PCI error conditions may be tracked (e.g., a “Grant Timeout” condition, a “target ready” (TRDY) timeout condition, and a “Livelock” condition).

The USB host controller walker status register342also contains the following five bits for conveying status of the USB linked list: TD active, USB host controller walker (UHCW) 1 ms frame timeout, UHCW queue context, IOC frame, and UHCW 2 ms frame timeout. These status bits enable the USB host controller walker status register342to convey status and error conditions encountered by the USB host controller walker engine395to the BMC114. Specifically, the TD active bit indicates whether an active transfer descriptor (TD) has been encountered. The UHCW 1 ms frame timeout bit indicates whether a one millisecond (ms) frame timer has expired. The UHCW queue context bit indicates the state of a “Qcontext” bit (see the state diagram inFIG. 2). The IOC frame bit indicates whether or not the host expects an interrupt from the current TD upon completion of handling the TD. The UHCW 2 ms frame timeout bit indicates whether a two millisecond (ms) frame timer has expired.

As shown, the USB host controller walker registers340also comprise a current queue head (QH) pointer343and a current transfer descriptor pointer344. The current QH pointer343and the current TD pointer344inform BMC firmware where in the host memory (e.g., the system memory106) the USB host controller walker engine395was at when it had to stop and interrupt the BMC114. In at least some embodiments, the current QH pointer343and the current TD pointer344reflect where the walker was at when it entered the “execute TD” state on the state diagram200shown inFIG. 2.

The USB host controller walker registers340also comprise a token ignore register345. The token ignore register345instructs the USB host controller walker engine395to ignore (i.e., do not execute) a TD which has a particular token pattern in the token field. In this manner, the token ignore register345is able to reduce the number of interrupts for “bogus” TDs which sometimes occur due to software bugs. Reducing the number of interrupts for bogus TDs improves the efficiency of BMC114.

In some embodiments, the emulated USB host controller of the BMC114keeps a list of the bogus TDs. Thereafter, the host computer system can use the list of bogus TDs to correct bug conditions of a USB host controller. The bogus TDs are a set of transfer descriptors set up for a host operating system to avoid certain hardware defects of some UHCI controllers. While the BMC firmware can be configured to ignore the bogus TDs, some UHCI controllers use the “bogus TDs” to prevent entering into an adverse hardware state.

As previously mentioned the virtual (emulated) USB host controller registers330comprise the PCI INT vector register331, the IOP INT vector register332, and the IOP INT mask register333. In operation, the IOP INT vector register332contains a bit for each register contained in UHCI specification registers320. If a host computer system writes to any of the UHCI specification registers320, then a corresponding bit will be set in the IOP INT vector register332(indicated by the arrow353from block320to332). As long as the corresponding bit is not “masked” (nullified) in the IOP interrupt mask register333, setting the corresponding bit will generate an interrupt372to the BMC114. The BMC interrupt372allows software/firmware of the BMC114to be notified when the host computer system has interacted with the emulated USB host controller of the BMC114.

Firmware of the BMC114can read the IOP INT vector register332to determine which registers have been changed. Firmware of the BMC114can then read the related UHCI specification registers and take the appropriate action. For example, if the host operating system changes some of the bits in the USB Command register322(e.g., clearing the Run/Stop bit), the BMC firmware receives an interrupt and examines the contents of the USB Command register322to determine that the Run/Stop bit has been cleared. In response to this change, the BMC firmware stops the UHCI subsystem as would clearing the Run/Stop bit signal in a real USB host controller. As another example, when the host system updates the frame list base address register324, the BMC114receives an interrupt when this register is written. Thereafter, the BMC firmware reads the IOP interrupt vector register332to determine which register was updated and then reads the frame list base address register324to determine the new address. The walker engine395can then be stopped and restarted to begin walking the list at the new location (identified by the new address).

The PCI INT vector register331is used by firmware of the BMC114to interrupt the host computer system and to indicate status. For example, in some embodiments, setting a certain bit in the PCI INT register331will generate a host interrupt (e.g., the interrupt may be a PCIINT# host interrupt362or a SMI# host interrupt363) unless the bit is “masked” (nullified) via the USB host controller INT enable register325. If the host interrupt is generated, the PCI INT vector register331sets a corresponding status bit in the USB host controller status register321(indicated by the register set signal352). When processing the host interrupt, the host computer system reads the USB host controller status register321to determine the status and take the appropriate action. For example, once firmware of the BMC114has completed any processing needed to perform a TD that sets the Interrupt on Completion (IOC) bit, an appropriate bit in the PCI interrupt vector register331will also be set. Setting the appropriate bit in the PCI interrupt vector register331causes the USB interrupt bit (bit0) of the USB HC status register321to be set. Host software handles the interrupt by reading the USB HC status register321. For example, finding bit0set will indicate that the TD is complete and host software can free up the memory/resources associated with that TD and add or remove items from the list as necessary. After processing the host interrupt, the host computer system clears the status bit in the USB host controller status register321as well as a corresponding bit in the PCI INT register331(indicated by the register clear signal351).

FIG. 4shows a method400in accordance with embodiments of the invention. As shown inFIG. 4, the method400comprises emulating a USB host controller (e.g., the emulated USB host controller127) at block402. In at least some embodiments, emulating the USB host controller is based on the UHCI specification. In alternative embodiments, emulating the USB host controller is based on the OHCI or EHCI specifications. Also, emulating the USB host controller may be based on software/firmware/hardware of a BMC114that provides remote management capabilities to a host computer system (i.e., the host computer system is able to be remotely managed by a remote management console via the BMC114).

The method400further comprises selectively emulating at least one USB peripheral device (block404). For example, selectively emulating at least one USB peripheral device may involve emulating one or more of a mouse, a keyboard, a floppy disk drive, a CD-ROM drive, a Flash memory, and a printer based on input from a user. For example, the user may select which USB peripheral devices to emulate via a web page interface provided by the BMC114. If more than a threshold number of USB peripheral devices are selected to be emulated (determination block406), the method400comprises emulating a USB hub (block408). After emulating the USB hub (block408) or if more than a threshold number of USB peripheral devices are not selected to be emulated (determination block406), the method400comprises providing data from an external interface to a host computer system based on the emulated USB host controller and at least one emulated USB peripheral device (block410).

The method400enables a host computer system having a BMC114to recognize data from a remote management console based on existing USB drivers. By emulating a USB host controller, USB peripheral devices and, if necessary, USB hubs, the BMC allows different types of data from a remote management console to be recognized by the host computer system. For example, data from a mouse, a keyboard, a floppy drive, a CD-ROM drive a Flash memory device or a printer at the remote management console location could be recognized by the host computer system as if the mouse, the keyboard, the floppy drive, the CD-ROM drive, the Flash memory device or the printer at the remote management console location were USB peripheral devices coupled locally to the host computer system via a USB communication bus. Thus, embodiments of the invention enable improved remote administration of a computer system such as the computer101.

The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art. It is intended that the following claims be interpreted to embrace all such variations and modifications.