3. 配置空间基础：配置空间的作用、访问方式
我个人一直觉得，配置空间是PCIe里最基础也最容易被忽略的东西。说白了，它就像每个设备的一张“身份证”加“用户手册”。Root Complex就是靠读这张身份证知道你是谁、你有多大本事、需要多大资源。没有配置空间，枚举流程根本跑不起来。
3.1 配置空间到底干什么用？
每个PCIe设备（包括Switch、Bridge、Endpoint）都有一段固定的寄存器区域，叫配置空间。系统软件（BIOS、OS、驱动）通过读写它来完成设备发现、资源分配、中断配置、错误报告等核心操作。
配置空间的核心职责：
- 设备识别：Vendor ID、Device ID告诉你这是谁的什么芯片。
- 资源需求声明：Base Address Registers（BAR）告诉系统需要多少MMIO/IO空间。
- 中断与错误控制：MSI能力、PCIe Capability、AER等扩展结构。
- 链路与状态管理：Link Status、Device Control等运行时寄存器。
我遇到过一些刚入行的工程师，调试时发现设备不工作，上来就抓PCIe链路波形。其实很多时候，先读一下配置空间的Vendor ID是否返回正确，能省下一大半时间。嗯，配置空间就是第一道检票口。
3.2 配置空间的访问方式：IO映射 vs 内存映射
访问配置空间有两条路：IO映射方式（CF8/CFC） 和 内存映射方式（MMIO）。前者是PCI时代的老办法，后者是PCIe推荐的现代方式。
3.2.1 IO映射方式：CF8/CFC
x86体系在IO空间中留了两个32位端口：
| 端口地址 | 名称 | 作用 |
|---|---|---|
0xCF8 | CONFIG_ADDRESS | 写入总线号、设备号、功能号、寄存器偏移 |
0xCFC | CONFIG_DATA | 通过IN/OUT指令读写实际寄存器值 |
流程很简单：
- 往CF8写入一个32位值，其中编码了目标设备的BDF（Bus:Device:Function）和寄存器偏移。
- 从CFC读或写，完成实际访问。
// 读配置空间某寄存器的“经典”写法（x86汇编思路）
mov dx, 0xCF8
mov eax, (bus << 16) | (device << 11) | (function << 8) | (offset & 0xFC) | 0x80000000
out dx, eax
mov dx, 0xCFC
in eax, dx
// eax 中即为目标寄存器值
一个小技巧：我建议写底层代码时，把CF8/CFC的访问封装成函数，避免到处写魔数。曾经有同事直接硬编码0xCF8，结果换平台时忘记改端口号，设备一直读不到，排查了半天。
3.2.2 内存映射方式（MMIO）
PCIe引入了一个新概念：ECAM（Enhanced Configuration Access Mechanism）。它将整个配置空间映射到一段连续的物理内存地址范围内。CPU直接通过普通的LOAD/STORE指令就能访问任意设备的配置空间，不需要IO端口操作。
- 映射公式：基地址 + (Bus × 256 × 4096) + (Device × 8 × 4096) + (Function × 4096) + 偏移
- 每个Function固定拥有4KB配置空间（PCI只给了256字节，PCIe扩展为4KB）。
- 优点：访问速度快，不需要IO指令切换保护模式，兼容非x86架构。
3.2.3 两种方式的对比
| 对比项 | IO映射（CF8/CFC） | 内存映射（MMIO/ECAM） |
|---|---|---|
| 访问指令 | x86 IN/OUT（特权指令） | 普通LOAD/STORE |
| 地址范围 | 两个固定端口 | 一段连续的物理内存地址 |
| 每个Function空间 | 256字节（PCI兼容） | 4KB (PCIe完整空间) |
| 系统支持 | 仅x86原生支持 | 所有架构（ARM、RISC-V等） |
| 性能 | 较慢（IO总线事务） | 快（内存总线事务） |
| 推荐场景 | 旧平台、BIOS早期阶段 | 现代OS、高性能驱动 |
曾经踩过的坑：我有一块ARM服务器板卡，原厂BSP默认只实现了CF8/CFC模拟，但ARM根本没有IO空间，全靠MMIO模拟IO端口。结果配置空间访问慢得像蜗牛爬。后来我换成ECAM的MMIO方式，枚举速度提升了十几倍。所以，新设计一定要支持ECAM。
3.3 配置空间结构速览
一个Function的配置空间布局分为两部分：
- Header Type 0（Endpoint）：偏移0x00~0x3F，包含Vendor ID、Device ID、BAR、Subsystem ID等。
- Capability List（0x40~0xFF）：以链表形式串起各种能力结构（Power Management、MSI、PCIe Capability、ARI等）。
- Extended Capability（0x100~0xFFF）：PCIe新增部分，包括AER、DPC、SR-IOV等高级特性。
注意：偏移0x00~0x3F的Header区域，不同类型设备（Type 0/Type 1/ Type 2）结构略有不同，但前16字节完全一致。枚举时首先读0x00处的Vendor ID，如果返回0xFFFF，说明该BDF上无设备。
3.4 一张图看懂配置空间访问全景
下面这张SVG把上面讲的两条路径和内部结构汇总到了一起。你跟着箭头看一遍，基本就清楚了。
3.5 实际项目中的应用
我记得有一次调试一块FPGA加速卡，卡上做了两个PCIe Function。BIOS枚举时只识别到Function 0，Function 1怎么都读不到。最后发现是硬件把Function 1的配置空间基地址算错了，导致MMIO映射到了错误的内存区域。我用CFC方式单步读了一下Function 1的Vendor ID，返回了0xFFFF——说明硬件根本没把配置空间挂到总线上。嗯，这种问题用MMIO根本看不出，因为它会返回总线错误异常。所以早期调试我建议先用CFC方式确认设备在不在，再用MMIO跑批量操作。
一个小习惯：我自己写驱动时，枚举代码里会保留一个“暴力CFC读Vendor ID”的回退路径。如果ECAM读返回异常，自动切换到IO方式再试一次。虽然慢，但能帮你判断是配置空间映射问题还是设备本身挂死。
另外，配置空间的访问方式也影响中断响应。MMIO走的是内存总线，没有IO陷阱的开销，所以现代Operating System在启动后几乎只用ECAM。但在BIOS阶段，因为内存控制器还没完全初始化，很多BIOS仍然走CF8/CFC。你想想看，这是不是挺灵活的？
总结一下：配置空间就是设备的户口本，CF8/CFC是老式手动翻页查询，ECAM是电子档案一键检索。不管用哪种方式，目的都一样——让CPU能读懂设备、配置设备。后面的枚举流程，就是基于这套访问机制来一步一步扒开设备树。