PCIe路由机制详解：TLP地址路由、ID路由与隐式路由排查

1. 先把"一个TLP怎么找路"这件事想明白

我在调试一类板卡时遇到过这样的情况：卡插上去，lspci里能看到设备，lspci -vv读出来的 BAR 也不是全 F，但驱动一request_mem_region就报冲突，ioremap之后读寄存器一律返回0xFFFFFFFF。这类问题的根源通常不在驱动本身，而在PCIe 路由方式这一层——请求包（TLP）在交换结构里没被投递到它该去的地方，或者它压根就没被发出去。这篇内容就是围绕 PCIe 的三种路由方式，从 TLP 头的字段一路讲到 Linux 内核里的资源树和实际排查手段。

适合谁看：写过 PCI/PCIe 设备驱动、做过板级 bring-up、或者正在啃 PCIe 子系统的同学。对完全没有接触过配置空间的人，前三节可能读起来有点吃力，但后面几节的排查流程和踩坑记录是能直接拿去用的。我尽量把每个结论背后的"为什么"说清楚，而不是只给操作步骤——因为路由这块，知其所以然比记住命令重要得多，同样一条lspci -t，理解原理的人看到的是总线号分配是否合理，不理解的人只看到一棵树。

1.1 PCIe在软件眼里是一棵"假树"，物理上却是一张网

要理解路由，先得把心理模型摆正。传统 PCI 是一条共享总线，所有设备挂在同一组信号线上，任何一个事务天然就能被所有设备看到，谁需要谁响应，仲裁器负责协调。PCIe 换了模型：链路是点对点的，Root Complex 往下挂 Switch，Switch 分出多条下游链路，每条链路上接 Endpoint 或者再挂 Switch。

但配置软件看到的仍然是树。Switch 的每一个端口在软件眼里都是一个"桥"设备，有自己的 Bus/Device/Function 和完整的配置头（Type 1）。Switch 内部那些真正的交叉开关逻辑，软件是看不见的；它只能通过每个端口的配置头去"告诉"硬件：你这边的下游总线号范围是多少、内存窗口在哪、IO 窗口在哪。硬件收到一个 TLP，就查这些寄存器决定往哪个口送。

这个设计有个直接后果：路由决策完全依赖配置头里写进去的那几个字段。软件要是把窗口写错了，硬件不会报错，它只会老老实实按错误的窗口去转发——发错了地方，或者干脆丢包。这也是为什么 PCIe 的路由问题往往表现为"静默的失败"，而不是一个干脆的报错。

