PCIe Series — PCIe-22: Extended Configuration Space — VLSI Trainers
PCIe Series · PCIe-22

Extended Configuration Space

Why configuration space had to grow beyond 256 bytes, how ECAM maps the full 4 KB per function into memory, the 32-bit extended capability header format, and every significant extended capability structure — AER, Virtual Channel, PASID, LTR, L1 Sub-States, and more.

📋 Why 256 Bytes Wasn’t Enough

The original PCI configuration space was 256 bytes per function. The first 64 bytes are the standard header. The remaining 192 bytes hold PCI capability structures — PM, MSI, the PCIe Capability. By the time PCIe added mandatory capabilities (PM, MSI, MSI-X, PCIe Capability, each 8–24 bytes) and then AER, VC, ATS, PASID, and dozens of other optional structures, 192 bytes became a tight constraint.

Two problems drove the expansion. First, there was simply no room for new capability structures as PCIe evolved through generations. Second, the legacy PCI IO-indirect access mechanism (writing to CF8h then reading/writing CFCh) was not multi-thread safe — two CPU threads accessing configuration space simultaneously could corrupt each other’s accesses.

PCIe solves both problems by extending configuration space to 4 KB per function and providing a new memory-mapped access mechanism called ECAM. The first 256 bytes remain backward compatible with legacy PCI software. The remaining 3840 bytes (offsets 100h–FFFh) form the Extended Configuration Space — a new region accessible only via ECAM.

📋 ECAM — Enhanced Configuration Access Mechanism

ECAM (Enhanced Configuration Access Mechanism) maps the entire 4 KB configuration space of every function as a flat memory-mapped region. A single 32-bit or 64-bit memory read or write to the correct address generates exactly one configuration read or write — atomically, without the two-step CF8/CFC dance.

ECAM requires a 256 MB base address region in physical memory space. This region is partitioned per bus/device/function. The base address of the ECAM region is advertised to the OS through the ACPI MCFG table (Memory Mapped Configuration table). Software maps this region and then accesses any function’s configuration space via ordinary memory operations.

ECAM vs Legacy CF8/CFC — Two Access Mechanisms Legacy CF8/CFC IO-indirect Step 1: Write target Bus/Dev/Fn/Reg to IO port 0CF8h Step 2: Read or write IO port 0CFCh for the data Two IO accesses per config access — not atomic Thread B can corrupt Thread A between steps 1 and 2 Only reaches offset 00h–FFh (6-bit register field = 64 DWs) Cannot access Extended Config Space (offset 100h–FFFh) ECAM — Memory-Mapped (MMCFG) Single memory read/write to calculated flat address Atomic — one instruction = one config access Multi-thread safe — no CF8 register to share Reaches full 4 KB per function (offsets 000h–FFFh) Base address in ACPI MCFG table Only ECAM can access Extended Config Space
Figure 1 — CF8/CFC vs ECAM. The legacy mechanism requires two IO accesses and can only address the first 256 bytes. ECAM is a single atomic memory access that reaches the full 4 KB. Offsets 100h–FFFh (Extended Configuration Space) are inaccessible via CF8/CFC — ECAM is the only way to read AER, VC, PASID, LTR, and other extended capability structures.

📋 ECAM Address Calculation

Every ECAM access targets exactly one function at exactly one register offset. The address is constructed from four components:

ECAM Physical Address = ECAM_BASE + Bus×1MB + Dev×32KB + Fn×4KB + Offset ECAM_BASE 256MB-aligned addr bits [63:28] Bus × 1 MB 0–255 buses bits [27:20] Dev × 32 KB 0–31 devices bits [19:15] Fn × 4 KB 0–7 functions bits [14:12] Offset 000h–FFFh bits [11:0] Total ECAM region: 256 buses × 32 devices × 8 functions × 4 KB = 256 MB. All config reads/writes are 32-bit aligned DWORD accesses.
Figure 2 — ECAM address formula. ECAM_BASE is advertised in the ACPI MCFG table. Bus number maps to bits [27:20], device to [19:15], function to [14:12], and the 12-bit register offset to [11:0]. The full 4 KB per function (offsets 000h–FFFh) is directly addressable.

