HK1183180A - Communicating message request transaction types between agents in a computer system using multiple message groups - Google Patents

Description

Communicating message request transaction types between agents in a computer system using multiple message groups

The present application is a divisional application of the chinese patent application having an application date of 12/5/2002, an application number of 02826165.8, entitled "communication message request transaction type between agents in a computer system using multiple message groups".

Technical Field

The present invention relates generally to the field of computer systems. More particularly, the present invention relates to the field of high speed point-to-point interconnects and communication architectures.

Background

Computing devices, such as computer systems, servers, network switches and routers, wireless communication devices, and other electronic devices, are generally comprised of many different elements. These elements typically include a processor, system control logic, a memory system, input and output interfaces, and the like. To facilitate communication between such elements, computing devices have long relied on general purpose input/output buses to enable these various elements of the computing system to communicate with each other to support the myriad of applications provided by such devices.

Perhaps the most common form of such a universal bus architecture is the Peripheral Component Interconnect (PCI) bus. The PCI bus standard (peripheral component interconnect (PCI) local bus specification, revision 2.2, published 12/18 of 1998) defines a multi-drop, parallel bus architecture for arbitrating the interconnection of chips, expansion boards, and processor/memory subsystems in a computing device. Typical PCI bus implementations have a throughput of 133Mbps (i.e., 33MHz 32 bits), while the PCI 2.2 standard allows for a 64 bit per pin parallel connection, clocked to 133MHz, resulting in a theoretical throughput of over 1 Gbps.

Until recently, the throughput provided by PCI bus architectures has provided sufficient bandwidth to accommodate the internal communication needs of even the most advanced computing devices (e.g., multiprocessor server applications, network devices, etc.). However, recent advances in processing power and increases in input/output bandwidth requirements have created a situation where: existing general purpose architectures such as the PCI bus architecture have become a bottleneck in such computing devices.

Another limitation associated with existing architectures is that they are generally not well suited for handling isochronous (time-dependent) data streams. An example of a synchronous data stream is a multimedia data stream that requires a transport mechanism to ensure that data is consumed as fast as data is received and that the audio portion is synchronized with the video portion. Conventional general purpose input/output architectures process data asynchronously or at random intervals as bandwidth allows. Such asynchronous processing of multimedia data may result in lost data and/or misplacement of audio and video.

Drawings

The inventions will be understood more fully from the detailed description given below and from the accompanying drawings of embodiments of the inventions which, however, should not be taken to limit the inventions to the embodiments described, but are for explanation and understanding only.

FIG. 1 is a block diagram of one embodiment of a computer system.

FIG. 2 is a diagrammatic representation of an exemplary enhanced general input/output port.

Figure 3 is a diagram illustrating the format of one embodiment of the beginning of a transaction layer packet header.

Fig. 4 is a diagram of a request packet header supporting a 32-bit address format.

Fig. 5 is a diagram of a request packet header supporting a 64-bit address format.

Fig. 6 is a diagram of a packet header of a message.

FIG. 7 is a diagram showing a request header format for a configuration transaction.

FIG. 8 is a diagram illustrating one embodiment of a format of a completion header.

Fig. 9a and 9b combine to form a flow chart of an exemplary embodiment of a method for processing a received transaction layer packet.

FIG. 10 is a flow diagram of one embodiment of a method for handling an error condition associated with a received request packet.

FIG. 11 is a flow diagram of one embodiment of a method for handling completion packets that are not expected by a system agent.

FIG. 12 is a flow diagram of one embodiment of a method for a requesting device to process a completion packet having a completion status other than "successful completion".

FIG. 13 is a flow diagram of one embodiment of a method for a completion device to process a completion packet having a completion status other than "successful completion".

Detailed Description

