2. Intel CPU平台上的PCIe控制器：Root Complex与Endpoint的协同工作
咱们做PCIe DMA，光知道协议层还不够。你得先搞清楚Intel CPU这边，谁在管PCIe这件事。说白了，就是Root Complex（RC）和Endpoint（EP）怎么配合。
我刚开始接触这个的时候，以为只要把DMA描述符丢给设备就行了。结果板卡死活不工作，查了半天才发现是RC侧的配置没对上。从那以后，我习惯先把这两个角色的分工理清。
2.1 Root Complex——CPU侧的“PCIe总管家”
Intel CPU内部，PCIe控制器不是直接挂在核心上的。它通过一个叫Root Complex的模块连接CPU和PCIe总线。RC负责：
- 发起配置事务（Type 0/1配置读写）
- 管理地址翻译（IOMMU、VT-d）
- 处理中断（MSI/MSI-X）
- 转发内存/IO访问到PCIe设备
你想想看，CPU要访问一个PCIe设备，比如读它的BAR空间。这个请求先到RC，RC把它转成PCIe事务层包（TLP），再发到设备。反之，设备要写CPU内存（DMA写），也是通过RC把TLP转换成内存写事务。
lspci -vvv看RC的配置空间。Intel的RC通常出现在Bus 0, Device 0, Function 0。如果这里显示异常，下游设备基本没法正常工作。
2.2 Endpoint——PCIe局端的“功能实体”
Endpoint就是咱们要控制的PCIe设备，比如FPGA加速卡、NVMe SSD、专用DMA引擎。它有自己的配置空间、BAR空间、中断能力。作为工程师，我们通常关注：
- BAR（基地址寄存器）：决定设备在CPU地址空间中的映射窗口
- MSI/MSI-X能力：通知CPU事件（比如DMA完成）
- DMA引擎：设备内部的数据搬运逻辑
我遇到过一种坑：BAR空间不够大。比如你的FPGA需要映射128MB的DMA缓冲区，但BAR2只配置了64MB。结果地址写出去就挂了。所以设计阶段就得算好BAR大小。
2.3 RC与EP的协同工作流程
一个典型的DMA事务，RC和EP是这样配合的：
- CPU配置EP：通过RC写设备配置空间，使能总线主控、设置MSI地址
- CPU分配DMA缓冲区：申请一段物理连续内存，获取物理地址
- CPU下发DMA描述符：把源/目的地址、长度写到EP的内部寄存器（通过BAR映射的MMIO）
- EP发起DMA：EP作为PCIe主设备，发送Memory Write TLP到RC，写入CPU内存
- EP发送中断：DMA完成后，EP通过MSI通知CPU
- CPU处理完成：CPU确认数据可用，处理回调
注意：这里EP发起的写TLP，目的地址必须落在RC分配给它的PCIe域中。如果地址超出范围，RC会直接返回Unsupported Request（UR），DMA就废了。
2.4 常见配置陷阱与避坑
工作中我踩过的坑，列几个典型的：
| 现象 | 根因 | 解决办法 |
|---|---|---|
| 设备无法枚举 | RC配置空间损坏或PCIe链路协商失败 | 先检查链路训练状态（LTSSM），用逻辑分析仪抓gen/gen2握手 |
| DMA写无响应 | 地址落在非内存空间或IOMMU未配置 | 用iommu=pt绕过VT-d测试，定位后再开启 |
| 中断收不到 | MSI地址写错或RC中断路由表未更新 | 查看/proc/interrupts，确认设备中断号分配正常 |
| BAR映射重叠 | 多个设备BAR请求冲突 | BIOS中预留足够MMIO空间，或者用pci=realloc重新分配 |
pci=realloc,mem才解决。所以建议：设计阶段就明确BAR属性（64位预取、可预取），不要留到调试时再改。
2.5 协同工作的核心要点
- RC是CPU侧的“唯一桥梁”，所有配置和DMA流量必经它。
- EP发起DMA时，RC必须能正确翻译目标地址（IOMMU或直通）。
- 中断路径和DMA路径是分离的：数据走TLP写，中断走MSI。
- 调试时从RC配置空间查起，链路协商、BAR分配、总线使能，一步步确认。
嗯，理解了这个协同机制，你就能明白为什么很多PCIe DMA驱动里要先配RC侧的MMIO基址，再配EP侧的DMA描述符了。说白了，就是给EP指路——告诉它“你写我这边哪块地址，我才能安全地收到”。
下一层我们会深入DMA描述符和队列管理。但先把RC与EP的关系焊死在心里，后面才不会被各种诡异问题搞晕。