Example: access offset 108h (AER Uncorrectable Error Status) in Bus 2, Device 0, Function 0 with ECAM_BASE = 0xE0000000:

Address = 0xE0000000 + (2 × 0x100000) + (0 × 0x8000) + (0 × 0x1000) + 0x108 = 0xE0200108

A 32-bit read to 0xE0200108 returns the AER Uncorrectable Error Status register directly — no two-step IO dance needed.

CF8/CFC cannot reach extended config space. The legacy Configuration Address Port uses a 6-bit register field (bits [7:2]) — addressing only 64 DWs = 256 bytes per function. Offsets 100h–FFFh are simply unreachable via CF8/CFC. If your software needs to read an AER, PASID, LTR, or VC capability structure, ECAM (via /dev/mem, /sys/bus/pci, or OS config space API) is the only path.

📋 Extended Capability Header Format

Extended capabilities use a different header format from the PCI capabilities in the 00h–FFh region. Instead of a 2-byte header (ID + Next Pointer), each extended capability starts with a 32-bit header that packs three fields together:

Extended Capability Header — 32 bits at the Start of Every Extended Capability Next Capability Offset [31:20] DWORD-aligned offset of next ext. capability (000h = end of list) 12 bits → can point anywhere in 0000h–FFFCh Cap Version [19:16] Version of this structure 4 bits — 1h most common Extended Capability ID [15:0] 16-bit ID identifies this structure type 65535 possible IDs vs 255 for PCI capabilities PCI capability header: 8-bit ID + 8-bit Next = 16 bits total. Extended capability header: 16-bit ID + 4-bit Version + 12-bit Next = 32 bits total.
Figure 3 — Extended capability header format. The 32-bit DW0 of every extended capability in the 100h–FFFh region. Three fields: 16-bit Capability ID (the type), 4-bit version, and 12-bit Next Capability Offset. The offset points to the DW0 of the next structure (DWORD-aligned, 000h = end). Software masks and reads each field from this single DW.

The 12-bit Next Capability Offset allows pointing anywhere in the 4 KB space (offsets 000h–FFFh, DWORD-aligned). The first extended capability always starts at offset 100h. If Next Offset = 000h, the list ends. Note that 000h is used as the end-of-list sentinel precisely because offset 000h is the Vendor ID register in the PCI-compatible header — no extended capability can ever be at offset 0, so 000h is unambiguous as “no next entry.”

▶ Walking the Extended Capability List

Software walks the extended capability list starting at offset 100h:

  1. Read the 32-bit DW at offset 100h via ECAM.
  2. Extract bits [15:0] — Extended Capability ID. If all bits are 0, there are no extended capabilities.
  3. Extract bits [19:16] — Capability Version.
  4. Process the capability at the current offset based on the ID.
  5. Extract bits [31:20] — Next Capability Offset. If 000h, stop. Otherwise jump to that offset and go to step 2.
ECAM is required to walk extended capabilities. Since CF8/CFC cannot reach offset 100h, all extended capability discovery must use ECAM. On Linux, this is what /sys/bus/pci/devices/<BDF>/config provides. On Windows, the PCIe Bus Driver uses MCFG-mapped ECAM. Hardware debuggers and BIOS use the raw ECAM memory region.

📋 AER — Advanced Error Reporting (Cap ID 0001h)

AER is the most important extended capability structure. It provides detailed, standardised error logging and reporting beyond what the basic PCI Status register offers. While the PCI Status register can only tell you “a fatal error occurred,” AER tells you exactly which error type, which TLP caused it (via the Header Log), which packet prefix caused it (TLP Prefix Log), and whether the error was the first in a sequence. AER is implemented by all PCIe-native endpoints and bridges.