Embodiments of a packet-based point-to-point interconnect architecture, communication protocol, and related methods for providing a scalable and extensible general-purpose input/output communication platform for use in electronic devices are described below. The disclosed embodiments relate to an enhanced general input/output interconnect architecture and associated communication protocols. One exemplary embodiment includes one or more of a root complex (root complex), a switch, or an endpoint (endpoint), the root complex including a host bridge, each incorporating at least a subset of enhanced general input/output features to support enhanced general input/output communications between these elements.

In one embodiment, communication between the enhanced general input/output devices of these elements is performed using a serial communication channel that uses a communication protocol that supports one or more innovative features including, but not limited to, a virtual communication channel, tail-based error forwarding (error forwarding) (a "tail" is attached to a transaction layer packet to indicate an error condition), support for legacy (legacy) PCI-based devices, multiple request response types, flow control, and/or data integrity management functions. The communication protocol supported in this embodiment includes a communication protocol stack that includes a physical layer, a data link layer, and a transaction layer.

In another embodiment, the communication agent incorporates an enhanced general input/output engine that includes a subset of the features described above. Furthermore, one or more elements of the various embodiments may be implemented in hardware, software, a propagated signal, or a combination thereof.

FIG. 1 provides a block diagram of an electronic device 100, and for the present embodiment, the electronic device 100 is a computer system. The system 100 includes a processor 102, a host bridge 103 that is part of a root complex 104, a switch 108, and an endpoint 110, each coupled as shown. The root complex 104, the switch 108, and the endpoint 110 include one or more instances of the enhanced general input/output communication port 106. As shown, each of the elements 102, 104, 108, and 110 are coupled to at least one other element via an enhanced general input/output communication port through a communication link 112, where the communication link 112 supports one or more enhanced general input/output communication channels. System 100 is intended to represent any one or more of a variety of conventional and non-conventional computing systems, servers, network switches, network routers, wireless communication subscriber units, wireless communication telephony infrastructure elements, personal digital assistants, set-top boxes, or any electronic device that would benefit from communication resources introduced through integration of at least a subset of the enhanced general input/output interconnection architecture and/or communication protocols described herein.

In the exemplary embodiment, processor 102 controls one or more aspects of the functional capabilities of electronic device 100. In this regard, the processor 102 may represent any of a variety of control logic devices including, but not limited to, one or more of a microprocessor, a Programmable Logic Device (PLD), a Programmable Logic Array (PLA), an Application Specific Integrated Circuit (ASIC), a microcontroller, and the like.

The root complex 104 provides a communication interface between the processor 102 and the switch 108 and endpoint 110. As used herein, the term "root complex" refers to a logical entity of the enhanced general input/output hierarchy that is closest to the host controller, the memory controller hub, the IO controller hub, or any combination of the above or some combination of chipset/CPU elements (i.e., in a computing system environment). Although depicted as a single unit in FIG. 1, the root complex 104 may be implemented by multiple physical components. The root complex 104 is populated with one or more enhanced general input/output ports 106 to facilitate communications with other peripheral devices, such as the switch 108, the endpoint 110, and the legacy bridge 114 or 116, although the legacy bridge 114 or 116 is not specifically described. In one embodiment, each enhanced general input/output interface port represents a different hierarchy domain. In this regard, the embodiment of FIG. 1 shows a root complex 104 having three hierarchical domains.

Figure 2 is a diagrammatic representation of an exemplary enhanced general input/output port 106. As shown, in this embodiment, the enhanced general input/output port 106 implements a communication stack that includes a transaction layer 202, a data link layer 204, and a physical layer 206, the physical layer 206 including a logical sub-block 208 and a physical sub-block 210. Each element of the transaction layer will be discussed in detail below.

Transaction layer 202 provides an interface between the enhanced general input/output architecture and the device core. The primary responsibility of the transaction layer 202 is to assemble and disassemble packets for one or more logical devices in the agent.

One of the main goals of the enhanced general input/output architecture is to maximize the efficiency of inter-device communication. In one embodiment, the transaction layer implements a pipelined full split transaction protocol (pipelined full-transaction protocol) and a mechanism for differentiating ordering and processing requirements of transaction layer packets. The transaction layer also includes transaction layer packet construction and processing.

