PCIe Chapter 3: From Unknown Topology to Function Discovery

Follow the same tree to discover functions

Enumeration starts at a platform-provided root, establishes bus ranges for the bridge path, probes downstream functions and records their identities. Chapters 1 and 2 explain the topology and configuration fields used here.

Specification route: Figures 7-1/7-2 → bridge bus-number fields in Figure 7-14 → identity and header layout in Figures 7-7/7-8.

The platform supplies an entry point; Function reads supply evidence

Software starts with platform-provided Host/Root Bridge information: Segment, Bus ranges, and configuration access services. It does not search arbitrary physical memory. The Root Bridge's platform interface differs from a Root Port's external Link role. Firmware 3.3 requires all Host Bridges to be configured so that the OS can manage their downstream devices.

Vendor ID is the specification's recommended presence probe, with FFFFh indicating no Function. Software-visible data is not necessarily Completion payload: for software depending on all-one responses, the Root Complex synthesizes that value from a Configuration Request's UR result. Failed access or an unconfigured path cannot establish that a physical card is absent merely from arbitrary buffer contents.

0xFFFF0001 is not an ordinary Vendor/Device ID

RRS (Request Retry Status) is Base 6.0's status for temporary inability to service a Request in specified circumstances. It is legal only under the applicable Reset/Readiness conditions, not as a general busy response at any time.

The read must cover both Vendor ID bytes. A read of only that 16-bit field returns 0001h, which is not an assigned Vendor ID. With visibility disabled or other locations read, software must not expect this same format; the Root Complex reissues the Request where required. Waiting limits depend on Reset, Readiness, and platform policy rather than one universal delay.

Open a temporary downstream range, then finalize it

The example follows one branch to completion before returning to its sibling. It temporarily uses the platform's 3F limit as Subordinate, then narrows the range to the discovered topology. This is a teaching strategy, not a mandatory universal algorithm.

Header Type 80h at 03:00.0 only permits probing other Functions; Function 1's presence is separate evidence. Header Type 00h at 04:00.0, without another mechanism indicating otherwise, prohibits blanket probing of Functions 1–7. Ordinary Link partners use Device 0 in this example, while internal Switch Downstream Ports can use other Device Numbers.

Figure 7-14 locates Secondary/Subordinate at 0x19/0x1A, each eight bits, with meanings on p.937. Configuration Writes must complete before software uses the new path. The example does not derive a Bridge's own BDF from Primary Bus Number. A platform with reservation requirements need not narrow its final limit to 04.

BDF

Bus/Device/Function

Header Type and Configuration Request Type are distinct

Configuration Header Type 1 describes a Bridge layout. Configuration Request Type 1 routes toward a deeper target. For 03:00.1, the Root Port's next Bus is 01, so the Request continues to the Switch as Type 1. The Switch recognizes Bus 03 as Downstream A's immediate downstream Bus and converts it to Type 0 before sending it to the Endpoint. A Bridge also processes valid Type 0 Requests targeting its own Configuration Space.

This describes externally visible routing, without assuming the Switch's internal logical Bus is another physical PCIe Link. Targets outside valid ranges follow UR handling. (Base 6.0 §7.3.2–§7.3.3, pp.912–913.)

Where does an Endpoint's Requester ID come from?

The preceding section routes a Configuration Request to an Endpoint; now look at Requests the Endpoint initiates. Non-Flit Configuration Request Figure 2-33 contains both Requester ID and Destination ID. The former identifies the initiator of the Configuration Request; the latter identifies its target Function. Do not use the host's Requester ID from that Configuration Write as the Endpoint's own future Requester ID.

Before its initial Configuration Write, a Function must not initiate Non-Posted Requests, because their Completions need a valid Requester ID. The specification provides an exception for Functions within a Root Complex accessing system boot devices; it does not apply to this ordinary Endpoint example. A completed configuration write alone does not establish readiness for DMA: Bus Master Enable, resources and device initialization must also be checked.

DMA

Direct Memory Access, device access to memory

For ARI (Alternative Routing-ID Interpretation) Bus capture, see Chapter 26. Flit Mode Segments and Shadow Functions also have separate identification rules; consult §2.2.6.2 rather than extending this example’s BDF decomposition to them.

PCI Express Base 6.0 §2.2.6.2, printed/PDF pp.156–157; §2.2.7.1 and Figure 2-33, pp.164–165; §6.4 Device Synchronization, pp.717–718.

How does a Flit Mode Configuration Write supply a Segment?

The preceding example identifies an Endpoint within one Hierarchy using Bus, Device and Function. Flit Mode also has separate Segment fields for identification and routing across Hierarchies. In the §2.2.1.2 Segment Rules, a Configuration Request sent by a Root Port in Flit Mode must include OHC-A3 with Destination Segment Valid (DSV) set and the correct Destination Segment, even in a single-Segment system.

If the Function receives a Configuration Write in Non-Flit Mode, §7.7.9.4 requires Segment Captured to clear. That does not prove the Segment value is zero; when DSV is clear the corresponding Destination Segment field is Reserved. A status snapshot alone cannot reconstruct the entire history of path modes.

Capturing a Segment, having a Requester ID and being permitted to initiate DMA are separate checks. Whether a Memory Request includes Requester Segment depends on its type and the §2.2.1.2 conditions; Segment Captured=1 does not mean every Memory Request must carry OHC-C.

DMA

Direct Memory Access, device access to memory

PCI Express Base 6.0 §2.2.1.2, Figures 2-6, 2-9, 2-11 and Table 2-6, printed/PDF pp.123, 131–133, 134–135 and 140; §2.2.6.2, p.157; §2.2.9.2, p.199; §§7.7.9.1 and 7.7.9.4, Figures 7-121 and 7-124, Tables 7-107 and 7-110, pp.1072–1073 and 1076–1077.

Where should we look when a known BDF cannot be read?

Use the same topology and target Endpoint 03:00.1. Identify the branch leading to it, then inspect the Secondary and Subordinate Bus Numbers of each Bridge from the root downward. This is a reading sequence for the evidence, not a claim about the order in which hardware processes a Request.

Use Figure 7-14 to locate Secondary and Subordinate; read §7.5.1.3.3–7.5.1.3.4 for their meanings, then §7.3.3 for Type 1 forwarding and conversion. For ECAM writes, §7.2.2 requires a platform method for software to ensure the Completer has finished the write; it does not require one particular method. (Base 6.0, printed/PDF pp.908, 912–913, 936–937.)

How is an absent Function different from an unimplemented Register?

When PCIe Completion information is available, §7.3.1 requires Unsupported Request (UR) for an unimplemented Bus, Device or Function. A read of an unimplemented Register within an implemented Function returns Successful Completion and zero data under §7.3.3, provided no other reportable error applies. The target and the result differ.

When only a software read value is available, first establish whether access succeeded, which BDF and offset were read, and how the platform reports transaction results. Under the conditions described in §2.3.2, a Root Complex synthesizes all-one data from UR for software that relies on it; that data is not carried in the UR Completion. Interpret RRS using the readiness scenario above. (Base 6.0, printed/PDF pp.220–221, 911, 913.)

Discovery does not finish resource and workload setup

Enumeration provides Function inventory, bridge paths, and identity clues, not proof that MMIO or DMA is ready. Firmware 3.3 §3.5 (pp.34–35) requires the specified boot/console paths and all Host Bridges to be configured; other devices may be left to the OS. An arbitrary unconfigured Endpoint alone does not establish a firmware violation.

MMIO

Memory-Mapped I/O, mapped device-register access