1. 项目概述为什么我们需要深入理解 pci.c 与 CXL Core如果你正在捣鼓 Linux 内核特别是涉及到最新的硬件特性比如 CXLCompute Express Link那么drivers/pci/目录下的pci.c文件绝对是一个绕不开的核心。尤其是在 Linux Kernel 6.0 这个版本CXL 支持从早期的探索阶段进入了更成熟、更核心的集成期。很多人可能觉得PCIe 驱动不是老生常谈了吗但 CXL 的引入让这个“老”框架焕发了“新”生机。pci.c作为 PCI 子系统最基础的通用驱动它不仅是所有 PCI/PCIe 设备初始化的起点更是 CXL 设备能够被内核识别、管理和使用的基石。简单来说没有pci.c里那套扎实的 PCI 枚举、资源配置和总线管理逻辑CXL 设备连“门”都进不来。这个项目的目的就是带你钻到 Linux Kernel 6.0 的源码里把pci.c中与 CXL Core 紧密相关的部分掰开揉碎了讲清楚。这不是一篇泛泛而谈的概述而是一次针对性的深度剖析。我们会聚焦于CXL 设备如何通过标准的 PCIe 配置空间被内核发现pci.c中的哪些关键函数为 CXL 驱动铺平了道路当内核遇到一个带有 CXL 能力的 PCIe 设备时pci.c和后续的cxl_core是如何分工协作的理解这个过程对于从事底层驱动开发、系统软件研发或者任何需要让新型硬件特别是像 CXL 这种兼具内存语义和IO语义的复杂设备在 Linux 上跑起来的工程师来说至关重要。它能帮你厘清内核的设备发现框架让你在调试“设备识别不了”、“资源分配失败”这类问题时有清晰的排查思路而不是盲目地四处试错。2. PCI 核心框架设备发现的通用引擎要理解 CXL 如何接入必须先搞清楚 Linux 内核的 PCI 子系统是怎么工作的。pci.c是这个子系统的“总控中心”它不针对任何特定设备而是提供了一套发现、枚举、配置所有 PCI/PCIe 设备的通用机制。2.1 初始化与总线枚举的入口内核启动过程中PCI 子系统的初始化由pci_init函数或通过subsys_initcall机制注册开始。但对于设备枚举的真正起点往往是从体系结构相关的代码如 x86 的pcibios_init调用pci_subsys_init开始的。这个过程中pci.c的核心任务之一是遍历系统中的所有 PCI 总线。关键函数是pci_scan_child_bus。这个函数会递归地扫描一条 PCI 总线上的每一个可能的设备位置由总线号、设备号、功能号唯一确定。对于每一个位置它通过pci_bus_read_dev_vendor_id发起 PCI 配置空间的读取操作。如果读回的厂商ID和设备ID是有效的非0xffffffff或0x00000000内核就认为这里存在一个真实的 PCI 设备。注意这里第一次硬件交互就发生了。如果设备没有正确响应或者配置空间访问路径如通过 ECAM有问题扫描就会失败。这也是为什么在调试新主板或定制硬件时首先要确认 BIOS/UEFI 里的 PCIe 设置和内核的 ECAM 映射是否正确。发现设备后内核会创建一个struct pci_dev对象来代表这个设备。这个结构体是内核中所有 PCI 设备操作的基石它包含了设备的配置空间信息、分配的资源内存、IO、中断、所属总线、以及一个非常重要的成员dev一个struct device对象。正是通过这个dev成员PCI 设备被挂接到了 Linux 统一的设备模型上从而与驱动模型、电源管理、sysfs 等子系统联动。2.2 资源配置的关键步骤仅仅发现设备是不够的设备要工作需要内存空间BAR、中断等资源。pci.c中的pci_setup_device和pci_read_bases函数负责读取设备的 PCI 配置空间解析出 Base Address Registers。每个 BAR 描述了设备需要的一块内存或 I/O 地址空间的大小和类型。更关键的一步是资源分配。在总线扫描完成后pci_assign_unassigned_resources函数会被调用。这个函数协调系统内所有 PCI 设备对资源的需求解决冲突并为每个设备的 BAR 分配合适的物理地址。分配好的地址会被写回设备的配置空间这就是所谓的“BAR 编程”。对于 CXL 设备尤其是 Type 3 内存扩展设备它的 BAR 可能指向一个巨大的、用于主机访问设备内存的窗口。这个窗口的分配是否成功、地址是否合理直接决定了 CXL 内存能否被系统使用。pci.c在这里扮演了资源“分配器”的角色它不关心这个 BAR 背后是网卡、显卡还是 CXL 内存它只遵循 PCI 协议规则进行分配。2.3 驱动匹配的桥梁pci_bus_type设备创建并配置好资源后就进入了驱动匹配阶段。内核定义了一个全局的pci_bus_type。每个 PCI 设备pci_dev-dev都会注册到这个总线类型上。同样每个 PCI 驱动包括我们后面要讲的 CXL 驱动都会通过pci_register_driver注册自己并提供一个id_table里面列出了这个驱动能支持的设备ID列表。当设备被添加到总线时内核的核心设备模型会遍历所有已注册的、属于pci_bus_type的驱动调用驱动的.match回调对于 PCI通常是pci_bus_match来比对设备ID。如果匹配成功就会调用驱动的.probe函数。这里有一个至关重要的细节pci.c提供的这个匹配机制是被动的。它不会主动去为某个设备寻找驱动而是当驱动注册时或者设备添加时触发一次匹配检查。这意味着CXL 驱动cxl_pci的加载时机非常重要。如果 CXL 设备先于驱动被系统发现那么设备会安静地躺在总线上等待驱动出现。如果驱动先加载那么当设备出现时驱动会立刻被匹配并执行probe。3. CXL 设备的特殊性与pci.c的应对CXL 设备首先是一个 PCIe 设备所以上述所有流程它都必须走一遍。但它又不是一个普通的 PCIe 设备。它在标准的 PCIe 配置空间基础上通过 PCIe 扩展能力PCIe Extended Capabilities机制添加了 CXL 特有的能力结构CXL Capability Structures。3.1 CXL 能力的发现与解析pci.c如何知道一个设备是 CXL 设备呢它自己并不直接“知道”。pci.c提供了一个通用的框架来遍历和发现 PCIe 扩展能力。这个逻辑主要在pci_find_next_ext_capability等函数中。内核在初始化设备时会调用pci_init_capabilities它会遍历设备配置空间中所有的扩展能力链表。当遍历到能力 ID 为PCI_EXT_CAP_ID_CXL这个常量在内核中定义的节点时pci.c的通用代码只是识别出“这里有一个 CXL 能力结构”但它并不解析其中的内容。解析工作是由后续的、专门的 CXL 驱动cxl_core来完成的。然而pci.c在这里做了一个关键动作它会将发现的 CXL 能力指针在配置空间中的偏移量保存在pci_dev结构体的某个字段中具体可能是一个私有数据区或者通过pci_dev-priv_flags等机制标记。这相当于给设备贴了一个“我是 CXL 设备”的标签方便后续的 CXL 驱动快速定位而无需重新扫描能力链表。3.2 对pci_dev的扩展cxl_dev_state这是 CXL 集成中最精妙的部分之一。一个 CXL 设备在内核中需要被两种视角看待PCI 视角作为一个 PCIe 端点设备需要管理其 BAR、中断、电源状态等。这是pci_dev的职责。CXL 视角作为一个 CXL 逻辑设备需要管理其 CXL 寄存器空间如 CXL 2.0 的组件寄存器、内存池、链路状态、主机管理的设备内存HDM等。这是 CXL 核心数据结构如cxl_dev_state的职责。那么如何将这两者关联起来内核采用了经典的“容器”模式。CXL 驱动如cxl_pci在它的probe函数中会为这个pci_dev分配并初始化一个cxl_dev_state结构体。这个结构体包含了所有 CXL 特定的状态和信息。然后通过dev_set_drvdata(pdev-dev, cxl_ds)这样的调用将cxl_dev_state的指针存储到 PCI 设备pdev-dev的驱动私有数据区中。从此以后在任何地方只要你能拿到这个pci_dev或其对应的struct device你都可以通过dev_get_drvdata()获取到与之关联的cxl_dev_state从而在 CXL 的上下文中操作设备。pci.c本身不关心这个私有数据是什么它只是提供了存储和获取这个指针的通用基础设施。3.3 资源管理的协同MMIO 与 HDMCXL 设备通常有两类重要的内存映射 I/O 区域PCI BAR 映射的区域用于传统的设备控制寄存器访问。这部分完全由pci.c和 PCI 核心管理通过pci_iomap、pci_read_config_dword等标准 API 访问。CXL HDMHost-managed Device Memory解码器窗口这是 CXL 内存的核心。主机 CPU 通过访问一段特定的物理地址范围由 HDM 解码器定义来读写 CXL 设备上的内存。这个地址范围的分配起始于 PCI 资源分配。具体来说CXL 设备的某个 BAR 可能被预编程或配置为指向 HDM 解码器相关的寄存器组。主机软件内核驱动通过配置这些寄存器将一段主机物理地址HPA空间与设备内存地址DPA空间映射起来。而为这个映射所保留的 HPA 空间其初始的、粗粒度的分配正是在 PCI 总线枚举时由pci.c中的资源分配逻辑完成的。CXL 驱动在此基础上进行更精细的划分和配置。这就好比pci.c负责划出一大块地皮分配一段大的物理地址空间然后 CXL 驱动在这块地皮上规划并建造具体的建筑设置多个 HDM 解码器窗口每个窗口对应不同的设备内存区间。4. 从pci.c到cxl_core驱动匹配与探测流程详解让我们跟踪一个 CXL 设备从硬件上电到内核驱动就绪的全过程看看pci.c和cxl_core是如何交接的。4.1 设备发现与pci_dev创建系统启动PCI 子系统初始化。pci_scan_child_bus扫描到 CXL 设备。它读取 Vendor ID 和 Device ID。假设这是一个由特定厂商如模拟器或真实硬件提供的 CXL 设备。内核创建struct pci_dev对象填充基本信息vendor, device, class 等。此时设备类别Class Code可能仍然是普通的存储类或其他类型因为 CXL 信息在扩展能力中。pci_setup_device被调用读取并解析标准配置空间包括 BAR。设备被添加到pci_bus_type上。此时在 sysfs 中你可以在/sys/bus/pci/devices/下看到这个设备例如0000:01:00.0但它还没有绑定任何驱动。4.2 CXL 能力识别与标记在 PCI 设备初始化链路的某个环节可能在pci_init_capabilities或类似的后续函数中内核的 PCI 通用代码会遍历扩展能力链表。当发现PCI_EXT_CAP_ID_CXL时它可能会执行类似下面的操作// 伪代码示意逻辑 int pos pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_CXL); if (pos) { // 将能力位置等信息存储起来例如设置一个标志位 pdev-is_cxl_device 1; pdev-cxl_cap_pos pos; }这个“标记”动作非常轻微它不解析 CXL 寄存器只是做个记录。真正的 CXL 驱动会依赖这个标记来快速判断设备类型。4.3 CXL PCI 驱动的匹配与探测CXL 子系统通常会提供一个基础的 PCI 驱动比如叫cxl_pci_driver。这个驱动在id_table中可能会使用比较宽泛的匹配条件甚至使用PCI_ANY_ID然后依靠.probe函数内的进一步检查来确认是否是真正的 CXL 设备。当cxl_pci.ko模块被加载时pci_register_driver(cxl_pci_driver)被调用。内核会立即遍历pci_bus_type上所有未绑定驱动的设备尝试匹配。对于之前发现的 CXL 设备此时就会发生匹配。驱动probe函数的典型工作流二次验证在probe中驱动首先会调用pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_CXL)确认设备确实具备 CXL 能力。这是双重保险。启用设备调用pcim_enable_device(pdev)。这个函数是pci.c提供的它会确保设备的 PCI 配置空间命令寄存器中的IO_ENABLE和MEMORY_ENABLE位被置位允许设备响应内存和 I/O 访问。这一步至关重要如果跳过后续对设备 BAR 空间包括 CXL 寄存器的读写都会导致系统错误如 MCE 或 PCIe Completion Abort。请求资源调用pcim_iomap_regions(pdev, BIT(bar_index), “cxl”)等函数将设备 BAR 指示的 PCI 内存区域映射到内核的虚拟地址空间。这样驱动就可以通过内存读写指令来访问设备的控制寄存器了。创建 CXL 核心上下文分配并初始化struct cxl_dev_state。这个结构体会保存从 CXL 能力结构中读取的关键信息如设备类型Type 1/2/3、寄存器基地址、能力集等。关联上下文dev_set_drvdata(pdev-dev, cxl_ds)。移交控制权调用 CXL Core 提供的 API例如cxl_pci_setup_mailbox、cxl_dev_state_identify等进一步初始化和配置 CXL 设备。至此控制权从通用的 PCI 驱动层移交到了专门的 CXL 核心层。4.4cxl_core的接手与高级管理cxl_core是 CXL 子系统的核心模块它不直接与硬件交互而是提供一套抽象的 API 和框架。当cxl_pci驱动完成基础硬件设置后它会向cxl_core“注册”这个设备。cxl_core负责设备枚举与拓扑构建CXL 设备可能形成层级如 Switchcxl_core负责理解并构建这个逻辑拓扑。内存池管理对于 CXL Type 3 设备cxl_core管理其作为内存扩展器的角色将设备内存暴露给内核的内存管理子系统。提供用户接口通过 sysfs如/sys/bus/cxl/devices/和字符设备如/dev/cxl/向用户空间暴露设备信息和控制接口。协调主机与设备内存交互管理 HDM 解码器处理内存访问的路径和协议转换。从pci.c的视角看它的工作到第 3 步驱动probe被调用就基本结束了。剩下的就是为 CXL 驱动提供稳定的 PCI 配置访问、资源管理、电源管理回调等基础设施支持。5. 实战调试当 CXL 设备无法识别时如何排查理解了上述流程当遇到“系统识别不到 CXL 设备”或者“CXL 驱动加载失败”的问题时你就可以进行有条理的排查了。以下是一个基于pci.c和 CXL 集成知识点的排查链条5.1 第一步确认 PCI 设备层是否可见这是最基础的检查。使用lspci -vvv命令。lspci -vvv -s 01:00.0 # 假设你的 CXL 设备在 01:00.0关键检查点设备是否存在命令是否有输出如果没有说明硬件连接、主板 BIOS 设置或 PCIe 根复合体配置可能有问题。Vendor/Device ID确认是否与你期望的硬件 ID 匹配。配置空间可读性lspci能正常显示所有配置空间字段吗如果出现大量ff或读取错误可能是 PCIe 链路训练失败、设备未正常上电或配置空间损坏。扩展能力列表在lspci输出的Capabilities部分必须能看到CXL字样。例如Capabilities: [a00] Compute Express Link如果看不到 CXL 能力那么内核的pci_find_ext_capability也找不到后续一切 CXL 相关的初始化都不会发生。这可能意味着设备固件未启用 CXL 能力或者你用的根本不是 CXL 设备。5.2 第二步检查内核 PCI 核心日志使用dmesg | grep -i pci或journalctl -k | grep -i pci查看内核启动和运行过程中 PCI 子系统的信息。查找是否有关于你的设备总线如0000:01:00.0的“扫描到”、“已启用”等信息。特别关注错误信息如BAR X: can‘t assign [mem/io]...资源分配失败、device not accessible访问失败等。这些错误直接来自pci.c中的函数是定位 PCI 层问题的关键。5.3 第三步检查 CXL 驱动绑定状态查看设备是否绑定了正确的驱动。ls -l /sys/bus/pci/devices/0000:01:00.0/driver如果指向/sys/bus/pci/drivers/cxl_pci说明驱动绑定成功。如果指向其他驱动如nvme如果设备也宣称自己是 NVMe说明发生了驱动绑定冲突。你需要检查 CXL 驱动的id_table优先级或者手动解除绑定再绑定。如果是一个“断链”符号指向自身说明没有驱动绑定。此时检查cxl_pci驱动模块是否加载 (lsmod | grep cxl)。驱动的id_table是否包含了你的设备 ID。在驱动probe函数中是否有其他检查失败如 CXL 能力验证失败导致驱动拒绝了该设备。这需要查看内核日志中来自 CXL 子系统的信息 (dmesg | grep -i cxl)。5.4 第四步深入内核源码添加调试打印如果以上步骤都无法定位你可能需要编译一个调试版内核或在关键函数中添加printk。pci.c侧的关键点pci_scan_slot/pci_scan_single_device看设备是否被扫描到。pci_setup_device看设备结构体创建是否成功。pci_init_capabilities看 CXL 扩展能力是否被找到并标记。pci_device_add看设备是否成功添加到总线类型。CXL 驱动侧的关键点cxl_pci_probe这是入口。在这里添加打印看是否被调用。pci_find_ext_capability的返回值。pcim_enable_device的返回值。pcim_iomap_regions的返回值。通常通过lspci确认 CXL 能力存在再结合内核日志中 CXL 驱动的probe入口打印和后续错误打印就能把问题定位到具体的函数调用失败上。6. 进阶pci.c中的钩子与 CXL 的定制需求随着 CXL 技术的演进一些高级特性可能需要pci.c提供更多的支持或定制点。虽然pci.c作为通用代码应保持稳定但它也通过一些机制预留了灵活性。6.1 电源管理回调的传递CXL 设备可能有复杂的电源状态如CXL.mem和CXL.io的独立电源管理。当系统进入睡眠S3/S4或 PCI 核心尝试切换设备电源状态时pci.c会调用pci_dev的driver-pm回调。CXL PCI 驱动可以实现这些回调如.suspend,.resume并在其中调用 CXL Core 的特定电源管理函数从而将 PCI 通用的电源管理事件传递到 CXL 特定的处理逻辑中。6.2 错误处理与 AER高级错误报告是 PCIe 的重要特性。pci.c集成了 AER 的初始化和错误检测框架。当 PCIe 总线或设备发生错误时pci.c中的错误处理例程会被触发。对于 CXL 设备除了标准的 PCIe AER还有 CXL 特定的错误状态寄存器在 CXL 能力结构中。理想的模式是pci.c处理通用的 PCIe AER 错误然后将控制权通过某种方式例如调用一个由 CXL 驱动注册的错误处理钩子传递给 CXL 驱动由后者去读取并处理 CXL 特定的错误日志。6.3 热插拔支持CXL 设备可能支持热插拔。pci.c提供了 PCI 热插拔的核心框架pci_hp。当用户在支持热插拔的槽位上插入 CXL 设备时硬件和 BIOS 会触发一个中断最终由pci.c中的热插拔控制器驱动调用pci_scan_slot来扫描新设备。后续的设备发现、驱动匹配流程和冷启动时完全一样。CXL 驱动需要确保其probe和remove函数是幂等且能安全处理热插拔场景的。7. 总结与个人经验体会扒完 Linux Kernel 6.0 中pci.c与 CXL Core 的交互细节我最深的体会是内核的优雅在于分层和抽象。pci.c完美地扮演了“基础设施提供者”的角色它把脏活累活总线扫描、资源配置、驱动匹配框架都干了并且干得极其稳定可靠。而像 CXL 这样的新特性则作为“上层建筑”只需要专注于自己领域的业务逻辑通过标准的 PCI 驱动接口和struct device模型就能无缝接入这个运行了数十年的庞大系统。在实际开发中这种理解能帮你省下大量时间。比如当你看到 CXL 内存初始化失败时你不会再盲目地去修改 CXL 代码而是会先问这个设备的 PCI BAR 分配成功了吗pcim_enable_device调用了吗配置空间能读吗很多时候问题就出在这些更底层、更通用的 PCI 环节。最后一个小技巧如果你想快速了解一个内核模块比如cxl_pci的依赖关系可以看它的Makefile和Kconfig。cxl_pci的Kconfig一定会select PCI并且depends on CXL_BUS。这从编译层面就反映了我们上面分析的软件栈层次CXL PCI 驱动依赖于通用的 PCI 子系统同时又是 CXL 总线框架的一部分。这种依赖关系正是内核模块化设计和层次化架构的直观体现。