One embodiment of the enhanced general input/output architecture supports the following basic transaction types and address spaces: memory, I/O, configuration, and messages. Two addressing types are supported: 32 bits and 64 bits.

Transactions are carried using request and completion packets, which may be referred to simply as requests and completions. Completion is only used if needed, for example, to return read data or to notify the completion of I/O and configuration write transactions. Completions are associated with their corresponding requests by the value in the requestor ID (discussed below) of the packet header.

All transaction layer packets in this embodiment start with a defined header. Some transaction layer packets include data following a header, which is determined by a format field specified in the transaction layer packet header. The size of the transaction layer packet is limited by a predetermined maximum payload size value. The transaction layer packet data in this embodiment is four byte naturally aligned and increments in four byte double words.

Figure 3 is a diagram illustrating the format of one embodiment of the beginning of a transaction layer packet header. Each transaction layer packet header includes a three-bit format field (Format [2:0 ]). The transaction layer packet header also includes a four bit type field (type [3:0 ]). Both the format field and the type field need to be decoded to determine the transaction layer packet format. Table 1 below shows an exemplary encoding for the format field.

000	2 double-word header, no data
		001	3 double-word header, no data
002	4 double-word header, no data
		101	3 double-word headers with data
110	4 double-word headers with data

TABLE 1 Format field encoding

The transaction layer header of this embodiment also includes a 2-bit extension type/extension length field (Et/El). This field is used to extend either the type field or the length field, depending on the value in the type field. The length field of this embodiment is typically an eight bit field, but if the value of the type field indicates that the Et/El field is to be used to extend the length field, the length field may be extended to a ten bit field. Depending on the value in the type [3:0] field, the type field can be extended to a six-bit field by attaching an Et/El field. See format, type and Et/El field encodings for the example of fig. 2 below (other embodiments may use other encoding strategies). Unless otherwise indicated, the Et/El field is used as an extension of the type field.

TABLE 2 Format, type and Et/El encoding

The request packet includes a request header that will be followed by a certain amount of double-word data for certain types of request packets. The term "doubleword" is used herein to indicate data of 32 bit length. For this exemplary embodiment, the length field of the message request header is not used except for messages that explicitly reference a data length. And for this embodiment, the El/Et field is concatenated with the length field to form a ten-bit length field for memory read requests and memory write requests. The ten-bit length field allows read and write requests that indicate up to 4kB of data. Other types of transaction layer packets are limited by the size of the length 7:0 field to indicate up to 1kB of data. In one embodiment, the amount of data contained by any transaction layer packet is limited by a predetermined maximum payload size. For transaction layer packets that include data, the value in the length field should be equal to the actual amount of data. If the recipient determines that the length field value does not match the true amount of data, the packet is considered a malformed transaction layer packet. Malformed transaction layer packets are described below.

Fig. 4 is a diagram of a request packet header supporting a 32-bit address format, and fig. 5 is a diagram of a request packet header supporting a 64-bit address format. For one embodiment, the memory read request and memory write request cases use either a 32-bit address format or a 64-bit address format. For addresses below 4GB, a 32-bit format is used.

The request packet headers of FIGS. 4 and 5 also include a first double-word byte enable field (1 st DW BE) and a last double-word byte enable field (last DW BE). The first double word byte enable field includes byte enables for the first double word of any memory read or write request. This field also includes a double-word only byte enable for input/output or configuration requests. The last double word byte enable field includes the byte enable for the last double word of any memory read or write request. Byte enable fields are not used for messages because these fields cover the message encoding fields of the message request header (see fig. 7, discussed below).