AER Capability Structure — Registers Overview Extended Cap Header (ID=0001h · Ver=2h · Next Offset) — offset 100h Uncorrectable Error Status [31:0] — RW1C sticky flags for each error type — offset 104h Uncorrectable Error Mask [31:0] — 1=masked (no ERR_FATAL/NONFATAL) — offset 108h Uncorrectable Error Severity [31:0] — 1=Fatal 0=Non-Fatal per error type — offset 10Ch Correctable Error Status [31:0] — RW1C sticky flags — offset 110h Correctable Error Mask [31:0] — 1=masked (no ERR_COR sent) — offset 114h
Figure 4 — AER Capability structure first six DWs. Uncorrectable errors are categorised as Fatal or Non-Fatal by the Severity register. Correctable errors (receiver errors, bad DLLP, replay timeout) do not require SERR and are tracked separately. Status registers are RW1C — write 1 to clear the sticky bit. Mask registers prevent the corresponding error message from being sent to the Root Complex.
AER Continued — Advanced Control and Header Log Advanced Error Capability and Control (AECR) [31:0] — ECRC enable/check, First Error Pointer — offset 118h Header Log DW0 [31:0] — First DW of TLP header that caused the first uncorrectable error — offset 11Ch Header Log DW1 · DW2 · DW3 — offsets 120h · 124h · 128h Root Error Command (12Ch) · Root Error Status (130h) · Error Source ID (134h) Root Complex only — AER interrupt enable, which error types received, BDF of error source device
Figure 5 — AER Capability continued. The AECR enables ECRC generation and checking and exposes the First Error Pointer (bits [4:0]) — the bit position of the first uncorrectable error that fired, identifying which error type occurred first when multiple errors were logged simultaneously. The 128-bit Header Log captures all four DWs of the guilty TLP’s header. Root Error registers are only present in Root Complex ports, not in endpoints or switch ports.

📋 AER Register Details

Uncorrectable Error Status / Mask / Severity — key bit positions

BitError typeDefault SeverityDescription
4Data Link Protocol ErrorFatalReceived DLLP with bad CRC or out of sequence. Fatal — link is unreliable.
5Surprise Down ErrorFatalLink went down unexpectedly (DL_Down without EIOS). Fatal — link lost.
12Poisoned TLP ReceivedNon-FatalReceived a TLP with EP (Error Poison) bit set.
13Flow Control Protocol ErrorFatalFlow control credits exceeded or invalid FC DLLP received.
14Completion TimeoutNon-FatalSent a non-posted request but the completion never arrived within timeout period.
15Completer AbortNon-FatalReceived a completion with Completer Abort status (CA).
16Unexpected CompletionNon-FatalReceived a completion that doesn’t match any outstanding request tag.
17Receiver OverflowFatalReceived TLP that overflowed the receive buffer (flow control violated).
18Malformed TLPFatalReceived a TLP that violated formatting rules (bad length, mismatched fields, etc.).
19ECRC ErrorNon-FatalECRC check failed — data was corrupted in flight. (Only if ECRC enabled.)
20Unsupported Request ErrorNon-FatalReceived a request that the device does not support (UR status returned).
21ACS ViolationNon-FatalTLP violated ACS (Access Control Services) policy at a switch port.

Correctable Error Status / Mask — key bit positions

BitError typeDescription
0Receiver Error8b/10b code violation, disparity error, or 128b/130b sync header error at the physical layer.
6Bad TLPTLP received with LCRC error or sequence number error — replayed automatically by DLL.
7Bad DLLPDLLP received with CRC error.
8Replay Number RolloverREPLAY_NUM counter reached 4 — link integrity suspect (four consecutive failed replays).
12Replay Timer TimeoutACK not received before REPLAY_TIMER expired — ACK latency too high for this configuration.
13Advisory Non-Fatal ErrorAn uncorrectable error was downgraded to Non-Fatal advisory (e.g. UR with advisory bit).

