1. 先说清楚PCI 和 PCIe 到底是什么1.1 从总线的角度理解 PCI/PCIe做 Linux 驱动的人几乎绕不开 PCI/PCIe。不管是网卡、显卡、NVMe 硬盘还是各种加速卡到了 Linux 里基本都挂在一棵 PCI 总线上。你天天用 lspci 看到的那一堆设备就是内核通过 PCI 枚举机制从总线上扫出来的。PCIPeripheral Component Interconnect是上世纪九十年代确立的并行总线标准而 PCIePCI Express是它的串行替代方案。两者在软件模型上是高度兼容的Linux 内核里甚至共用同一套驱动框架和配置空间访问逻辑这也是为什么你现在写一个 PCIe 设备的驱动用的还是struct pci_driver这套老接口——底层协议变了但寄存器和枚举方式保持了延续性。类比一下PCI 总线就像一条多车道的并行公路所有设备共享同一组数据线PCIe 则是点到点的专用“高速通道”每个设备都有自己的独立链路Link不用再跟别人抢线。所以 PCIe 的带宽是独享的理论速率从 2.5GT/sGen1一路涨到 32GT/sGen5每个 lane 的速率翻倍lane 数还可以从 x1 拼到 x16。但注意PCIe 虽然带宽高它的配置空间访问方式跟传统 PCI 基本一致依然是基于 Bus/Device/FunctionBDF三层地址来定位设备。这一点对驱动开发人员特别重要因为你调试的时候满眼都是0000:3b:00.0这种 BDF 字符串。1.2 配置空间驱动和硬件的“握手协议”PCI/PCIe 设备上电后硬件里有一块固定区域叫配置空间Configuration Space标准大小是 256 字节PCIe 还扩展了 4KB 的增强配置空间也就是存 AER 能力、链路状态这些的地方。内核访问配置空间不靠内存映射而是靠 I/O 端口 0xCF8/0xCFC传统 PCI 方式或者 ECAMMemory-Mapped ConfigurationPCIe 主流方式。配置空间里最重要的几个字段字段偏移作用Vendor ID / Device ID0x00 / 0x02驱动匹配设备的“身份证”Command / Status0x04 / 0x06控制 IO 使能、内存使能、总线主控等Class Code0x09设备类型网卡、显卡、存储控制器等BAR0 ~ BAR50x10 ~ 0x24设备地址资源窗口的基址寄存器Capabilities 指针0x34指向能力链表PM、MSI、PCIe cap 等Interrupt Line / Pin0x3C / 0x3D传统中断路由信息驱动匹配设备靠的就是 Vendor ID Device ID 组合或者可以用 Class Code 做通配。你在驱动里写static const struct pci_device_id my_pci_ids[] { { PCI_DEVICE(0x1234, 0x5678) }, { } };内核就会拿这张表去跟枚举出来的设备的 Vendor/Device ID 逐一比对。匹配成功才会调用你的 probe。这块后面详说。配置空间里还有一个非常关键的机制叫Capability 链表。PCIe 的 MSI/MSI-X 中断、电源管理、AER 错误报告、热插拔等高级功能全部通过 Capability 结构暴露。驱动和内核工具就是沿着这个链表找到对应的能力寄存器。如果你在调试的时候发现某个功能没生效先别怀疑驱动逻辑用lspci -vvv看看对应的 Capability 是否存在。1.3 地址资源BAR、MMIO 与 DMA设备要跟 CPU 通信无非两种途径一是寄存器访问二是 DMA 数据搬运。寄存器访问靠的是那 6 个 BARBase Address Register。BAR 里存的是设备想占用的地址空间大小和类型Memory 还是 IO内核在枚举阶段读取 BAR然后给它分配实际的物理地址区间。这里有个重要细节BAR 的大小不是直接读出来的而是先写全 1 再读回来根据哪些位被置 0 来推算地址空间大小。比如你往 BAR0 写 0xFFFFFFFF读回来是 0xFFFFF000说明低 12 位被硬件强制为 0那这个 BAR 的大小就是 4KB。这是 PCI 协议里最早期的“探测”技巧内核在 pci_size() 里干的活就是这个。分配完之后驱动在 probe 里要自己完成三件事pci_enable_device(pdev); // 使能 IO/内存/总线主控 pci_request_regions(pdev, mydev); // 请求占用 BAR 资源 ioremap(pci_resource_start(pdev, 0), size); // 把 BAR0 映射到虚拟地址我见过不少新手只调了pci_enable_device就急着去读写寄存器结果一访问就 oops或者读到全 0xFF。原因就是没做ioremap内核的虚拟地址空间里根本没有这块映射。反过来也有老手过度设计把pci_request_regions省略掉总觉得“内核又不会跟我抢”直到有一天设备跟别的驱动冲突才明白这个函数的意义——它是在资源管理器里“登记产权”避免两个驱动同时声称对同一段 BAR 的拥有权。DMA 那边稍微复杂一点。PCI 设备做 DMA内核里用dma_alloc_coherent()分配一致性内存或者用dma_map_single()/dma_map_sg()做流式映射。PCIe 设备默认走 64 位地址所以通常还要调一下 DMA 掩码dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));如果不设置内核默认按 32 位 DMA 处理碰到一些高端设备比如大数据量网卡就可能出现地址截断问题数据写到一半出错。这种问题在驱动里特别隐蔽因为不报错、只是数据不对。2. Linux 如何找到 PCI 设备2.1 枚举过程到底发生了什么很多做应用层开发的人第一次接触 PCI都会有疑问我没写任何代码为什么系统启动后lspci就能看到所有设备设备是哪来的答案是PCI 枚举是内核做的而且是在非常早的启动阶段完成的。x86 平台上内核通过 ACPI 拿到 PCI 总线的根信息然后从 Bus 0 开始递归扫描。扫描的流程大致是对每个 Bus 上的每个 Device 的 Function 0读取 Vendor ID。如果读到 0xFFFF说明该位置没有设备。如果 Vendor ID 有效再读 Device ID、Class Code、Header Type 等填充struct pci_dev。如果 Header Type 表明这是一个 PCI-PCI 桥bit7 为 1而且桥的次级总线号有效就递归扫描下游总线。扫描完成后统一做资源分配——遍历所有设备的 BAR计算需要的大小和地址对齐然后从根桥的地址窗口里逐个分配。这也就是为什么你经常在 dmesg 里看到类似下面这样的日志pci 0000:3b:00.0: [1234:5678] type 00 class 0x020000 pci 0000:3b:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] pci 0000:3b:00.0: BAR 0: assigned [mem 0xc8000000-0xc8003fff 64bit]第一条说明设备被发现第二条说明 BAR 的请求大小第三条说明内核最终分配的实际地址。这三行日志看明白了枚举机制也就懂了大半。2.2 lspci 与 sysfs把内核的“发现结果”读出来Linux 下查看 PCI 设备有个神级工具叫lspci。不加参数是简洁列表加-vvv是“恨不得把所有寄存器都告诉你”的详细模式加-x直接 dump 配置空间原始字节加-nn显示厂商/设备 ID 的数值形式。更底层一点的是 sysfs。每个 PCI 设备在/sys/bus/pci/devices/0000:3b:00.0/下有一整套属性文件vendor、device、class配置空间字段直接导出resource各 BAR 的资源范围irq当前分配的中断号enable写 1/0 可以手动使能或禁用设备driver_override强制指定绑定的驱动remove写 1 可以把设备从总线上逻辑移除热插拔模拟还有一个很实用的目录/sys/bus/pci/slots/对应物理插槽操作热插拔时经常用到。调试驱动时我习惯先在 sysfs 确认设备的资源情况再决定ioremap哪段地址。比如某个 BAR 在内核里显示是resource0那驱动里对应pci_resource_start(pdev, 0)。这里的数字是对应的别搞混了。2.3 资源分配失败一个常见的枚举坑我在实际项目里踩过一个比较经典的坑板卡上有四路 PCIe 设备系统起来后发现其中一路在 lspci 里时有时无偶尔直接消失。排查到最后发现是根桥的 MMIO 窗口不够了——四个设备每个要 64MB 的 BAR而根桥只分配了 128MB 的窗口。判断方法很简单看 dmesgpci 0000:02:00.0: cant claim BAR 0 [mem 0x00000000-0x03ffffff]: no compatible bridge window或者pci 0000:02:00.0: BAR 0: no space for mem resource遇到这种问题终极解法是 BIOS 里给根桥预留更大的窗口或者减少占用。驱动层面能做的有限但要注意一个细节pci_enable_device在资源分配失败的时候可能失败或者部分失败驱动里要有错误分支不能盲目认为设备一定可用。除此之外pcirealloc内核参数可以强制内核重新分配桥窗口有时能临时解决问题但不是所有平台都支持只能作为应急手段。3. PCI 设备驱动框架的核心实现3.1 struct pci_driver 与 ID 表Linux 下的 PCI 驱动框架非常成熟核心数据结构就一个 ——struct pci_driver。它的完整面貌如下struct pci_driver { const char *name; const struct pci_device_id *id_table; int (*probe)(struct pci_dev *dev, const struct pci_device_id *id); void (*remove)(struct pci_dev *dev); int (*suspend)(struct pci_dev *dev, pm_message_t state); int (*resume)(struct pci_dev *dev); void (*shutdown)(struct pci_dev *dev); ... };驱动的注册方式很简单static struct pci_driver mydrv { .name mydrv, .id_table my_pci_ids, .probe my_probe, .remove my_remove, }; module_pci_driver(mydrv);module_pci_driver是个宏展开后就是module_initmodule_exit分别调用pci_register_driver和pci_unregister_driver。如果你有额外的初始化逻辑也可以手动写_init/_exit函数。这里要强调一个点id_table 是驱动和设备之间的“姻缘线”。内核在枚举完设备后会在所有已注册的 pci_driver 里逐个查找是否有匹配的 ID。匹配顺序取决于驱动的注册顺序和 ID 表的条目顺序。如果你发现自己的 probe 没被调用十有八九是 ID 没对上——用lspci -nn查看真实 ID然后跟驱动里的做对比。3.2 probe 函数里该干什么probe 是驱动生命周期中最关键的阶段所有初始化都在这里完成。一个规范的 probe 流程大致如下static int my_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct my_dev *dev; int ret; // 1. 使能设备打开 IO/内存/总线主控 ret pci_enable_device(pdev); if (ret) return ret; // 2. 设置 DMA 掩码64 位设备要设置 ret dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)); if (ret) { dev_err(pdev-dev, DMA mask failed\n); goto err_disable; } // 3. 请求 BAR 资源 ret pci_request_regions(pdev, mydrv); if (ret) goto err_disable; // 4. 分配私有数据结构 dev kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) { ret -ENOMEM; goto err_regions; } // 5. ioremap 映射 BAR dev-bar0 ioremap(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0)); if (!dev-bar0) { ret -ENOMEM; goto err_free; } // 6. 初始化中断MSI 优先传统 INTx 兜底 ret pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI | PCI_IRQ_INTX); if (ret 0) goto err_unmap; // 7. 注册中断处理函数 ret request_irq(pci_irq_vector(pdev, 0), my_irq_handler, 0, mydrv, dev); if (ret) goto err_vectors; // 8. 其他业务初始化 // ... pci_set_drvdata(pdev, dev); return 0; err_vectors: pci_free_irq_vectors(pdev); err_unmap: iounmap(dev-bar0); err_free: kfree(dev); err_regions: pci_release_regions(pdev); err_disable: pci_disable_device(pdev); return ret; }注意最后那个pci_set_drvdata它把私有数据挂在pci_dev上后续的所有函数——比如中断处理、文件操作、remove——都可以通过pci_get_drvdata(pdev)拿回来。这是 PCI 驱动里最常见的数据传递方式。3.3 remove 与电源管理容易被忽视的收尾很多人写驱动只重视 proberemove 随便写两行就完事。但实际上remove 的质量直接决定模块能否安全卸载以及设备热插拔时系统会不会崩。remove 的标准流程是 probe 的逆序static void my_remove(struct pci_dev *pdev) { struct my_dev *dev pci_get_drvdata(pdev); free_irq(pci_irq_vector(pdev, 0), dev); pci_free_irq_vectors(pdev); iounmap(dev-bar0); pci_release_regions(pdev); pci_disable_device(pdev); kfree(dev); }这里有一个非常容易踩的坑中断处理函数可能正在运行。如果驱动里有任务比如工作队列、tasklet还在访问硬件直接 free_irq 和 iounmap 会导致内核崩溃。稳妥的做法是先设置一个dev-removing标志让中断处理函数检测到后直接返回再用synchronize_irq()等待正在执行的中断处理完最后才释放资源。电源管理方面标准 PCI 驱动要实现suspend和resume。suspend 里通常要做停止 DMA、保存关键寄存器状态、释放中断resume 里则反过来重新使能设备、恢复寄存器、重新注册中断。偷懒的做法是直接在 suspend 里调pci_save_state和pci_disable_device但如果你驱动里有 DMA 正在跑这个偷懒会带来数据损坏。3.4 字符设备与 PCI 驱动的结合很多 PCI 设备驱动最终会暴露一个/dev/mydrv字符设备给应用层访问。传统的做法是在 probe 里调用register_chrdev或者cdev_add。这里有一个重要的时序问题probe 完成前设备节点最好不要对外可见否则应用层可能在你初始化到一半的时候打开设备导致竞态。推荐的做法是probe 里分配好 cdev 和 device 号注册到内核真正的硬件初始化在 open 的时候做或者用状态机保证“设备未就绪时打开返回 -EAGAIN”。反过来remove 时要先删除设备节点再释放 cdev避免出现“设备已经拔了应用层还握着 fd 不放”的情况。另外如果你用 devtmpfs设备节点会自动出现在/dev/下前提是正确设置dev-devt和 class。这块细节比较多但核心思路就一句话字符设备和 PCI 设备是两个层面的东西PCI 驱动负责跟硬件通信字符设备负责跟应用层通信两者通过私有数据结构桥接。4. PCIe 热插拔从硬件到内核的配合4.1 热插拔的分类PCIe 热插拔Hot-Plug在实际数据中心里用得非常多——比如服务器上拔插 NVMe 硬盘、GPU 卡不用关机就能换硬件。按实现方式分主要有三种原生 PCIe 热插拔基于 PCIe 插槽的 Presence Detect 和 Attention Button 机制由内核pciehp驱动处理。ACPI 热插拔主要是笔记本和部分服务器平台由 ACPI 方法控制电源和插槽状态对应内核的acpiphp驱动。SHPCStandard Hot-Plug Controller老式 PCI 热插拔标准现在基本被前两种取代。对驱动开发者来说不用特别关心底层是哪种热插拔实现因为内核对外暴露的接口是一样的设备拔掉时触发 remove插上时触发 probe。你的驱动只要 remove/probe 写得规范热插拔就能正常工作。4.2 内核热插拔处理流程以原生 pciehp 为例整个流程是这样的物理插槽上插入卡后槽位的 Presence Detect 信号发生变化。pciehp 驱动检测到变化往内核发出一个 “slot event”。内核通过pciehp_ist中断服务线程处理事件读取槽位状态寄存器。如果是插入事件内核会触发总线重新扫描pci_scan_slot/pci_bus_add_devices新设备被枚举出来。新设备枚举完成后内核会按照 id_table 匹配驱动触发 probe。如果是拔出事件内核先走设备移除流程pci_stop_and_remove_bus_device触发驱动的 remove然后释放资源。在用户态你还能看到 udev 事件。比如插入一张网卡/sys/bus/pci/devices/目录下会多出一个设备目录同时 udev 会收到add事件触发相应的规则。这在服务器场景下很常见——你插入一块新网卡系统自动识别并配置 IP。4.3 热插拔场景下的驱动要求热插拔对驱动的核心要求就两个字干净。具体拆开来看一是 remove 必须是幂等的。设备拔出后寄存器访问会返回全 0xFF 或触发总线错误。如果你的 remove 里还去读写硬件寄存器轻则满脸错误日志重则卡死整个系统。我在实际项目里遇到过 remove 过程中读 BAR 寄存器导致整个 PCIe 总线完全挂死的情况最后只能重启。从那以后remove 里所有硬件访问前都检查dev-removing标志并且对错误返回值做宽容处理。二是要考虑并发。设备正在收 DMA 数据时被拔掉如果驱动没有在 remove 里先停 DMA、再释放缓冲区内核很有可能在dma_unmap的时候访问已经无效的地址导致 panic。稳妥的顺序是停业务 → 停中断 → 停 DMA → 释放资源。三是在 probe 中不要做太重的初始化。热插拔场景下probe 是在内核线程里执行的如果 probe 耗时过长比如固件加载卡住会阻塞整个热插拔流程。碰到硬件需要较长时间初始化的情况可以考虑把耗时操作放到工作队列里做probe 先返回成功后续状态通过 sysfs 或者状态位报告。5. 掉卡、降速、AER 报错的排查实战5.1 先看链路状态PCIe 设备出问题最常见的表象就是“掉卡”——lspci 里设备突然消失了或者是性能不对——明明 x8 的卡变成 x1 在跑。这些问题的根源绝大多数在物理链路上。Linux 下查看链路状态最直接的方式是lspci -vvv -s 3b:00.0重点看这一段LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L1, Exit Latency L0s unlimited LnkSta: Speed 8GT/s, Width x8, DRSupportedLnkCap是链路能力capabilityLnkSta是当前状态status。如果LnkSta显示的 Speed 或 Width 低于LnkCap说明链路训练降级了。比如能力是 x8当前只有 x1那性能就剩八分之一。常见原因是接触不良、信号完整性差、或者 PCIe 链路训练时协商失败导致降级。如果是热插拔设备插拔后链路状态恢复不了还可以尝试echo 1 /sys/bus/pci/slots/3/power重新上下电强制链路重新训练。不过这个操作要看平台是否支持 slot power 控制。5.2 AER 错误怎么读AERAdvanced Error Reporting是 PCIe 规范里的高级错误报告机制内核把它归集到pcieport驱动里。一旦链路出现可修正或不可修正错误内核会在 dmesg 里输出类似这样的日志pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0 pcieport 0000:00:1c.0: PCIe Bus Error: severityCorrected, typeTransaction Layer, (Requester ID) pcieport 0000:00:1c.0: device [8086:9d10] error status/mask00000000/00002000 pcieport 0000:00:1c.0: [ 0] Receiver Error这里有几个关键信息severityCorrected可修正还是 Fatal致命。type错误发生在哪一层——Transaction Layer、Data Link Layer 还是 Physical Layer。device [8086:9d10]出错的设备 ID。错误状态位每个位对应一种具体错误类型。常见错误位含义如下状态位含义[0] Receiver Error物理层接收错误信号质量问题[6] Bad TLP事务层收到损坏的 TLP 包[7] Bad DLLP数据链路层收到损坏的 DLLP[12] Timeout事务超时[13] Poisoned TLP收到带毒 TLP数据损坏标记对驱动开发者来说AER 日志最大的价值是帮你定位方向如果是 Receiver Error 满天飞大概率是信号完整性或链路问题跟驱动无关如果是 Bad TLP 或者 Completer Abort那可能是驱动地址映射或者 DMA 配置错误得查代码。5.3 排查流程与常见原因我在项目里积累了一套排查链路问题的流程简单分享第一步确认物理状态。重新插拔卡换插槽看问题是否复现。PCIe 掉卡问题有一半是物理接触不良尤其是服务器里长期运行的机器金手指氧化或插槽积灰是家常便饭。第二步看链路协商结果。用上面说的lspci -vvv查LnkSta确认速率和宽度有没有降级。如果能力 x16、实际 x1先怀疑硬件如果能力就显示 x1那就可能是 BIOS 配置或卡本身的问题。第三步看 AER 错误计数。系统运行一段时间后用ras-mc-ctl或直接看cat /sys/devices/pci0000:00/0000:00:1c.0/aer_dev_correctable如果 Correctable 错误快速增长说明物理链路不稳定。偶尔几个可修正错误不用太紧张PCIe 协议本身就允许通过重传恢复但大量增长就要处理了。第四步排除驱动因素。把设备驱动卸载看设备是否还在 lspci 里。如果驱动卸载后设备正常问题很可能在驱动对硬件的操作方式上——比如 DMA 地址错误、BAR 映射错位、中断处理不当导致的系统级故障。5.4 驱动层的处理策略有些 AER 错误确实是驱动造成的。最常见的是这三个场景一是 DMA 地址越界。驱动给设备传的 DMA 地址超出了设备支持的范围设备写内存时写到了错误的地方产生 Poisoned TLP。这类问题靠日志很难直接看出来建议在驱动里加 DMA 地址校验或者用 IOMMU 来兜底。二是中断处理时间长导致超时。如果中断处理函数里做了太多事链路层可能因为长时间没有响应而报 Timeout。对策是把耗时操作移到 tasklet 或工作队列里。三是访问了不存在的 BAR 空间。驱动里 ioremap 的地址范围超出设备实际提供的 BAR 大小访问时会触发 Unsupported Request 或 Completer Abort。用pci_resource_len确认大小别拍脑袋写死偏移。如果确实在驱动里发现了问题可以考虑用pci_err_recovery机制。内核提供了一套错误恢复流程当发生可恢复的不可修正错误时pcieport 会调用链路下游设备的error_detected、mmio_enabled、slot_reset、resume回调。驱动实现这几个回调就能在链路错误后自动恢复不用人工干预。不过这套接口依赖驱动配合如果你的驱动没实现设备只能走彻底移除路线。6. 实操总结与个人经验写到这里基本上 Linux PCI 设备驱动的主线内容都覆盖了。最后分享几个我在实际项目里反复验证过的经验希望能帮后来的人少踩几个坑。第一拿到新板卡第一件事先用lspci -vvv完整看一遍配置空间。不要急着写驱动先把设备的 BAR、能力、中断都搞清楚。很多时候硬件的默认配置跟你想的不一样提前发现能避免后期抓瞎。我见过有人按 datasheet 写死了寄存器偏移结果实际设备跟 datasheet 版本不一致debug 了三天最后发现是硬件版本差异。第二驱动的错误处理一定要完整。probe 里每一步都可能失败每一个 goto err 标签背后都是一段资源释放逻辑。很多稳定的商业驱动看起来“啰嗦”就是因为每一行失败分支都不放过。内核里资源是要求“谁申请谁释放”的漏掉任何一步模块卸载的时候就会给你颜色看。第三热插拔场景下一切的教训都指向 remove 要快、要干净。设备拔出后内核不会等你的 remove 慢慢跑。你要是 remove 里卡在等待硬件响应上整个系统的 PCIe 总线都可能被拖住。任何时候remove 里都不要做长时间等待硬件寄存器的操作。第四调试 DMA 问题的时候IOMMU 是你的好朋友。x86 平台可以开iommupt看是不是 DMA 地址问题或者干脆先用intel_iommuon强制走 IOMMU如果问题消失那就是 DMA 地址配置有误。当然这只适用于调试环境生产环境要按实际需求配置。这个方向后续可以扩展的还很多比如 MSI-X 多队列中断的分配策略、SR-IOV 虚拟化支持、PCIe AER 错误注入测试aer-inject、以及用户态的vfio-pci直通。每块内容都能再写一篇长文。如果你正在做 PCIe 设备驱动先把本文的框架梳理清楚剩下的就是拿着硬件手册一个寄存器一个寄存器地啃了。
