企业官网建设流程全解析

1. 先说清楚：PCI 和 PCIe 到底是什么

1.1 从总线的角度理解 PCI/PCIe

做 Linux 驱动的人，几乎绕不开 PCI/PCIe。不管是网卡、显卡、NVMe 硬盘，还是各种加速卡，到了 Linux 里基本都挂在一棵 PCI 总线上。你天天用 lspci 看到的那一堆设备，就是内核通过 PCI 枚举机制从总线上扫出来的。

PCI（Peripheral Component Interconnect）是上世纪九十年代确立的并行总线标准，而 PCIe（PCI Express）是它的串行替代方案。两者在软件模型上是高度兼容的，Linux 内核里甚至共用同一套驱动框架和配置空间访问逻辑，这也是为什么你现在写一个 PCIe 设备的驱动，用的还是struct pci_driver这套老接口——底层协议变了，但寄存器和枚举方式保持了延续性。

类比一下：PCI 总线就像一条多车道的并行公路，所有设备共享同一组数据线；PCIe 则是点到点的专用“高速通道”，每个设备都有自己的独立链路（Link），不用再跟别人抢线。所以 PCIe 的带宽是独享的，理论速率从 2.5GT/s（Gen1）一路涨到 32GT/s（Gen5），每个 lane 的速率翻倍，lane 数还可以从 x1 拼到 x16。

但注意，PCIe 虽然带宽高，它的配置空间访问方式跟传统 PCI 基本一致，依然是基于 Bus/Device/Function（BDF）三层地址来定位设备。这一点对驱动开发人员特别重要，因为你调试的时候，满眼都是0000:3b:00.0这种 BDF 字符串。

1.2 配置空间：驱动和硬件的“握手协议”

PCI/PCIe 设备上电后，硬件里有一块固定区域叫配置空间（Configuration Space），标准大小是 256 字节，PCIe 还扩展了 4KB 的增强配置空间（也就是存 AER 能力、链路状态这些的地方）。内核访问配置空间，不靠内存映射，而是靠 I/O 端口 0xCF8/0xCFC（传统 PCI 方式）或者 ECAM（Memory-Mapped Configuration，PCIe 主流方式）。

配置空间里最重要的几个字段：

驱动匹配设备靠的就是 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 个 BAR（Base 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 开始递归扫描。扫描的流程大致是：

1. 对每个 Bus 上的每个 Device 的 Function 0，读取 Vendor ID。如果读到 0xFFFF，说明该位置没有设备。
2. 如果 Vendor ID 有效，再读 Device ID、Class Code、Header Type 等，填充struct pci_dev。
3. 如果 Header Type 表明这是一个 PCI-PCI 桥（bit7 为 1），而且桥的次级总线号有效，就递归扫描下游总线。
4. 扫描完成后，统一做资源分配——遍历所有设备的 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 的窗口。

判断方法很简单，看 dmesg：

pci 0000:02:00.0: can't 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在资源分配失败的时候可能失败或者部分失败，驱动里要有错误分支，不能盲目认为设备一定可用。除此之外，pci=realloc内核参数可以强制内核重新分配桥窗口，有时能临时解决问题，但不是所有平台都支持，只能作为应急手段。

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_init+module_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 与电源管理：容易被忽视的收尾

很多人写驱动只重视 probe，remove 随便写两行就完事。但实际上，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 卡，不用关机就能换硬件。按实现方式分，主要有三种：

1. 原生 PCIe 热插拔：基于 PCIe 插槽的 Presence Detect 和 Attention Button 机制，由内核pciehp驱动处理。
2. ACPI 热插拔：主要是笔记本和部分服务器平台，由 ACPI 方法控制电源和插槽状态，对应内核的acpiphp驱动。
3. SHPC（Standard Hot-Plug Controller）：老式 PCI 热插拔标准，现在基本被前两种取代。

对驱动开发者来说，不用特别关心底层是哪种热插拔实现，因为内核对外暴露的接口是一样的：设备拔掉时触发 remove，插上时触发 probe。你的驱动只要 remove/probe 写得规范，热插拔就能正常工作。

4.2 内核热插拔处理流程

以原生 pciehp 为例，整个流程是这样的：

1. 物理插槽上，插入卡后，槽位的 Presence Detect 信号发生变化。
2. pciehp 驱动检测到变化，往内核发出一个 “slot event”。
3. 内核通过pciehp_ist中断服务线程处理事件，读取槽位状态寄存器。
4. 如果是插入事件，内核会触发总线重新扫描（pci_scan_slot/pci_bus_add_devices），新设备被枚举出来。
5. 新设备枚举完成后，内核会按照 id_table 匹配驱动，触发 probe。
6. 如果是拔出事件，内核先走设备移除流程（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, DRSupported

LnkCap是链路能力（capability），LnkSta是当前状态（status）。如果LnkSta显示的 Speed 或 Width 低于LnkCap，说明链路训练降级了。比如能力是 x8，当前只有 x1，那性能就剩八分之一。常见原因是接触不良、信号完整性差、或者 PCIe 链路训练时协商失败导致降级。

如果是热插拔设备，插拔后链路状态恢复不了，还可以尝试：

echo 1 > /sys/bus/pci/slots/3/power

重新上下电，强制链路重新训练。不过这个操作要看平台是否支持 slot power 控制。

5.2 AER 错误怎么读

AER（Advanced 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: severity=Corrected, type=Transaction Layer, (Requester ID) pcieport 0000:00:1c.0: device [8086:9d10] error status/mask=00000000/00002000 pcieport 0000:00:1c.0: [ 0] Receiver Error

这里有几个关键信息：

• severity：Corrected（可修正）还是 Fatal（致命）。
• type：错误发生在哪一层——Transaction Layer、Data Link Layer 还是 Physical Layer。
• device [8086:9d10]：出错的设备 ID。
• 错误状态位：每个位对应一种具体错误类型。

常见错误位含义如下：

对驱动开发者来说，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 平台可以开iommu=pt看是不是 DMA 地址问题，或者干脆先用intel_iommu=on强制走 IOMMU，如果问题消失，那就是 DMA 地址配置有误。当然这只适用于调试环境，生产环境要按实际需求配置。

这个方向后续可以扩展的还很多，比如 MSI-X 多队列中断的分配策略、SR-IOV 虚拟化支持、PCIe AER 错误注入测试（aer-inject）、以及用户态的vfio-pci直通。每块内容都能再写一篇长文。如果你正在做 PCIe 设备驱动，先把本文的框架梳理清楚，剩下的就是拿着硬件手册一个寄存器一个寄存器地啃了。