For one embodiment, for each bit of the byte enable field, a value of "0" indicates that the corresponding byte of data is not written to, or read if non-prefetchable, at the completer. The term "completer" as used herein is meant to indicate a logical device addressed by a request packet header. A value of "1" indicates that at the completer, the corresponding byte of data is written or, if non-prefetchable, read. For the first doubleword byte enable field, bit 0 corresponds to byte 0 of the first doubleword of data. Bit 1 corresponds to byte 1 of the first double word of data. Bit 2 corresponds to byte 2 of the first double word of data. Bit 3 corresponds to byte 3 of the first double word of data. For the last doubleword byte enable field, bit 0 corresponds to byte 0 of the last doubleword of data. Bit 1 corresponds to byte 1 of the last double word of data. Bit 2 corresponds to byte 2 of the last double word of data. Bit 3 corresponds to byte 3 of the last double word of data.

The example packet headers of fig. 4, 5, 6 and 8 include a requestor ID field, a tag field, an attribute field, and a virtual channel ID field. The requestor ID field and the tag field together form a transaction ID field. The requester ID field is divided into a bus number field, a device number field, and a function number field.

The tag field is a 5-bit field generated by each requesting device. The tag value is unique to all outstanding requests that need to be completed for the requesting device. All requests and completions include a transaction ID field. For these exemplary embodiments, the requestor ID field is a 16-bit value that is unique for each function (a function is an independent segment of a multifunction device identified in configuration space by a unique function number). The function captures the bus number that is provided with all configuration writes completed by the function and supplies the number in the bus number field of the requestor ID field. Each logical device in an element is designed to respond to a unique device number for configuration requests addressed to that element. For these exemplary embodiments, an element may contain many (possibly up to several tens) of logical devices. Each function associated with a logical device in a component is designed to respond to a unique function number for configuration requests addressing the component and the logical device. Each logic device may contain up to eight logic functions.

The attribute field indicates the characteristics of the transaction. Attributes that may be specified in the attribute field include a priority attribute, a transaction ordering attribute, and a cache coherency management attribute.

The virtual channel ID field identifies the virtual channel. For these exemplary embodiments, the virtual channel ID field is a 4-bit field that allows identification of up to 16 virtual channels for each transaction. For these exemplary embodiments, virtual channel 0 is used for general traffic, while virtual channels other than 0 are used for isochronous traffic.

Fig. 6 is a diagram of a packet header of a message. As shown in table 2, the message may or may not include data and may or may not require completion. The message is decoded by all devices in a system that supports the enhanced general input/output interconnect architecture.

For a message request, the message field is decoded to determine the special cycle and to determine whether the message includes data and whether the message needs to be completed. The message field of this embodiment is an 8-bit field that is located where the byte enable field normally resides for other transaction types. The receiving device treats the unsupported message as an don't complete (the don't complete transaction is discussed below).

The messages of the exemplary embodiment are grouped into groups. There are eight groups that contain data accompanying the request and eight groups that do not. Other embodiments are possible utilizing a different number of groups. For this embodiment, as shown in table 2, the eight sets including data accompanying the request have a value of b110 in the format field. The eight groups that do not contain data have a value b010 in the format field. The subfield s [2:0] combines one bit from the type field and two bits from the Et/El field. The sub-field s [2:0] indicates one of eight groups.

Examples of various messages that may be implemented include, but are not limited to, the following: a message to unlock the device; a message to reset the device; a message indicating a correctable error condition; a message indicating an uncorrectable error condition; a message indicating a fatal error condition; a message for reporting a bad request packet; messages regarding power management; messages relating to sequencing control/management and messages used to emulate legacy (e.g., PCI) interrupt signals (or other legacy signals). These individual message types may be divided into one of the groups discussed above. For example, all power management messages may be included in one group, while interrupt signaling messages may be included in another. Embodiments are also possible in which: one or more groups remain for use by the vendor.

FIG. 7 is a diagram showing a request header format for a configuration transaction. The configuration space is one of the four supported address spaces of these exemplary embodiments.