Advanced Error Capability and Control Register (AECR) — offset 118h

BitsFieldDescription
[4:0]First Error PointerRead-only. Bit position of the first uncorrectable error that set a bit in Uncorrectable Error Status. Identifies which error was logged first in the Header Log when multiple errors hit simultaneously.
5ECRC Generation CapableRead-only. Device supports generating ECRC (End-to-End CRC) on outgoing TLPs.
6ECRC Generation EnableRead/Write. When 1, device adds ECRC to all outgoing TLPs (sets TD bit in header).
7ECRC Check CapableRead-only. Device can verify ECRC on incoming TLPs.
8ECRC Check EnableRead/Write. When 1, device checks ECRC on incoming TLPs and reports failures.

📋 Virtual Channel (VC) Capability (Cap ID 0002h)

The Virtual Channel capability structure configures which Traffic Classes (TC0–TC7) map to which Virtual Channels (VC0–VC7) and controls VC arbitration. VC0 is always present and always assigned to TC0. Additional VCs (VC1–VC7) are optional and allow QoS-critical traffic to travel through dedicated buffers that cannot be blocked by lower-priority traffic.

Register groupOffset from cap startKey fields
VC Capability Register 1+04hExtended VC Count (how many VCs beyond VC0), Low Priority Extended VC Count, Reference Clock, Port Arbitration Table Entry Size
VC Capability Register 2+08hVC Arbitration Capability — bitmask of supported arbitration schemes (Round Robin, WRR, Time-Based WRR, etc.)
VC Control and Status+0ChVC Arbitration Select — chooses current arbitration scheme. VC Load VC Arbitration Table — triggers loading of the arbitration table.
VC0 Resource Capability+10hPort Arbitration Capability (which arbitration types VC0 supports), Maximum Time Slots
VC0 Resource Control+14hTC/VC Map [7:0] — bitmask of TCs mapped to VC0. Enable VC0 bit. Port Arbitration Select for VC0.
VC0 Resource Status+18hNegotiation Pending — when 1, VC0 TC mapping is being re-negotiated. Port Arbitration Table Status.
VCn registers (for n=1–7)repeatingSame structure as VC0 for each additional VC implemented. TC/VC Map controls which TCs flow through this VC.
VC0 and TC0 are always linked. TC0 must always be assigned to VC0. No other TC mapping is required — the simplest possible VC configuration is TC0→VC0 for everything, which is what most systems use. Advanced systems with real-time audio, video, or storage latency requirements map high-TC traffic to separate VCs with dedicated bandwidth allocations and arbitration priority.

📋 Device Serial Number (DSN) (Cap ID 0003h)

The Device Serial Number capability provides a globally unique 64-bit serial number for the device. The serial number is split across two DWs: DW1 holds the lower 32 bits and DW2 holds the upper 32 bits. The format is defined such that the upper 24 bits come from a registered IEEE OUI (Organizationally Unique Identifier) ensuring global uniqueness.

DSN is used by virtualisation hypervisors to uniquely identify SR-IOV physical functions across reboots, by hot-plug systems to distinguish replacing a card with the same PCI Device ID, and by Thunderbolt-over-USB4 to verify trusted device chains. In PCIe 4.0 and later, the DSN also forms part of the SPDM (Security Protocol and Data Model) device authentication chain.

DWOffset from cap startContent
DW0+00hExtended Capability Header (ID=0003h)
DW1+04hSerial Number [31:0] — lower 32 bits of 64-bit unique number
DW2+08hSerial Number [63:32] — upper 32 bits, includes IEEE OUI in bits [63:40]

📋 ATS — Address Translation Services (Cap ID 000Fh)

