PCIe Chapter 4: BARs, Address Spaces, and Resource Allocation

Connect a device resource to the CPU access path

BAR

Base Address Register

A BAR (Base Address Register) describes a device resource and its allocation interface. Determine type and size, allocate an aligned base, cover the range with every bridge window, then enable the applicable decoding.

Specification route: Figures 7-10–7-12 and Table 7-9 → bridge-window rules and Figure 7-14 → Command controls in Figure 7-5 and Table 7-4.

Identify the format before calculating size

A BAR resides in Configuration Space; it is not a workload buffer. A Type 0 Header has six DWORD locations, and a 64-bit BAR consumes two consecutive locations. A Bridge's Type 1 Header has only two BAR locations, distinct from its downstream Memory Windows.

A Memory BAR has bit 0 clear; bits 2:1 encode 32-bit as 00b and 64-bit as 10b, with Prefetchable in bit 3. An I/O BAR has bit 0 set and address bits beginning at bit 2, so the Memory BAR's four-bit mask does not apply. This example uses no I/O BAR: an ordinary PCIe Endpoint must not depend on OS allocation of I/O resources and must not generate I/O Requests.

Prefetchable expresses permitted behavior such as reads without side effects and tolerance of write merging, not current CPU cache state. A Prefetchable BAR on this ordinary Endpoint must support 64-bit addressing; a non-Prefetchable BAR may be 32-bit.

Size probes require the correct 32-bit or 64-bit width

The specified method disables the corresponding decoding, saves the original BAR, writes all ones, reads it back, and masks the encoding bits. Invert and add one within the intended width. Restore the original value, or establish a consistent new allocation before re-enabling decoding. Clearing BME does not remove earlier outstanding transactions; their absence is a separate assumption here.

BAR0 mask = 0xFFFFC000 & 0xFFFFFFF0
size = ((~mask) & 0xFFFFFFFF) + 1 = 0x4000

BAR2/3 mask = (0xFFFFFFFF << 32) | (0xFFE0000C & 0xFFFFFFF0)
size = ((~mask) & 0xFFFFFFFFFFFFFFFF) + 1 = 0x200000

BAR3 is BAR2's upper DWORD, not a separate I/O BAR despite reading all ones. The assigned values are 0x80004000 for BAR0 and 0x2000000C/0x00000001 for BAR2/3. An initial zero BAR does not prove absence; use the valid unimplemented result from the correct probe, and do not misinterpret an all-zero mask as a 4 GiB request.

Assume BAR0+0x120 is a valid device Register, yielding PCI address 0x80004120. The example separately assumes identical CPU/PCI mapping, so the CPU uses that same number. This is not a platform-wide guarantee. The Register and the available resource addresses are also teaching assumptions.

Every Bridge Window on the path must contain the target

The path to 03:00.0 passes through Root Port 00:01.0, Switch Upstream Port 01:00.0, and Downstream A 02:01.0. All three support and use the following windows in the example. The platform reserves the ranges, with no competing sibling allocation.

The Base's omitted lower 20 address bits become zero, while the Limit's become one, creating inclusive ranges with 1 MiB granularity. A low nibble of one in the Prefetchable fields indicates 64-bit support, with Upper fields supplying address bits 63:32. A window may exceed a BAR's size, but its gaps need not contain valid Registers. Bus Number ranges do not replace Memory Windows.

MSE and BME control different behavior

Command is a 16-bit Register at 0x04. Bit 0 controls I/O Space, bit 1 MSE controls received Memory accesses, and bit 2 BME controls Function-originated Memory/I/O Requests. A Type 1 Port's BME also controls forwarding those Requests upstream, without blocking Completions.

With resources, windows, platform mapping, and the device interface ready, Command=0x0002 on the Endpoint and all three Bridges permits the example's CPU MMIO read while prohibiting Endpoint-originated DMA Memory Requests. BME does not block the read's Completion. BME=0 also prohibits MSI/MSI-X because they use in-band Memory Writes.

MMIO

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

DMA

Direct Memory Access, device access to memory

MSI

Message Signaled Interrupt

MSI-X

Message Signaled Interrupts Extension

Changing the Endpoint to 0x0006 adds permission to originate the relevant Requests, but does not prepare buffers, device work, platform translation, or upstream Port BME. Do not update Command by blindly writing back a DWORD that includes Status at 0x06, since Status contains RW1C bits.

Why can Configuration Space be readable while a Memory Read fails?

Configuration access selects a Function and Register using BDF and an offset; a Memory Read selects its target by memory address. In the existing example, place 0x80004120 inside BAR0 and each Bridge Window, then inspect Memory Space Enable (MSE) along the receiving direction.

BDF

Bus/Device/Function

Locate the BAR and Bridge fields in Figure 7-10 and Figure 7-14; decode Memory Base/Limit with §7.5.1.3.8; then read MSE in Figure 7-5/Table 7-4, including the Primary Side condition for a Type 1 Header. Finally use §2.3.1 to determine how UR is returned for a Request requiring Completion. (Base 6.0, printed/PDF pp.208, 916–918, 928, 936, 940.)

Is every byte inside a BAR readable?

The BAR defines an address range, while the device interface defines which Registers can be used. The example assumes only that +0x120 is a readable Register; it does not define +0x3000, although that offset is also inside BAR0. Base 6.0 §7.5.1.2.1 (p.930) permits a Function to return UR for unused locations its programming model never accesses. The device interface and transaction evidence are needed to assess an actual access.

Keep allocation and handoff conclusions separate

Firmware 3.3 §3.5 (pp.34–35) uses I/O/Memory Enable and ROM Enable to determine corresponding resource configuration, not BME to establish BAR validity. Enabled resources must be correctly configured by firmware, but drivers still prepare device-specific work.

ROM

Read-Only Memory