FIG. 8 is a diagram illustrating one embodiment of a format of a completion header. All read requests and some write requests need to be completed. Completion includes a completion header followed, for some types of completion, by a certain amount of double-word data. The completion status [2:0] field shown in FIG. 8 indicates the status of completion. Table 3 shows an exemplary encoding strategy.

Completion State [2:0]	Status of state
		000	Is successfully completed
001	Request-expected completion not supported

011	Retention
		100	Completer suspension

TABLE 3 completion status field encoding policy

The completer ID [15:0] field contains the same type of information as the requester ID field described above. The value provided in the completer ID field corresponds to the bus/device/function of the agent that completed the request. The values of the requester ID, tag and channel ID contained in the completion header are the same as those supplied in the header of the request packet. The completion header also contains the same value in the attribute field as the header of the initial provisioning request. Completion packets are routed by the switches and root complex to the port that initiated the corresponding request transaction.

For a memory read request transaction, a single completion packet may provide less than the full amount of data requested by a corresponding read request, so long as all completion packets associated with the corresponding read request, in combination, return the indicated amount of data. For these exemplary embodiments, the I/O and configuration read requests are completed by only one completion packet.

The completion including the data indicates the amount of data in the packet header. If the completion packet actually contains a different amount of data than the indicated amount, a malformed transaction layer packet is generated.

Fig. 9a and 9b combine to form a flow chart of an exemplary embodiment of a method for processing a received transaction layer packet. The operations described below need not occur in a continuous manner. Some embodiments may perform certain operations simultaneously. At block 905, a check is made to determine if the values contained in the format and length fields of the received packet match the actual size of the packet. A mismatch indicates a malformed packet and an error condition results, as shown in block 925. Error case handling will be discussed below. If the true size of the received packet does not indicate a mismatch with the format and length fields, processing continues to block 910.

If the received packet is a memory request using 64-bit addressing, then at block 910, the address bits [63:32] are checked to see if any of the address bits [63:32] are non-zero. If none of the address bits [63:32] are non-zero, the result is a malformed packet and processing proceeds to an error case block 925. If at least one of the address bits [63:32] is non-zero, processing continues to block 915.

At block 915, a check is made to determine if any fields in the packet header contain reserved values. If a reserved value is found, the result is a malformed packet and processing proceeds to block 925. If no reserved value is found, processing proceeds to block 930.

At block 930, a determination is made as to whether the packet is a request packet or a completion packet. If the packet is a completion packet, processing proceeds to completion processing block 935. The completion process will be discussed more fully below. If the received packet is not a completion packet, processing continues to block 940. Note that all packets flowing to block 940 are request packets.

At block 940, a check is made to determine if the request packet is of a request type supported by the completing device. If the request type is not supported, the result is an unsupported request and processing proceeds to error case block 925. For this exemplary embodiment, if the unsupported request type is a broadcast message or a message using a code reserved for broadcast messages, the packet is silently discarded and no error condition is generated. If the completing device supports the request type, processing continues to block 945.

If, as indicated at block 945, the completing device is unable to respond to the request packet due to an internal error, the result is "completer abort," and processing proceeds to error case block 925. Otherwise, the request is serviced at block 950. In servicing the request, the processes of blocks 940 and 945 may need to be repeated.

Once the request is successfully serviced, processing continues to block 955. If the processed request requires completion, as indicated at block 955, a completion packet is returned at block 960.

FIG. 10 is a flow diagram of one embodiment of a method for handling an error condition associated with a received request packet. As seen at block 1010, if the received request expects completion, then a completion with an appropriate completion status is transmitted at block 1020. The completion is routed back to the requesting device. If the received request is not expected to complete, an error message is transmitted to the requesting device at block 1030. An error is reported to the system at block 1040. The error message transmission operation indicated at block 1030 may be implemented as a programmable option.