ATS enables a PCIe device to cache address translations from an IOMMU. Instead of every DMA requiring an IOMMU lookup, the device requests a translation (getting a Translated address back), caches it locally, and then marks subsequent DMA TLPs with AT=10b (Translated) — bypassing the IOMMU lookup and reducing latency. This is essential for SR-IOV and virtual machine DMA performance.

RegisterOffsetKey bits
ATS Capability+04hInvalidate Queue Depth [4:0] — max outstanding invalidate requests device can queue. Page Aligned Request bit — device only sends aligned Translation Requests.
ATS Control+06hEnable [15] — when 1, device may issue Translation Requests and use AT=10b in DMA TLPs. STU [4:0] — Smallest Translation Unit (smallest region device will request a translation for).

ATS works in conjunction with the AT field in TLP headers (PCIe-11). Without ATS, devices use AT=00b (Untranslated — every DMA goes through IOMMU). With ATS enabled and a cached translation, DMA TLPs carry AT=10b and bypass the IOMMU table walk. The IOMMU can invalidate cached translations via an Invalidation Request TLP when mappings change.

📋 PASID — Process Address Space ID (Cap ID 001Bh)

PASID allows a PCIe device to tag its DMA transactions with a Process Address Space Identifier — effectively telling the IOMMU “this DMA should be translated using process P’s address space, not just the VM’s address space.” This enables per-process IOMMU isolation, critical for shared GPU compute (CUDA/OpenCL) and SR-IOV environments where multiple processes share one physical device.

Without PASID, all DMA from a device is translated using a single address space (the VM or driver context). With PASID, each DMA TLP carries a 20-bit PASID value that the IOMMU uses to select the correct page table — allowing true per-process memory isolation even when multiple processes share the same physical function.

RegisterOffsetKey bits
PASID Capability+04hExecute Permission Supported [1] — device can tag requests with execute permission intent. Privileged Mode Supported [2] — device can indicate privileged-mode DMA. Max PASID Width [12:8] — highest PASID bit the device supports (0–19, so 1–20 bits total).
PASID Control+06hPASID Enable [0] — when 1, device may include PASID TLP Prefix in its DMA TLPs. Execute Permission Enable [1] · Privileged Mode Enable [2].
PASID in Gen 6 context. Gen 6 AI accelerators running thousands of simultaneous compute kernels per device make PASID essential. Each kernel’s DMA needs its own IOMMU address space for memory isolation and protection. PASID + ATS together allow kernels to share physical NVLink/PCIe bandwidth while maintaining strict per-process memory isolation — a requirement for multi-tenant cloud AI infrastructure.

📋 LTR — Latency Tolerance Reporting (Cap ID 0018h)

LTR allows a device to report how much service latency it can tolerate before performance degrades or data is lost. The Root Complex uses this information to make intelligent decisions about when to service requests — for example, keeping memory in self-refresh longer if all attached devices advertise high latency tolerance, saving significant platform power.

LTR Message Format — Two Latency Values in One Message Snoop Latency [15:0] Bits [9:0] — Latency Value (0–1023) Bits [12:10] — Scale: 000=×1ns · 001=×32ns · 010=×1µs · 011=×32µs · 100=×1ms · 101=×32ms Bit 15 — Requirement: 1=this latency is required Reports latency tolerance for snooped DMA requests No-Snoop Latency [31:16] Bits [25:16] — Latency Value (0–1023) Bits [28:26] — Scale: same encoding as Snoop Latency Bit 31 — Requirement: 1=this latency is required Reports latency tolerance for non-snooped DMA requests
Figure 6 — LTR Message payload. The 32-bit message carries two independent latency values — one for snoop-required accesses and one for no-snoop accesses. Each has a 10-bit value, a 3-bit scale (1ns to 32ms), and a 1-bit Requirement flag. Setting value=0 means “any delay hurts me — serve me immediately.” The Requirement bit = 0 means “I have no service requirement right now.”

