PCIe BARs Explained: MMIO, Address Space, and Device Resources

A PCI or PCI Express Base Address Register is part of a device function’s PCI configuration space. It tells platform software that the function exposes an I/O or memory resource and provides the base-address field used when that resource is assigned. The important mental model is that the BAR participates in describing an address window through which software can reach something implemented by the device; it is not itself a chunk of system RAM.

The operating system can then expose that resource to the device driver. Linux, for example, represents PCI BAR resources in its PCI device structures and provides helpers such as pci_iomap() so a driver can map a BAR and access device registers or device memory through the appropriate I/O accessors. Linux also warns drivers not to assume that the raw PCI bus address read from configuration space is identical to the host physical address, because platform-specific translation can exist.

Memory-mapped I/O, or MMIO, places device resources into an address space that software can access with memory-style operations through the architecture’s required I/O mapping and access mechanisms. A BAR that requests memory space can therefore end up associated with a host-visible MMIO range. Transactions targeting that range are routed toward the PCIe device rather than behaving like ordinary accesses to DRAM.

That is why a large MMIO window should not be read as “the PC lost this much RAM.” Address space and physical memory capacity are different concepts. The platform has to reserve a non-conflicting address range for the device resource, but reserving addresses does not allocate an equal-size buffer from installed system DRAM. A GPU can also expose multiple BARs for different purposes, such as control registers and apertures into device memory.

Platform software needs to know how much I/O or memory address space a BAR requires before it can place that resource without colliding with others. Microsoft documents the conventional PCI BAR probing process in its PCI virtualization material: the PCI bus driver can write all ones to a BAR and read the result to determine whether the BAR exists and how much memory or I/O address space it requires. This is a resource-size discovery mechanism, not a benchmark of the device.

Once resource requirements are known, firmware and operating-system PCI code can assign address ranges within the platform’s available windows. Linux requires drivers to request BAR regions so two devices do not accidentally claim the same resource, and its PCI helpers expose the already interpreted resources rather than encouraging drivers to reconstruct platform address translation from raw configuration values.

A memory BAR carries attributes that include the address form supported by that BAR. The practical distinction is placement capability: a resource limited to a 32-bit memory BAR has to fit in the addressable region available to that form, while a 64-bit memory BAR can describe an address above the 4 GiB boundary when the rest of the platform supports such allocation.

This distinction is about the address assigned to the device resource, not about whether the CPU itself is “32-bit” or “64-bit” in the everyday operating-system sense. Modern systems can have a mixture of device resources with different placement constraints, and bridges plus firmware must provide suitable windows for downstream devices.

Firmware options commonly labeled Above 4G Decoding allow compatible platforms to place suitable PCIe MMIO resources above the 4 GiB address boundary instead of forcing all of them into the lower address region. This becomes useful when a system has many or large PCIe resources competing for address space below that boundary.

The label is easy to misread. Enabling Above 4G Decoding does not install memory, enlarge VRAM, increase PCIe lane bandwidth, or by itself make a workload faster. It changes where compatible PCIe resources may be decoded in the system address map. Actual support still depends on the platform firmware, host bridge, operating system, and devices involved.

Discrete GPUs are the most familiar consumer example because software needs host-visible paths to GPU registers and memory resources. Historically, a GPU memory aperture exposed through a BAR could be much smaller than the card’s total local memory, so software accessed portions of that memory through a limited host-visible window. The BAR size therefore cannot be used as a generic VRAM-capacity field.

Even when a large aperture covers much or all of a device-local memory resource, the address-space reservation still is not an equal-size allocation of system DRAM. It is an address window through which transactions can reach the device. Device-local memory remains physically attached to the device unless a particular architecture explicitly implements something different.

PCI Express Resizable BAR extends this resource model by allowing supported functions and platform software to select among advertised BAR sizes for a resizable resource. On modern graphics platforms this can allow the CPU-visible GPU memory aperture to cover a much larger portion of VRAM instead of relying on a relatively small fixed window.

Resizable BAR does not eliminate BARs, and a system having ordinary PCIe BARs does not imply that Resizable BAR is supported. The complete enablement chain can include compatible CPU/platform firmware, motherboard settings, GPU firmware and driver support. Core Tech Tips covers those platform requirements and workload-dependent performance effects separately in the Resizable BAR and Smart Access Memory guide.

When firmware or an operating system cannot allocate a suitable non-overlapping window for a PCIe resource, the symptom is fundamentally a resource-enumeration or placement problem. Adding more system RAM does not inherently create the missing MMIO address range. The useful diagnostic questions are which BARs the device exposes, what sizes and address forms they require, what bridge windows are available, and what the firmware and operating system actually assigned.

For normal PC users, BAR details are usually invisible because firmware, the PCI bus driver, and the device driver cooperate to handle them automatically. They become relevant when interpreting firmware settings such as Above 4G Decoding, understanding Resizable BAR, diagnosing unusual PCI resource conflicts, or reading low-level tools such as Linux lspci output. Keeping address space, system DRAM, device-local memory, and PCIe link bandwidth separate prevents most of the common misconceptions.