Some systems may include one or more PCI buses in addition to the enhanced general input/output interconnect structure discussed above. For memory, I/O, and configuration requests that pass through the enhanced general input/output interconnect fabric and are destined for devices on the PCI bus, the completion status of these embodiments represents the true PCI end of the cycle. For example, unpublished PCI cycles must actually be serviced on the PCI bus before the completion status can be determined. For all other cases, the completion status value is defined as follows.

When a request is successfully completed by the completing device, the resulting completion status value is "successful completion" (encoded as "000" in the completion status field, as shown in Table 3 for this embodiment). For example, read requests from the host bridge are routed through the switch to the completer endpoint. The completer responds with a completion packet indicating a successful completion status and also responds with the data of the read request. The switch routes the completion packet back to the host bridge.

When the completing device receives and decodes the request, but the completion packet does not support the requested transaction and the request requires completion, the resulting completion status is an "unsupported request" (encoded as "001" in the completion status field, as shown in table 3 for this embodiment). One example of an unsupported request is a memory read request for an out-of-range address. In this case, the completer cannot support the request, and the request expects a completion.

The resulting completion status is an unsupported request for the completion device to receive and decode the request and the completion device cannot support the requested transaction and the requesting device does not expect completion. Because the requesting device does not expect completion, the completion status is communicated to the requesting device via a message as described above in connection with FIG. 10. One example of an unsupported request that the requesting device does not expect to complete is a memory write transaction to an out-of-range address. Communication of completion status via a message may be implemented as an optional feature.

When a completing device receives and decodes a request, but the completing device cannot respond due to an internal error, the resulting completion status is "completer abort" (encoded as "100" in the completion status field for this embodiment).

When a completing device receives a packet that violates the packet format rules, the result is a "malformed packet". The completing device responds to this by transmitting a "malformed packet" error message, which is routed to the requesting device. For this embodiment, a switch receiving a malformed packet must route the packet to an upstream port if no other port can be definitively identified as the intended destination port.

When the read completion has a completion status other than "successful completion," no data is returned with the completion packet. The read completion with the unsuccessful completion status is the last completion transmitted for the request. For example, a completer may service a read request in four parts, and a second completion packet causes the completer to abort the completion status. The last two completion packets are not transmitted. Once the requesting device receives a completion packet with an unsuccessful completion status, the request is considered to be complete and no other completion packets corresponding to the read request should be expected.

FIG. 11 is a flow diagram of one embodiment of a method for handling completion packets that are not expected by a system agent. An "unexpected completion" occurs when an agent receives a completion that does not correspond to any outstanding request issued by the same agent. For the exemplary method of FIG. 11, block 1110 indicates that if there is no unexpected completion, normal operation continues at block 1120, but if an unexpected completion is received, the unexpected completion packet is dropped at block 1130. After the packet is dropped, the error condition may be reported to the system at block 1140. For this exemplary embodiment, the error report may be an option that is programmable by software.

FIG. 12 is a flow diagram of one embodiment of a method for a requesting device to process a completion packet having a completion status other than "successful completion". Block 1210 indicates that if the completion status is "successful completion," normal operations continue at block 1220. If the completion status is not "successful completion," the value of the completer ID field is recorded at block 1230. For this embodiment, the completer ID value is stored in a register. Next, at block 1240, a "receive unsuccessful completion" bit is set in a register in the requesting device of this embodiment. The error condition described above may be reported at block 1250. The error condition reporting may be implemented as a programmable option. The software agent may use the completer ID value and the "receive unsuccessful completion" bit to track the source of the error condition.

FIG. 13 is a flow diagram of one embodiment of a method for a completion device to process a completion packet having a completion status other than "successful completion". Block 1310 indicates that if the completion status of the transmitted completion packet is "successfully completed," normal operation continues at block 1320. If the completion status is not "successful completion," the values of the requestor ID and tag fields are recorded at block 1330. For this embodiment, the requestor ID and tag value are stored in one or more registers. Next, at block 1340, a "transfer unsuccessful completion" bit is set in a register in the completion facility of this embodiment. The error condition may be reported at block 1350. The error condition reporting may be implemented as a programmable option. The software agent may use the requester ID and tag values and the "transfer unsuccessful completion" bit to track the source of the error condition.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Reference in the specification to "an embodiment," "one embodiment," "some embodiments," or "other embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the inventions. The various appearances "an embodiment," "one embodiment," or "some embodiments" are not necessarily referring to the same embodiments.

