Message TLPs

📋 Why Message TLPs Exist

PCI used physical sideband wires for interrupts (INTA#–INTD#), power management events (PME#), system error (SERR#), parity error (PERR#), and slot signals. These wires had to be routed across every board, every connector, and every bridge — a wiring nightmare that grew worse with every additional slot.

PCIe eliminated those sideband wires entirely. Every signal that PCI carried on a dedicated pin is now carried as an in-band Message TLP. This means the PCIe fabric itself delivers interrupts, error reports, power events, and hot-plug notifications — using the same differential pair infrastructure that carries data.

📋 Msg vs MsgD — Two TLP Types

There are two Message TLP types. Both share the same 4DW header. The only difference is whether a data payload follows.

Type bits [4:3] are always 10 for all messages. Type bits [2:0] — the routing sub-field — vary by message group and determine how every switch in the fabric routes this TLP. The Message Code in DW1 byte 7 identifies the specific message type within the group.

📋 Message Header — All 16 Bytes

Messages always use the 4DW (16-byte) header. The extra DW compared to memory TLPs is needed because bytes 8–15 carry message-specific data (target address for address routing, target BDF for ID routing, or message-specific payload fields).

📋 Routing Sub-field — Six Codes

The 3-bit routing sub-field in Type bits [2:0] determines how every switch handles this Message TLP. Unlike address routing (used by memory TLPs) or ID routing (used by completions), Message routing can be implicit — requiring no address or BDF lookup at all.

📋 Message Code Field (DW1 Byte 7)

The Message Code is an 8-bit field in DW1 byte 7. Combined with the routing sub-field, it uniquely identifies every defined Message type. The top 4 bits group messages by category; the lower 4 bits identify the specific message within that group.

📋 INTx — Interrupt Signalling

INTx messages replace the four physical interrupt pins (INTA#–INTD#) of PCI. They emulate the level-sensitive behaviour of those pins: Assert to signal interrupt pending, Deassert to signal interrupt serviced.

INTx rules from the spec (Table 5-9)

• INTx messages use TC=0 only. Receivers must check and handle violations as Malformed TLPs.
• INTx messages have no data payload — Length field is reserved.
• Only issued by Upstream Ports (endpoint sending toward RC direction).
• If INTx signalling is disabled (Interrupt Disable bit in Command register = 1), the device must send Deassert messages for any INTx that was active before the bit was set.
• Switches track each interrupt pin state independently per downstream port and combine them for the upstream port.
• The RC tracks all four virtual wires independently and converts them into system interrupts.

📋 Power Management Messages

Power management messages coordinate link power state transitions between devices and the Root Complex. They replace the physical PME# pin of PCI.

📋 Error Signalling Messages

Error messages are how PCIe devices tell the Root Complex about protocol errors. They travel upstream using routing code 000 (to Root Complex) and identify the reporting device in the Requester ID field.

• All three error messages use TC=0, carry no data payload, and are only sent when the device’s AER (Advanced Error Reporting) capability has the appropriate reporting enable bits set.
• The RC converts Error Messages into system-specific events — typically PCIe AER kernel notifications (Linux: `pcie_aer` driver), Windows Driver Framework error events, or BIOS/firmware callbacks.
• Error messages do not carry detail about the error — they are notification signals. The AER Extended Capability registers in the reporting device carry the detailed error information that software reads via configuration TLPs after receiving the message.

📋 Unlock Message

The Unlock Message is the termination signal for a locked transaction sequence (MRdLk). When a device sends MRdLk, every switch along the path locks VC0 to prevent other requesters from using it. The Unlock Message releases those locks across the entire path.

📋 Set Slot Power Limit

This MsgD (message with data) informs a card in a slot of its physical power budget. The device stores this limit in its Device Capabilities Register and must not draw more power than specified without explicit software permission.

📋 Vendor-Defined Messages

Vendor-Defined Messages (VDM) allow companies to define proprietary message types for features not covered by the PCIe spec. The header includes a Vendor ID field in DW2 bytes 10–11 that disambiguates messages from different vendors sharing the same code range.

📋 Latency Tolerance Reporting (LTR)

LTR Messages allow an endpoint to inform the platform of its acceptable service latency — how long it can tolerate waiting before the platform must respond to a read or write. The platform uses this information to optimise power management decisions: if all devices can tolerate long latencies, the platform can enter deeper sleep states between transactions.

The LTR header differs slightly from the standard message layout: DW2 carries the Snoop Latency field and DW3 carries the No-Snoop Latency field, each encoding a latency value with a scale factor (1 ns, 32 ns, 1024 ns, or 32768 ns).

📋 OBFF — Optimized Buffer Flush and Fill

OBFF Messages allow the platform to communicate its current power state and activity hint to endpoints. Endpoints use this hint to optimise their DMA behaviour — for example, flushing their transmit buffers when the platform signals it is about to enter a low-power state, rather than waiting until a full DMA burst is assembled.

⚡ Message TLPs in Gen 6

The Message TLP format — header layout, routing codes, message codes, and all rules — is completely unchanged in Gen 6. Message TLPs are packed into Gen 6 flits the same way any other TLP is. From the Transaction Layer’s perspective, nothing has changed.

Gen 6 specific message considerations

• FRS (Function-Level Reset Surprise) Message. PCIe 6.0 introduced FRS messages to support hot-plug and function reset scenarios in multi-function devices more cleanly. These are new message codes within the existing 4DW header format — the header structure is unchanged.
• ERR_FATAL in Gen 6 context. Gen 6’s FEC (Forward Error Correction) corrects many errors that would previously have generated ERR_COR messages. After FEC, the corrected bitstream reaches the Data Link Layer without errors. Only errors that FEC cannot correct — beyond the RS code correction capability — escalate through the ACK/NAK replay mechanism and may ultimately generate ERR_* messages.
• LTR relevance in Gen 6. At Gen 6 speeds, the latency tolerances that matter to the power management system become tighter. LTR messages from Gen 6 devices may carry shorter latency values than Gen 5 devices, reflecting the expectation of lower-latency fabric response. The message format is unchanged.
• VDMs in CXL 3.0. CXL 3.0 (which runs on the PCIe 6.0 PHY) makes extensive use of Vendor-Defined Messages for CXL-specific coherency and fabric management. The VDM header format is unchanged from what is described in this post — CXL simply defines new Vendor ID values and message content.

📋 Quick Reference