What PCIe config space says about a device
Before any driver loads, a PCIe device has already told the host what it claims to be. That claim is a small, tidy record, and it gives away more than you would think.
By Lethal Research
When a PCIe card is powered up, the host reads it before any driver exists. That first read covers a small region on the device called config space. Everything the operating system decides next rests on what it finds there. Which driver to load. How much address space to hand over. Whether the device may master the bus at all. The card gets to fill that region in. This is why the phrase "donor profile" exists in this market, and it is worth learning as a fact rather than a marketing word.
The shape of the record
The first 64 bytes of config space are set by the standard. PCI Express grew that region to 4096 bytes per function to hold capability structures. But the header at the front is the part every host reads first, and it has not changed in decades. Type 0 headers describe endpoints, which is what a DMA card is. Type 1 describes bridges and switches.
| Field | What it declares | What it decides on the host |
|---|---|---|
| Vendor ID | Who made the silicon. Allocated by PCI-SIG, so the number space is public and traceable. | Half of the key the OS uses to pick a driver. An unallocated or nonsense value is immediately odd. |
| Device ID | Which part this is, chosen by the vendor. | The other half of the driver key. Together they produce the hardware ID you see in Device Manager. |
| Revision ID | Silicon stepping. | Drivers branch on it for errata. It is also a detail that a careless profile gets wrong. |
| Class Code | What category of thing this is: storage, network, display, and so on. | Determines which class driver may claim the device when no specific driver exists. |
| Subsystem Vendor ID / Subsystem ID | Who assembled the board, and which board variant it is. | How a driver tells a reference design from an OEM card with different wiring. |
| Base Address Registers | How much memory or I/O space the function needs, and of what kind. | The host programs these during enumeration. Sizes and types are part of a device's signature. |
| Capability list | A linked list of structures: MSI, MSI-X, power management, PCIe link capabilities. | Declares link width, speed, and interrupt behaviour. Rich, and easy to get internally inconsistent. |
Simplified. The binding definition is the PCI Express base spec from PCI-SIG. The layout is also summarised in public.
Why a profile is more than two numbers
The simple model of firmware identity says you set a vendor ID and a device ID and you are done. That model is wrong, and the reason is fit. A real card agrees with itself. Its class code fits its BAR layout. The BARs fit the capability list. The capability list fits the stated link width. All of it fits the driver a real operating system would load, and the behaviour that driver then expects. Say you claim to be a common storage controller but show BARs that controller never had. The record now argues with itself, and that is the cheapest thing in the world to look for.
This is also why "donor" is the right word. The useful profiles are copied whole from devices that really exist. They are not built up from parts that merely look right. A donor gives you a set that agrees with itself: identity, class, BAR sizes, capability layout, the lot. That is an engineering limit, not a stealth claim.
None of this means a tidy profile cannot be picked out, and nobody honest will tell you otherwise. Config space is one signal among many. The host reads it at boot, and that host is a machine the other side may be watching by other means too. A well-built profile takes away the obvious contradictions. It does not make a device undetectable, and a vendor who says otherwise is either confused or lying to you.
What you can look at yourself
Config space is not secret. Every operating system reads it on every boot. The standard tools that print it ship with Linux and can be had for Windows. Reading your own machine's devices is the fastest way to make this real. You will see at once that a real device has a dense record, and that the fields answer to each other.
# Linux: list every PCI function with vendor/device IDs and class
lspci -nn
# Verbose view of one function: BARs, capabilities, link width and speed
lspci -s 03:00.0 -vvv
# Same data as raw config space bytes, standard header region only
lspci -s 03:00.0 -xxx
# Windows: the hardware ID the OS derived from vendor and device ID
# Device Manager > device > Properties > Details > Hardware Ids- Compare two cards you own. Note how much of the record is layout rather than identity.
- Look at a device whose driver you know. Then read the class code and BARs that driver expects. The link between them is the point.
- Note that subsystem IDs on an OEM board often differ from the reference silicon. That is normal and expected, not a red flag.
The takeaway for a buyer is narrow but useful. When a firmware listing talks about profiles, it means how fully and how neatly a board fills in this record. That is a real engineering trait you can reason about. It is not a safety rating, and it is not the only thing anyone is looking at.
Read next
Questions about this? Ask on Discord
All posts