LTR is sent as a Message TLP (Point-to-Point, routed to Root Complex). Switches aggregate LTR messages from all downstream ports, reporting the minimum (most demanding) latency upstream. The Root Complex is not required to honour LTR requests, but is strongly encouraged to. Devices should send an updated LTR message whenever their service requirements change and must send one with Requirement=0 before entering a low-power state.

LTR Capability and Control registers

RegisterOffsetKey bits
LTR Capability+04hNo control fields — capability just signals support. Enabled via LTR Mechanism Enable in PCIe Capability Device Control 2 register.
Max Snoop Latency+04h (some variants)Maximum Snoop Latency Value [9:0] · Scale [12:10] — maximum LTR value a Root Port will accept upstream before treating the message as advisory only.
Max No-Snoop Latency+06hSame encoding as Max Snoop Latency for no-snoop path.

📋 L1 PM Sub-States (Cap ID 001Eh)

The L1 PM Sub-States capability adds additional power levels within the L1 ASPM link state. Standard L1 requires both the upstream and downstream component to be in L1 simultaneously. L1 PM Sub-States introduce four refined sub-states that allow even more aggressive power savings while keeping the entry/exit latency predictable.

L1 PM Sub-States — Four Levels of Deeper L1 Sleep Standard L1 Both sides idle Clock may stay on Exit: Recovery ~2–100 µs ASPM L1 only L1.1 (ASPM) Tx removed from common mode Ref clock removed More savings than L1 ASPM-controlled L1.2 (ASPM) L1.1 + PLL off Deeper clock gating possible Longest exit latency ASPM-controlled L1.1 (PM) Software-initiated via D-state change Same electrical as ASPM L1.1 SW-controlled L1.2 (PM) Software-initiated via D3hot entry Same electrical as ASPM L1.2 SW-controlled
Figure 7 — L1 PM Sub-States. Standard L1 keeps the transmitter common mode voltage but may keep PLLs running. L1.1 removes common mode (further reducing power). L1.2 additionally turns off PLLs for maximum savings but the longest exit latency. ASPM variants are hardware-controlled. PM variants are software-controlled via device power state changes.
RegisterOffsetKey bits
L1SS Capabilities+04hL1.1 ASPM Supported [0] · L1.2 ASPM Supported [1] · L1.1 PM Supported [2] · L1.2 PM Supported [3]. LTR_L1.2_THRESHOLD [31:16] — minimum LTR value required to allow L1.2 entry.
L1SS Control 1+08hL1.1 ASPM Enable [0] · L1.2 ASPM Enable [1] · L1.1 PM Enable [2] · L1.2 PM Enable [3]. Common_Mode_Restore_Time [15:8] — time needed to restore common mode on exit. LTR_L1.2_THRESHOLD [31:16] — programmed threshold for L1.2 eligibility.
L1SS Control 2+0ChT_POWER_ON [4:0] — time needed to power on the PLL after L1.2 exit. T_POWER_ON Scale [6:5] — units for T_POWER_ON (2µs, 10µs, 100µs).

📋 ACS — Access Control Services (Cap ID 000Dh)

ACS prevents a PCIe device from bypassing the IOMMU by sending DMA directly to another PCIe device (peer-to-peer DMA). Without ACS, a compromised SR-IOV Virtual Function could DMA directly to another VF’s memory — bypassing all OS memory protection. ACS enforces that all DMA passes through the Root Complex and IOMMU, even when the source and destination are on the same switch.