Claims (10)

1. An apparatus for communicating messages, comprising:

a processor;

a root complex coupled to the processor for providing a communication interface and including a general purpose input/output communication port, the general purpose input/output communication port including:

means for implementing a communication stack including a physical layer, a data link layer, and a transaction layer in the general purpose input/output communication port, an

Means for assembling, via the transaction layer, a packet header for a message request transaction to send the message request transaction to one or more logical devices, wherein the packet header comprises:

a format field indicating a length of the packet header and further specifying whether the packet includes a data payload;

a subset of a type field indicating that the packet relates to the message request transaction; and

a message field comprising a message for implementing the message request transaction, the message comprising at least one message selected from the group of: a message to unlock the logical device, a message to reset the logical device, a message to indicate a correctable error condition, a message to indicate an uncorrectable error condition, a message to indicate a fatal error condition, a message to report a bad request packet, a message to indicate power management, and a message to emulate an interrupt signal.

2. The apparatus of claim 1, wherein the message to implement the message request transaction comprises the message to emulate an interrupt signal, the interrupt signal comprising a legacy Peripheral Component Interconnect (PCI) signal.

3. The apparatus of claim 1, wherein the message further comprises an indication of whether an implemented message request transaction requires completion.

4. The apparatus of claim 3, wherein the implementation that does not support the message included in the message field is an indication to a logical device that the completion is not required.

5. The apparatus of claim 1, the packet header further comprising:

a requester identification field including information for identifying a requester of the message request transaction; and

a tag field comprising information for identifying a completion related to the message request, wherein the requestor identification field and the tag field together form a transaction identification field.

6. An apparatus for communicating messages, comprising:

a processor;

a root complex coupled to the processor for providing a communication interface and including a general purpose input/output communication port, the general purpose input/output communication port including:

means for implementing a communication stack comprising a physical layer, a data link layer, and a transaction layer in the general purpose input/output communication port in the root complex,

means for assembling, via the transaction layer, a packet header for a message request transaction to send the message request transaction to one or more logical devices, wherein the packet header comprises:

a format field indicating a length of the packet header and further specifying whether the packet includes a data payload;

a subset of a type field indicating that the packet relates to the message request transaction;

a message field comprising a message implementing the one or more message type request transactions, the message comprising at least one message selected from the group of: a message to unlock the logical device, a message to reset the logical device, a message to indicate a correctable error condition, a message to indicate an uncorrectable error condition, a message to indicate a fatal error condition, a message to report a bad request packet, a message to indicate power management, and a message to simulate an interrupt signal; and

means for receiving the packet header in a switch comprising the logical device and a second general purpose input/output communication port, and implementing the communication stack in the switch comprising the data link layer, the physical layer, and the transaction layer, wherein the packet header relates to the message request transaction for the logical device, the transaction layer comprising disassembling the packet header relating to the message request transaction for the logical device to implement the message included in the message field.

7. The system of claim 6, wherein the message to implement the message request transaction comprises the message to emulate an interrupt signal, the interrupt signal comprising a legacy Peripheral Component Interconnect (PCI) signal.

8. The system of claim 6, wherein the message further comprises an indication of whether an implemented message request transaction requires completion.

9. The system of claim 8, wherein the implementation that the logical device does not support the message included in the message field is an indication to the logical device that the completion is not required.

10. The system of claim 6, the packet header further comprising:

a requester identification field including information for identifying a requester of the message request transaction; and

a tag field comprising information for identifying a completion related to the message request, wherein the requestor identification field and the tag field together form a transaction identification field.