再补一个容易混淆的点：PCIe-to-PCI 桥（也就是常说的 PCI 桥）在软件模型上和 Switch 端口没有本质区别，同样是 Type 1 配置头，同样有 Bus Number 和窗口寄存器。区别在于它下面挂的是真正共享的总线，多个设备共享同一组地址空间和同一根中断线。所以你在lspci -t看到的那种带-[的层级，有可能是 Switch，也有可能是 PCI 桥，需要用lspci -vv看配置头里的 Header Type 和 Capability 才能分辨。

1.2 TLP头里没有"目的端口"，只有判据

很多人第一次看 TLP 格式会疑惑：这 3DW/4DW 的头里，哪儿写着"我要去哪个设备"？答案是——没有这个字段。TLP 头里只有Fmt（几个 DW、带不带数据）、Type（事务类型）、Requester ID、Tag、地址或者目标 BDF 等等。至于"该往哪个下游端口走"，是沿途每个端口根据Type决定用哪套判据、再查自己的寄存器得出的结论。

三种判据对应三种路由方式：

表里第三行"软件不参与"这句话要理解到位：隐式路由的意思是，一个 Message 该往哪走，是由规范预先规定好的，软件既不用配窗口也不用配总线号。但这不代表软件不需要理解它——你调中断不响、PME 唤醒不了、AER 错误报不上来，很多都是 Message 这一路出了问题。

还有一种特殊情况值得单独提：Local - Terminate at Receiver，也就是 TLP 到了接收端就地消化，不再转发，典型的是某些厂商自定义消息和 Vendor Defined Message 的特定用法。这个在处理 Switch 内部消息或者 DPC（Downstream Port Containment）相关流程时会碰到，普通设备驱动基本遇不上。

1.3 为什么驱动作者必须关心路由

有人会说：枚举和资源分配不是固件和内核干的事吗，我写驱动只关心 BAR 和中断不就行了。这话对一半。你确实不需要自己去写桥的窗口寄存器，但你需要能判断"我这个设备的 BAR 有没有被正确分配到一条能走通的路径上"。

举个很具体的例子。一块设备要求 8GB 的 64 位 prefetchable BAR，插在一个 Switch 的 downstream port 后面。这个 Switch 上游端口的 prefetchable 窗口如果只有 4GB（很常见，因为固件按默认策略算的），那么内核在分配的时候要么失败，要么把设备挪到别的总线下去。你在驱动里pci_iomap拿到的地址看起来是个合法内核虚拟地址，readl也不报错，但读回来的数据全是垃圾——因为 TLP 地址落在 Switch 上游窗口之外，被 UR（Unsupported Request）丢掉了，而默认的 UR 处理可能只是记个日志。

所以驱动侧至少要能做三件事：确认 BAR 分配结果是否落在有效窗口内、能读懂 AER 日志里报的是哪一类错误、知道从/sys和/proc/iomem的哪个文件去核对。这三件事都建立在理解路由方式的基础上。

2. 地址路由：内存和IO请求靠窗口一层层筛下来

2.1 地址路由的TLP头长什么样

一个 Memory Request 的 TLP 头，Fmt字段决定了它是 3DW 还是 4DW（对应 32 位地址还是 64 位地址），以及带不带数据。具体编码大致是这样：Fmt=0b000是 3DW 无数据，0b001是 3DW 带数据，0b010是 4DW 无数据，0b011是 4DW 带数据。注意这里的编码在不同版本规范里略有调整，但"低两位表示有没有数据、高位表示 DW 数"这个规律是稳定的。

Type字段区分是 Memory 还是 IO：Memory Read/Write 的 Type 是0b00000，IO Read/Write 是0b00010。地址放在头的后半部分：3DW 的情况下，第三个 DW 的[31:2]就是地址的[31:2]；4DW 的情况下，第三个 DW 是地址低 32 位，第四个 DW 的[31:0]是地址高 32 位。

两个细节容易忽略：

第一个是地址永远按 4 字节对齐编码，低两位不出现。实际访问的字节范围由First DW Byte Enable和Last DW Byte Enable这 8 个 bit 决定。所以一次writeb到 BAR+1，产生的 TLP 里地址是 BAR 起始地址 + 0 或者 + 4（按 4 字节对齐），然后靠 byte enable 精确指定是哪一个字节。你在用ioremap之后调writeb时不用管这些，硬件和桥会自动处理，但如果你在看 trace 或者自己拼 TLP（比如做验证平台），这一点必须清楚。

第二个是4DW 的情况下，最后一个 DW 的低两位是保留的，不是 byte enable。这个是很多人自己拼包时踩过的坑，把 byte enable 填到那个位置，对端解析出来就是错的事务。

2.2 桥的Base/Limit寄存器本质上就是路由表

一个 Type 1 配置头里跟地址路由相关的寄存器，主要是下面这几组：

这里的粒度是硬件写死的：Memory Base 寄存器只有高 16 位有效，低 20 位读出来永远是 0；IO Base 只有高 12 位有效。所以一个 Memory 窗口最小 1MB、最大 4GB（32 位时），一个 IO 窗口最小 4KB、最大 64KB（16 位时）。

判据是闭区间：Base <= addr <= Limit，两端都包含。举个具体例子，Memory Base 寄存器写成0x8000、Memory Limit 写成0x80FF，实际窗口就是0x80000000到0x80FFFFFF，共 16MB。为什么是 16MB：(0x80FF - 0x8000 + 1) * 1MB = 0x100 * 1MB = 16MB。如果你的 BAR 是 32MB，这个窗口放不下，硬件就不会转发，TLP 直接被丢弃并上报 UR。

Prefetchable Memory Base的低 4 位有个特殊编码：0b0001表示这个桥支持 64 位预取窗口，此时要去 0x28/0x2C 读高位。如果是0b0000，说明只支持 32 位预取窗口，高位寄存器无效。这个细节在写枚举代码或者做静态检查脚本时会用到。

2.3 Linux里这些窗口是从哪来的

这里要分两条路径讲，因为 x86 和 ARM64 的做法差别不小。

x86 平台走 ACPI。Root Bridge 的窗口由固件通过_CRS（Current Resource Settings）方法报告，内核在drivers/acpi/pci_root.c里解析这些资源，转换成pci_host_bridge的windows链表。之后pci_scan_child_bus枚举时，pci_read_bridge_bases会把每个桥配置头里的 Base/Limit 读出来，通过pci_bus_add_resource挂到对应pci_bus的resource[]数组上。这一步只是"读"，不是"写"——也就是说，如果固件已经分配好了，内核就照着用。

ARM64 平台通常走设备树。dma-ranges和ranges属性描述了 PCI 地址空间到 CPU 地址空间的映射关系，内核在pci_host_common_probe或者各家的 host controller 驱动里解析，同样生成pci_host_bridge的窗口链表。

关键点在于：默认情况下内核不重新分配，它信任固件。只有在几种情况下才会走pci_assign_unassigned_resources()：固件根本没做枚举（某些嵌入式平台常见）、资源冲突导致部分 BAR 没分配、或者启动参数里加了pci=realloc。重新分配的逻辑在drivers/pci/setup-bus.c里，pci_bus_size_bridges先自底向上算每个桥需要多大窗口，pci_bus_assign_resources再自顶向下把地址填进 Base/Limit 寄存器。

这个顺序值得说一下为什么。自底向上算是因为子设备的需求决定了父窗口的最小尺寸，你不可能先给父节点分配再回头改；自顶向下填是因为父窗口的位置决定了子窗口能落在哪段地址范围内。这个"先算后填"的两遍扫描是所有资源分配算法的标准做法，你在自己写 Bootloader 做简易枚举时也建议照这个思路来。

2.4 地址路由失效的四种典型表现

我按遇到问题的频率排一下，这四种在实战中占了绝大多数。

第一种，读回全 F。pci_read_config_dword读 Vendor ID 得到0xFFFFFFFF。这个状态表示"这个 BDF 上没有设备响应配置请求"。原因可能是设备没上电、链路没训练起来、时钟没给、PERST# 没释放，也可能是总线号分配错了——软件以为在 bus 3 上，实际设备被枚举到了 bus 4。这种情况用lspci -t看一眼树形结构，再对照lspci -vv里桥的 secondary/subordinate，基本能定位。

第二种，UR 上报。设备在，配置空间读得到，但访问某个 BAR 地址时 AER 报 Unsupported Request。说明 TLP 走到了某个端口，那个端口查自己的窗口发现地址不在范围内，拒绝转发。这时候要去核对用户名下的 BAR 起始地址和沿途所有桥的窗口。

第三种，越界写导致内存踩踏。这个最危险，因为不一定报错。桥的地址窗口配置错误，TLP 不只没送到设备，反而落到了主存上——如果窗口配成了系统 RAM 所在的地址段，写操作就会直接改写内存内容，内核可能莫名其妙崩溃或者数据被污染。这种情况基本只会出现在自己手写枚举代码或者固件有 bug 的场景里，正常平台上不太会遇到。

第四种，第二块卡分不到资源。经典的"插一块好使，插两块就有一块不工作"。原因通常是父桥的窗口不够大，或者 32 位地址空间用尽。后者在有多块大显存设备或者大 BAR 网卡的机器上很常见，解决办法是开 Above 4G Decoding，把设备的高位 BAR 分配到 4GB 以上的地址空间去。这个在第六节还会展开。

3. ID路由：配置请求和Completion靠BDF定位

3.1 Type 0 和 Type 1 的分水岭在哪

地址路由看地址，ID 路由看的是 TLP 头里的目标 BDF。这一类里最重要的是两种事务：配置请求和Completion。

配置请求分 Type 0 和 Type 1。区别在于：Type 0 表示"目标设备就在我这条总线上"，收到它的设备应该直接处理，不再往下转发；Type 1 表示"目标设备在我下面某条总线上"，收到它的桥需要判断要不要往下转。

判断逻辑很明确。一个桥收到 Type 1 配置请求，取出里面携带的 Bus Number，跟自己的Secondary Bus Number和Subordinate Bus Number比较：

• 如果Bus == Secondary，说明目标设备就挂在这个桥的下一级总线上，桥把 Type 1 转换成 Type 0 发出去；
• 如果Secondary < Bus <= Subordinate，说明目标在更下面，桥原样转发 Type 1；
• 如果Bus不在这个范围内，桥不转发，这个请求往上走或者被丢弃。

这个逻辑解释了为什么"总线号必须连续分配"——Subordinate 是一个上界，它假设下面所有总线号都在Secondary到Subordinate之间连续排列。如果枚举时分配得不连续，比如某个桥下面分了 5、7 两条总线，中间空着 6，那 Subordinate 就得写 7，桥在判断 bus 6 的时候会误以为是自己下面的，但实际上那是个空号。功能上不一定出错，但会让排查变复杂。内核对这一点是有约束的，pci_scan_bridge_extend里分配总线号时就是按连续的方式往下发的。

3.2 枚举时总线号是怎么分出来的

pci_scan_bridge_extend()在drivers/pci/probe.c里，逻辑大致是这样：先读桥的Primary/Secondary/Subordinate三个寄存器，判断这个桥下面是否已经被固件枚举过。

如果Secondary是 0 或者Secondary <= Primary，说明下面还没枚举，内核就从当前总线往后分配一个新的总线号给它，写进 Secondary，然后递归pci_scan_child_bus去扫这条新总线。扫完之后，把这条总线下面所有设备用到的最大总线号回填到 Subordinate。

如果Secondary已经有效（固件枚过举了），内核就直接按已有的总线号范围往下扫，不再重新分配。

这里有个常被忽略的坑：Switch 的 Upstream Port 和 Downstream Port 共享同一个物理设备的配置空间，但软件看到的两个 BDF 是不同的——Upstream Port 挂在上一级总线上，Downstream Port 对应一条新的总线。这就是为什么你在lspci -t里能看到 Switch 下面"凭空"多出一条总线的原因。如果你在做虚拟化或者自己写枚举代码，这一点必须处理对，否则整个下游子树都扫不到。

3.3 Completion和Tag：ID路由的反向路径

PCIe 的所有非Posted事务（读请求、IO 写、配置写）都是拆分事务：Requester 发出请求就完事，Completer 稍后发一个 Completion 回来。Completion 怎么找回 Requester？靠的就是 ID 路由的反向使用——Completion 头里带着Requester ID（也就是发起者的 BDF）和Tag。

Requester ID加上Tag（8 位，开启 Extended Tag 后 16 位）唯一标识一个未完成的事务。Requester 这边维护一张未完成事务表，收到 Completion 就按这两个字段查表匹配。匹配不上就是"Unexpected Completion"，也是一个 AER 错误类型。

这套机制带来一个值得注意的约束：同一个 Requester 同时能挂起的非Posted事务数量受 Tag 数量限制。8 位 Tag 最多 256 个并发，16 位就是 65536。如果驱动里疯狂并发发起读请求（比如用一个循环连续readl而不等结果），有可能把 Tag 用完，后面的请求会被阻塞。当然普通 MMIO 读是 CPU 直接发起的，CPU 和 Root Complex 内部有自己的限制机制，一般不会到这一步；但在用 DMA 或者自己写硬件发起请求的场景下，这个限制是真实存在的。

还有一个相关概念是Completion Timeout。Completer 迟迟不回 Completion，等够时间后 Requester 会报 Completion Timeout 错误，默认行为可能是重试几次然后放弃并上报。如果设备被热拔了、或者下游链路断了，就会看到这个错误。排查的时候注意区分：Completion Timeout 说明请求发出去了但没回应；UR 说明请求被中间某个端口拒了。两者的方向完全不同。

3.4 访问配置空间的两条通道

ID 路由最典型的应用场景就是读配置空间，而访问配置空间在 x86 上有两条路。

第一条是传统的IO 端口法：往0xCF8写一个 32 位值，格式大概是bit31=1、bit[23:16]=Bus、bit[15:11]=Device、bit[10:8]=Function、bit[7:2]=寄存器偏移；然后从0xCFC读或者写数据。这条路的问题很明显：每次只能访问 32 位，而且必须串行——写地址、读数据这两步之间不能被打断，多核并发访问需要加锁。内核里对应pci_conf1_read/write，在arch/x86/pci/下。

第二条是ECAM（Enhanced Configuration Access Mechanism），也叫 MMCONFIG：把一段物理内存地址映射成配置空间，地址由(Bus << 20) | (Device << 15) | (Function << 12) | Offset算出，直接readl/writel就能访问。速度快、支持并发，而且能访问 4KB 的完整扩展配置空间（传统的 IO 端口法每次只能到 256 字节，访问扩展配置需要额外操作）。

ECAM 的基址来源在 x86 上是 ACPI 的MCFG表，Linux 启动时pci_mmcfg_arch_init会解析这张表，把每段 ECAM 地址范围注册进pci_mmcfg_list。较新的 ACPI 版本支持_CBA方法，让 Root Bridge 动态给出 ECAM 基址，用于支持热插拔的 host bridge。

两条通道在内核里通过struct pci_ops抽象，pci_bus_read_config_byte这些接口最终会调到pci_root_ops->read。ECAM 可用时优先用 ECAM，不可用时回退到 IO 端口法，pci_dev->cfg_size会相应变成 256 或 4096。判断当前用的是哪条路，dmesg | grep -i "MMCONFIG\|ECAM"一般能看到。

4. 隐式路由：Message请求靠MsgCode自己找路

4.1 没有地址也没有BDF，那靠什么

Message 这一类事务的特殊之处在于：它既不带目标地址（地址字段位置被Message Code占用了），也不带目标 BDF，只有一个MsgCode和一个Route编码。投递方向完全由硬件按规范约定处理。

Route编码大致有这么几类语义：送到 Root Complex、按地址、按 ID、从 Root Complex 向下广播、在接收端就地终止、汇聚到 Root Complex。不同版本的规范在具体比特编码上有调整（比如早期版本里"送到 Root Complex"的编码位置和后期版本不一样），所以如果你在写底层代码，一定要对着手上那个版本的规范表来，不要凭记忆填。

软件在这里的角色不是"配置路由"，而是"理解哪类消息会走到哪，然后准备好接收"。这是隐式路由和另外两种最大的区别。

4.2 几类必须认识的Message

按使用频率排，驱动作者最常打交道的是下面这几类。

INTx 中断消息。Assert_INTA 到 Deassert_INTD 一共 8 个 MsgCode，用于传统 PCI 中断在 PCIe 上的模拟投递。设备拉中断线时发 Assert，释放时发 Deassert，方向都是往 Root Complex。这类消息最终会被转换成系统中断（x86 上通常是某个 IOAPIC 的 GSI，或者被转成 MSI 处理），这也是为什么很多设备的 INTx 明明"是中断"却表现为一条 Message。

电源管理消息。PM_PME 用来请求唤醒，PME_Turn_Off 和 PME_TO_Ack 用于电源状态切换时的握手，PM_Active_State_Nak 用于 ASPM 协商。PME 这条链路是很多"设备插着但系统唤不醒"问题的根源。

错误消息。ERR_COR、ERR_NONFATAL、ERR_FATAL 三个级别，用来把设备的错误状态往 Root Complex 上报。这几个消息跟 AER（Advanced Error Reporting）机制配合，是排查硬件错误的主要信息源。

厂商自定义消息。MsgCode 在0x7E附近的一段是留给厂商的，实际用途包括 DPC 触发、LTR（Latency Tolerance Reporting）消息、ATS Invalidation 等等。这些通常不需要驱动直接处理，由内核的对应子系统接管。

4.3 Root Complex收到消息之后交给谁

这一步是隐式路由的最终落点，也是很多问题暴露的地方。

INTx 消息在 Root Complex 上被转换成中断控制器的一个输入，内核这边就是普通的request_irq。如果你的驱动用pci_alloc_irq_vectors拿了 MSI/MSI-X，就完全不走这条路；但如果设备只支持 INTx，或者 MSI 分配失败回退了，那中断路径上就一定要保证 INTx 消息能正确到达。

PME 消息的处理在drivers/pci/pcie/pme.c里，pcie_pme_work_fn会遍历下游设备、读 PME Status 位、调对应的回调。如果你写过带唤醒功能的驱动，pci_enable_wake和device_set_wakeup_enable设置的东西最终就是在这一层生效的。

AER 错误消息的处理在drivers/pci/pcie/aer.c，aer_isr收到中断后遍历各设备读错误状态寄存器，然后分类上报。这一路的信息在dmesg里就是形如pcieport 0000:00:01.0: AER: Corrected error received这样的日志。看日志的时候重点看Corrected、Non-Fatal、Fatal三个级别，以及后面的TLP Header打印——那里面直接给出了出错事务的地址或者 BDF，是定位路由问题最直接的证据。

5. 路由出问题时，按这个顺序往下查

5.1 第一步永远是分清"看不见设备"和"看见了但走不通"

这两类问题的排查方向完全不同，混在一起查会浪费大量时间。

判断方法很直接：lspci -s <BDF>能不能列出来。列不出来就是枚举阶段的问题，往链路训练、电源、时钟、复位方向查；能列出来但访问异常，才是路由或者资源分配的问题。

如果设备不在预期的 BDF 上，用lspci -t看整棵树的形状，再对照lspci -vv里每个桥的Bus: primary=XX, secondary=YY, subordinate=ZZ三个值，看总线号分配是否符合预期。我遇到过一次是某个桥的 Subordinate 被固件写成了 0，导致内核认为它下面没有总线，整个下游子树都没扫——lspci -t上看就是那个桥后面光秃秃的。

5.2 用/sys和/proc核对窗口是否真的覆盖住了BAR

设备能列出来之后，下一步核对地址窗口。三个地方要看：

/sys/bus/pci/devices/0000:xx:yy.z/resource文件里每一行是一个 BAR，格式是start end flags，flags里的0x...200表示 memory、0x...400表示 prefetchable、0x...100表示 IO。

/proc/iomem能看到整条 PCI 总线占用的地址范围和每一段被哪个设备 claim 了。如果某个 BAR 的起始地址在/proc/iomem里找不到对应的 PCI Bus 段，说明它落在了一个没人管的地址区间，TLP 发出去必然被拒。

桥的窗口用setpci直接读配置头最直观。比如读 00:01.0 的 Memory Base/Limit：

setpci -s 00:01.0 20.l

输出一个 32 位值，低 16 位是 Base（高 16 位有效，需要左移 16），高 16 位是 Limit（同样左移 16 再或上0xFFFFF）。IO 窗口对应偏移0x1c，prefetchable 对应0x24，高位对应0x28和0x2c。

把设备 BAR 的起始地址和大小，跟沿途所有桥的窗口逐一比对，只要有任何一个桥的窗口不包含它，路由就是断的。这个比对过程手动做比较枯燥，我一般写个小脚本遍历/sys/bus/pci/devices/*/，把每个设备的 BAR 和它父总线的窗口打出来对照。

5.3 AER日志里藏着出错TLP的原始信息

如果设备能访问一部分地址，另一部分报错，那就去看 AER 日志。

dmesg | grep -iE "aer|corrected|unsupported"

Unsupported Request表示某个端口拒了这个 TLP，通常就是窗口不覆盖。Completer Abort是设备自己拒了，可能地址不在设备的 BAR 范围内。Malformed TLP是包头格式有问题，自己拼包的场景下才会遇到。Completion Timeout上面说过了，是没回应。

AER 日志里那段TLP Header十六进制 dump 非常有价值，可以解析出Fmt、Type、Requester ID、Tag、地址。我习惯把这几个字段解出来，然后拿地址去跟窗口比、拿 Requester ID 去确认是哪个设备发起的，基本上两个字段就能把范围缩小到具体某条链路。

5.4 两个实际排查记录

案例一：Switch 后面挂多块卡，第二块 BAR 分配失败。

现象是lspci能看到两块卡，但第二块的 BAR 全是 0，/sys/.../resource里显示start=0 end=0。查 Switch 上游端口的 prefetchable 窗口，只有 256MB，而两块卡各要 128MB prefetchable，加上对齐要求之后第二块放不下了。

处理思路是让内核重新分配：加pci=realloc启动参数，让pci_assign_unassigned_resources重新算窗口。但这样做之后发现上游端口的 prefetchable 窗口最大值受限于它上一级（Root Port）给出的范围，还是不够。最终的解决办法是在固件阶段就把这个 Root Port 的 prefetchable 窗口配大，或者在设备树里把ranges的范围放宽。这件事让我记住一条：资源不足的时候，往上找一层，问题往往在更上游的桥。

案例二：64 位 BAR 落在了 CPU 访问不到的地址段。

现象是驱动ioremap成功、readl不报错，但读回来的全是0xFFFFFFFF。查/proc/iomem发现这个 BAR 的地址落在PCI Bus 0000:00这一大段里，看起来正常。再看 Root Bridge 的窗口，发现它只覆盖了低 4GB 的一部分，而这块设备的 64 位 BAR 被分到了 4GB 以上——地址在 PCI 域里是合法的，但 Root Complex 没有把它映射到 CPU 可访问的地址空间。

这类问题在 ARM64 平台上尤其容易出现，因为dma-ranges的映射关系决定了哪些 PCI 地址能真正到达 CPU。x86 上有 Above 4G Decoding 开关也是同样道理。解决办法不是改驱动，而是把平台的地址映射范围配全。

6. 写驱动时跟路由相关的几处坑

6.1 BAR尺寸和对齐不是你想要多大就多大

设备的 BAR 大小由硬件决定，软件只能读不能改。探测方法是往 BAR 写全 1，再读回来，读到的值取反加一就是大小。这个操作有风险——它会覆盖 BAR 原来的值，所以必须先把原值存下来，探测完写回去，而且要确保设备此时没有被驱动使用。

pci_resource_len()拿到的是内核探测后记录的大小，这个值在枚举阶段就已经算好了，驱动直接用就行，不要自己去写全 1 探测。我见过有人在probe里自己写全 1，结果把固件已经分配好的地址搞坏了，后续所有访问全错。

对齐方面，BAR 大小是 2 的幂，起始地址必须按大小对齐。这个约束是硬件保证的，你在设计设备端的时候就要考虑好，别在 FPGA 上搞一个 3MB 的 BAR——它会被向上取整成 4MB，白白浪费地址空间。

6.2 Prefetchable和non-prefetchable不能乱标

BAR 的flags里那个 prefetchable 位，含义是"这块内存被读的时候没有副作用，可以预取、可以合并、可以乱序"。很多人在 FPGA 上做设备的时候图省事，把控制寄存器区也标成 prefetchable，结果就是 CPU 的预取逻辑会去读那些"读一下就会清零"的寄存器，状态全乱。

判断标准很清晰：只要是带读清零、读递增指针、FIFO 弹出这类副作用的寄存器，就必须标成 non-prefetchable。只有纯粹的存储区（比如设备上的 DDR、大块数据缓冲）才标 prefetchable。这个标志标错了不会立刻报错，而是表现为"偶发数据错乱"，排查起来非常痛苦。我在一个采集卡项目上就踩过这个坑，最后是靠抓 PCIe 分析仪才定位到的。

6.3 IO BAR尽量别用

IO 空间的总量在 x86 上非常有限，16 位寻址只有 64KB，扩展之后也就 64KB 到 4GB 之间一小段，而且很多平台根本不给分配。新设计设备的时候一律用 Memory BAR，IO BAR 只在兼容老设备的时候才考虑。

如果确实遇到了只有 IO BAR 的设备，注意 IO 窗口的粒度是 4KB，而 IO BAR 最小可以到 4 字节，所以对齐上会很浪费。另外访问 IO 空间要用inb/outb这一套（内核里是inb()、outb()或者ioremap之后用readb），不能用普通的readl/writel去访问内存映射的地址。

6.4 上游桥窗口不够时，先看能不能挪，再考虑重分配

设备 BAR 分配不上的时候，处理顺序建议是这样：

先看能不能用resource_alignment参数调整对齐和大小，让内核把它挪到一个更合适的位置：

pci=resource_alignment=00:02.0;8M

这个参数可以在不改硬件设计的前提下解决一部分"位置不合适"的问题。

不行的话再考虑pci=realloc，让内核重新分配整个树。要注意这个操作会改动固件已经配好的东西，在某些平台上可能引发其他设备异常，属于有风险的操作，生产环境慎用。

最后才考虑改固件或者改硬件设计。从工程角度看，最好是在设计阶段就把窗口需求算清楚，别等到调试阶段才发现不够。

6.5 DMA和路由是两回事，但经常一起出问题

地址路由管的是 CPU 访问设备（MMIO）这条方向，DMA 是设备访问内存的反方向。两者用的机制不一样：MMIO 路由靠桥的窗口寄存器，DMA 靠设备发出的 Memory Write TLP 里的目标地址，那个地址由驱动通过dma_map_*系列接口拿到。

如果平台上有 IOMMU，DMA 地址还要经过一层地址转换，这时候驱动拿到的dma_addr_t和设备实际写出去的 PCI 地址不是同一个值。这种情况下如果出现 DMA 数据不对，先确认dma_map返回的地址和 IOMMU 的映射窗口是否匹配，别一头扎进 PCIe 路由里查——方向不对。

判断方法很简单：MMIO 读写正常但 DMA 数据错，问题在 DMA 这一侧；MMIO 读写就不正常，才往路由方向查。这个二分法能省掉大量时间。

7. 最后说几句我在实际项目里的体会

PCIe 路由这三块内容，刚接触的时候最容易犯的错是"只记结论不记判据"。比如记住了"配置请求看 BDF"，但没搞清楚 Type 0 和 Type 1 的转换时机，遇到 Switch 后面的设备枚举不出来就完全没思路。真正管用的做法是拿一张纸，把自己平台的拓扑画出来，每个桥的 Primary/Secondary/Subordinate、每组窗口的 Base/Limit 都标上去，然后拿一个具体的访问地址，模拟一遍它从 CPU 出发经过哪些端口、每个端口怎么判断。画过两三次之后，这套逻辑就变成条件反射了。

另外一个很实用的习惯是：改任何跟资源分配相关的启动参数之前，先把当前的/proc/iomem和所有桥的配置头 dump 一份存下来。这类问题经常是改了之后现象变化了，但说不清是变好还是变坏，有基线对比就清楚多了。我做板级调试的时候会写一个小脚本，一次性把lspci -vvv、/proc/iomem、/sys/bus/pci/devices/*/resource全抓下来存成带时间戳的目录，出问题的时候直接 diff 两个状态，比人肉回忆靠谱得多。

还有一点是关于隐式路由的：这类问题最容易被忽略，因为它不体现在任何寄存器的配置上。中断不响、唤醒失效、错误报不上来，很多人第一反应是查驱动，其实应该先看dmesg里有没有 AER 或者 PME 相关的记录，确认消息这一路是不是通的。把这条链路当成一个独立的排查维度，而不是附属于中断子系统，思路会清晰很多。