第四章：BAR空间与地址映射——Memory BAR、I/O BAR、Prefetchable属性
说到PCIe设备的地址映射，绕不开的就是BAR（Base Address Register）。说实话，很多刚接触PCIe的工程师会觉得BAR就是个地址寄存器，配个值就完事了。但在我多年的性能调优经历里，因为BAR配置翻车的案例太多了——地址冲突、非对齐访问、预取属性用错……每一条都够你调试好几天。
这一章，我们就来彻底讲清楚BAR的属性。
BAR到底是什么？
每个PCIe设备都有若干组BAR寄存器。它们的作用很简单：告诉系统“我设备需要多大的地址空间，以及我想要什么样的访问方式”。系统在配置阶段（枚举）会读这些BAR，根据你的申请分配一段连续的物理地址空间。设备后续的MMIO访问，全靠这段地址来完成。
核心要点： BAR决定了CPU如何“看到”设备内部的寄存器和数据缓冲区。也直接影响了你的驱动读写性能。
Memory BAR vs I/O BAR
从类型上分，BAR主要分为两类：Memory BAR 和 I/O BAR。差别可不是一点点。
| 属性 | Memory BAR | I/O BAR |
|---|---|---|
| 访问指令 | 使用load/store（普通访存指令） | 使用in/out（x86专用端口指令） |
| 地址空间 | 系统物理地址空间（通常大于4GB） | 64KB I/O端口空间（x86受限） |
| 批量传输支持 | 支持burst、合并写、预取 | 不支持，每次访问固定宽度 |
| 性能 | 高（可走RC缓存、合并写） | 低（每次访问都触发完整TLP） |
| 适用场景 | 大数据量、高性能寄存器 | 遗留设备、少量状态/控制寄存器 |
我建议：新设计的设备，能选Memory BAR就别用I/O BAR。为什么呢？一次I/O访问的开销比Memory BAR大一个数量级都不止。我曾经在一个NVMe控制器上看到，把中断状态寄存器从I/O BAR改成Memory BAR后，中断处理延迟从5μs降到了1.2μs。
小心遗留依赖： 有些老的x86系统BIOS可能在枚举时对I/O BAR有地址范围限制（比如只敢映射到0-0xFFFF），如果你的设备需要较大I/O空间，可能会分配失败。我在调试一个旧式COM express模块时就遇过这种情况。
Prefetchable属性——这玩意儿影响可不小
Prefetchable，直译是“可预取的”。它是个1位标志位，但含义很丰富。
说白了，这个标志告诉CPU和Root Complex：这块内存空间的内容在读取时没有副作用。也就是说，你提前读、合并读、甚至推测执行读，都不会改变设备的行为。
有副作用的场景？比如一个状态寄存器，读一次清一次中断。这种就不能设置Prefetchable。否则CPU觉得“我先猜猜你接下来要读什么”，结果把中断给清掉了——嗯，程序直接挂掉。
我个人的习惯：尽量把性能关键的数据面BAR设为Prefetchable。比如DMA描述符环、数据缓冲区、完成队列。因为这些空间本来就只有写和读，没有清状态的问题。
小测试： 用lspci -vvv查看你的PCIe设备，找到BAR条目中写着Prefetchable的部分。看看有多少BAR是Prefetchable的？如果一片全是Non-Prefetchable，你要警惕了——带宽很难跑满。
Non-Prefetchable BAR通常只适合控制寄存器、配置寄存器。还有一些特殊情况值得注意：
- 64位BAR：Prefetchable属性与64位支持绑定。当BAR在64位地址空间时，Prefetchable必须设为1（有些规范强制）。
- 组合方式：一块BAR的Type位决定了它是不是Prefetchable和地址宽度。例如Type=00b是32位Non-Prefetchable；01b是32位Prefetchable；10b是64位Prefetchable。
地址映射过程——别让系统乱砍地址
系统在PCIe枚举时会做这几步：
- 写全1到BAR寄存器，读出返回的掩码，就知道BAR需要多大的对齐空间（比如需要4KB，掩码就是低12位0）。
- 检查BAR是否在系统可用的物理地址范围里（考虑I/O窗口、PCIe MMIO大小）。
- 分配一个基地址，写回BAR寄存器，设备就对应到了那个物理地址。
注意：BAR地址的对齐要求是空间大小的整数倍。比如需要8KB，基地址必须8KB对齐。你想想看，如果系统剩下一个8KB的洞，但基地址是4KB对齐但跨了4KB边界，设备枚举就会失败。
我记得有一次调一个FPGA加速卡，BAR申请了1MB，系统只给分配在48位物理地址的高端（因为低端4GB已经被显卡占满了）。结果驱动里把地址截断到了32位——坑啊！从那以后我每次写驱动都会检查resource_size和pci_resource_start的返回值是否大于0xFFFFFFFF。
一张图理清BAR空间映射
下面这个SVG图总结了三种BAR属性和它们与系统地址空间的关系。注意箭头方向：CPU端通过RC访问设备段，设备通过DMA访问System Memory端。
注意： Prefetchable设定不当会导致CPU推测执行读取到无效数据，或者导致写合并（Write Combining）无法启用。我在做RDMA网卡时调过这个，Non-Prefetchable的BAR即使MMIO写合并开启也无法生效，带宽从90Gbps直接掉到40Gbps。——最后改了一个bit就好了。
实战中的避坑清单
- BAR大小与对齐：不要申请小于4KB的BAR（很多系统不支持），对齐一定严格按掩码算。
- Prefetchable属性：一旦设了Prefetchable，设备必须保证所有寄存器的读不产生副作用。如果你的控制寄存器读一次会清某个状态，就千万别设。
- 64位地址跨4GB边界：虽然64位空间很大，但有些老式BIOS或桥片可能不支持给BAR分配超过4GB的地址。遇到这种情况，可以在驱动里手动申请低端DMA缓冲区，或者改用IOMMU。
- 非对齐访问：PCIe规范表示BAR地址必须对齐到空间大小，但驱动做MMIO读写时也要注意，不要跨边界访问（比如读8字节跨越了设备内部的寄存器页）。
- 多个BAR之间不要重叠：这个看似基础，但我在一个FPGA设计里见过，因为内部地址译码错误导致BAR0和BAR1映射到了同一段内部寄存器——结果系统一访问就崩溃。
调试小工具： 用 setpci 可以现场修改BAR值（需要root），但修改后必须重新加载驱动。我喜欢在枚举后先 cat /sys/bus/pci/devices/xxxx/resource* 看一眼地址范围，确认是否正常。
嗯，BAR空间看起来是个小概念，但它直接决定了CPU与硬件之间的通信效率。Prefecthable的设置、地址对齐、类型选择，每一个细节都能在实测中看到明显的性能差异。我自己测试的时候，经常先配成一个错误的值，然后通过性能计数器对比——差距出来了一目了然。希望大家今后设计或调试PCIe设备时，把BAR当作一个重要的优化点，而不只是一行初始化代码。