PCIe BARs and MMIO Explained: How Devices Map Registers and Memory

A PCI Express device is not useful to an operating system merely because the link trained successfully. Software also needs defined address ranges through which it can reach device registers, on-device memory windows, or legacy I/O resources. PCI Base Address Registers, usually called BARs, describe those resource requirements in PCI configuration space.

During enumeration, firmware and the operating system discover those requirements and assign non-conflicting address ranges. A driver can then map the assigned resource and access the device through the operating system's supported I/O interfaces. This is resource mapping, not a copy of the device into system RAM.

PCI devices expose Base Address Registers in their configuration header. A BAR can describe memory space or I/O-port space, and memory BARs carry attributes such as whether the resource uses a 32-bit or 64-bit address. Operating systems probe these resources and retain the assigned ranges as part of the device's PCI resource information.

Microsoft's graphics-driver documentation describes PCIe BAR probing as the mechanism used to determine the memory or I/O address space required by a device. Linux likewise exposes BAR-backed PCI resources to drivers and provides helpers for requesting and mapping them.

Memory-mapped I/O, or MMIO, places a device resource into the processor's physical address space. Loads and stores directed at that region are routed to the device rather than behaving like accesses to ordinary DRAM. Drivers use architecture-aware I/O accessors and mapping APIs because ordering, caching, and access semantics can differ from normal memory.

Linux kernel documentation explicitly distinguishes PCI MMIO and I/O-port resources and warns drivers not to treat raw PCI bus addresses as host physical addresses. Platform firmware and chipset logic can remap resources, so drivers consume the operating system's assigned resource view.

A BAR's size tells the platform how much address space must be reserved for that resource. It does not describe PCIe link bandwidth, transfer rate, or how quickly the device can service accesses. Those are separate properties governed by the PCIe link, device architecture, memory subsystem, transaction behavior, and workload.

This distinction matters when interpreting firmware screens and tools that show large hexadecimal resource ranges. A 256 MB mapping means that address window spans 256 MB; it does not mean the device is transferring 256 MB at once or that it contains only 256 MB of physical memory.

A memory BAR can be defined as 64-bit, allowing the assigned resource address to sit above the 32-bit address range. Microsoft documents that a 64-bit PCI BAR consumes two sequential BAR slots in the configuration header because the address value spans two 32-bit registers.

This is one reason modern systems can allocate large PCIe resources without trying to squeeze every device window below 4 GB. The firmware, operating system, bridges, and device must still support a compatible resource layout.

A graphics card can have gigabytes of local VRAM while exposing a smaller host-visible PCIe memory window. The BAR is the host address aperture used to reach a device resource; it is not inherently a declaration of total local-memory capacity. Hardware and drivers can manage which portions of local memory are reachable through a limited aperture.

Resizable BAR changes that relationship by allowing supported PCIe devices and platforms to negotiate a larger BAR size from a device-defined set of supported sizes. It does not turn VRAM into system RAM, increase the PCIe link width, or guarantee a performance gain in every workload.

PCIe topology is a tree of root ports, bridges, switches, and endpoints. Resources assigned to endpoints below a bridge must fit within address windows that the bridge forwards downstream. That makes allocation a platform-wide packing problem rather than an isolated decision for each card.

Large or numerous BARs can therefore expose firmware or topology constraints even when each endpoint is individually valid. Linux PCI documentation includes resource reassignment and BAR-resizing mechanisms because changing one resource can require bridge windows and neighboring resources to be reconsidered.

A driver normally requests ownership of the assigned PCI resource and maps the needed portion into a usable kernel virtual address. Linux's pci_iomap family, for example, creates an I/O mapping for a selected BAR and lets the driver access the resource through I/O accessors. The mapping can cover the complete BAR or a bounded range.

That virtual mapping is a software view of the already assigned device resource. It should not be confused with the PCI bus address written into configuration space, the CPU's ordinary virtual memory mappings for applications, or the device's own internal addressing.

Think of a PCIe BAR as a request and descriptor for an addressable doorway into a device. The platform assigns that doorway a non-conflicting location, bridge windows route transactions toward it, the operating system records the resource, and a driver maps the part it needs. MMIO is the mechanism that lets processor memory accesses reach that device resource.

Keeping the layers separate explains many otherwise confusing observations: a GPU can have far more VRAM than its traditional BAR aperture, a 64-bit BAR can be placed above 4 GB, a larger BAR can create allocation pressure without changing link bandwidth, and a driver's virtual mapping is not the same address that appears on the PCIe bus.