ACS feature bitWhen enabled
ACS Source Validation (SV)Switch verifies that the Requester ID in incoming upstream TLPs matches a valid downstream port. Prevents spoofed requester IDs.
ACS Translation Blocking (TB)Switch/root port rejects TLPs with AT≠00b (non-default AT field) unless they came from a trusted IOMMU. Prevents devices from sending translated addresses that bypass IOMMU.
ACS P2P Request Redirect (RR)All peer-to-peer memory requests are redirected upstream to the Root Complex (and IOMMU) instead of being forwarded directly downstream to the target device.
ACS P2P Completion Redirect (CR)Completions resulting from redirected P2P requests are also sent upstream through the Root Complex.
ACS Upstream Forwarding (UF)TLPs received on a downstream port that have a Requester ID not matching the port’s downstream device are forwarded upstream. Used in multicast and broadcasting scenarios.
ACS P2P Egress Control (EC)Fine-grained control of which downstream ports may receive peer-to-peer TLPs based on a bitmask table. Allows P2P between trusted ports but not untrusted ones.
ACS Direct Translated P2P (DT)Allows translated (AT=10b) P2P requests between trusted ports — used for high-performance GPU-to-GPU DMA via IOMMU-managed translations.
ACS is required for SR-IOV security. Without ACS, a Virtual Function in one VM can DMA directly to another VM’s memory through a PCIe switch. Operating systems and hypervisors must check ACS capability and enable it before assigning devices to VMs. Linux verifies ACS on all path bridges before allowing device assignment via VFIO.

📋 VSEC — Vendor-Specific Extended Capability (Cap ID 000Bh)

VSEC allows vendors to expose proprietary extended registers in the 100h–FFFh region in a format that is self-describing and discoverable via the standard linked list. Software can skip VSEC structures it doesn’t recognise without corrupting the chain. Any number of VSEC structures may be present.

FieldOffsetContent
Extended Cap Header+00hCap ID = 000Bh · Version · Next Offset
VSEC Header+04hVSEC ID [15:0] — vendor-assigned ID for this specific VSEC structure. VSEC Rev [19:16] — version. VSEC Length [31:20] — total byte length of this VSEC structure including the 8-byte header.
VSEC Registers+08h onwardsVendor-defined. Size = VSEC Length − 8 bytes.

Common uses of VSEC: proprietary debug/trace registers, firmware update interfaces, thermal monitoring, hardware performance counters, vendor-specific link health statistics, and manufacturing test access ports. Examples: Intel’s VSEC for PCIe Performance Monitoring Units (PMU), NVIDIA’s VSEC for GPU health status and throttle reasons.

⚡ Extended Config Space in Gen 6

All existing extended capability structures are completely unchanged in Gen 6. AER, VC, DSN, ATS, PASID, LTR, L1SS, ACS, VSEC — their formats, register offsets, and software interfaces work identically across all PCIe generations from Gen 1 to Gen 6.

Gen 6 adds new extended capability IDs for its new features:

Extended Cap IDStructureGen 6 purpose
002ChPhysical Layer 64.0 GT/s CapabilityReports Gen 6 PAM4 equalization status, FEC capability and enable, flit mode negotiation status, lane margining at Gen 6 speeds. Equivalent to the Gen 3 (002Bh), Gen 4 (0026h), Gen 5 (002Ah) PHY capability structures but for 64 GT/s.
002BhAlternate ProtocolNegotiates CXL protocol over PCIe 6.0 physical link. CXL 3.0 uses PCIe 6.0 PHY and flit mode but adds cache coherence protocols. This capability identifies whether a link is operating as CXL.io, CXL.cache, or CXL.mem in addition to or instead of standard PCIe.
0033hSPDM (Security Protocol and Data Model)Device identity and attestation using PCIe DOE (Data Object Exchange) and SPDM. Critical for secure AI accelerator deployment — allows host to verify firmware integrity and device authenticity before trusting it with sensitive model weights or user data.
0034hIDE (Integrity and Data Encryption)PCIe IDE extends SPDM to provide TLP-level encryption and integrity protection. Protects PCIe traffic from physical tapping on the PCB. Critical for Gen 6 AI infrastructure where model IP protection is required.
ECAM and the extended capability linked list work identically for Gen 6 structures. Software discovers the Physical Layer 64.0 GT/s Capability by walking the list from offset 100h exactly as it would discover AER or PASID. The 32-bit extended capability header format is the same. No new access mechanism is needed — ECAM and the linked list scale to however many IDs the spec defines.

📋 Quick Reference

ItemValue / Rule
Extended Config Space locationOffsets 100h–FFFh — 3840 bytes (960 DWs) per function
Access mechanismECAM (MMCFG) only — CF8/CFC cannot reach 100h+
ECAM region size256 MB total — 256 buses × 32 devices × 8 functions × 4 KB
ECAM address formulaECAM_BASE + (Bus×1MB) + (Dev×32KB) + (Fn×4KB) + Offset
ECAM base advertisementACPI MCFG table — consumed by OS during boot
Extended cap header32-bit DW: Cap ID [15:0] · Cap Version [19:16] · Next Offset [31:20]
First extended cap offsetAlways 100h — first DWORD at 100h is the first extended cap header
End-of-list sentinelNext Offset = 000h (points to Vendor ID register — never a valid cap location)
AER Cap ID0001h — Uncorrectable Error Status/Mask/Severity + Correctable Status/Mask + AECR + Header Log (4 DWs) + Root Error registers (RC only)
AER ECRC fields in AECRBits 5–8: ECRC Gen Capable, Gen Enable, Check Capable, Check Enable
AER First Error PointerAECR bits [4:0] — bit position of first uncorrectable error type that fired
AER Header Log16 bytes (4 DWs at 11Ch–12Bh) — captures TLP header that caused first uncorrectable error
VC Cap ID0002h — TC/VC mapping, VC arbitration. VC0+TC0 always linked. VC1–7 optional.
DSN Cap ID0003h — 64-bit globally unique serial number. Upper 24 bits = IEEE OUI.
ATS Cap ID000Fh — enables IOMMU translation caching. Device marks DMA with AT=10b after caching translation.
ACS Cap ID000Dh — prevents P2P DMA bypassing IOMMU. Required for SR-IOV security. Linux VFIO checks ACS before device assignment.
PASID Cap ID001Bh — 20-bit Process Address Space ID tags DMA with per-process IOMMU context. Required for per-process isolation on shared accelerators.
LTR Cap ID0018h — device reports snoop+no-snoop latency tolerance. Sent as point-to-point Message TLP to Root Complex.
LTR enable pathDevice Control 2 register (PCIe Capability DW5) LTR Mechanism Enable bit — must be set before device sends LTR messages.
L1SS Cap ID001Eh — L1.1/L1.2 ASPM and PM sub-states. L1.2 deepest — PLL off. Requires LTR to know when it’s safe to enter L1.2.
VSEC Cap ID000Bh — vendor-specific extended registers. VSEC Length [31:20] tells software how many bytes to skip.
Gen 6 new cap IDs002Ch: PHY 64.0 GT/s · 002Bh: CXL Alternate Protocol · 0033h: SPDM attestation · 0034h: IDE encryption
Extended Cap IDNameMandatory?Key purpose
0001hAERStrongly recommendedDetailed error logging, Header Log, ECRC
0002hVirtual ChannelRequired if multi-VCTC→VC mapping, VC arbitration
0003hDevice Serial NumberOptionalGlobally unique 64-bit ID
0004hPower BudgetingOptionalHot-plug power budgeting
000BhVSECOptionalVendor-specific registers
000DhACSRequired for SR-IOVP2P DMA blocking, IOMMU enforcement
000FhATSOptional (perf)IOMMU translation caching
0018hLTROptionalLatency tolerance → platform PM
001BhPASIDRequired for per-process isolationPer-process IOMMU context tagging
001EhL1 PM Sub-StatesOptionalL1.1/L1.2 deeper power states
002ChPhysical Layer 64.0 GT/sRequired for Gen 6PAM4 EQ status, FEC capability
002BhAlternate Protocol (CXL)Required for CXLCXL protocol negotiation over PCIe 6.0 PHY
0034hIDEOptional (security)TLP-level encryption and integrity
Scroll to Top