2、PCIe基础回顾：PCIe拓扑结构、PCIe配置空间、BAR空间与MMIO
各位同学，咱们今天聊PCIe。说实话，NVMe和PCIe的关系，就像鱼和水。你搞NVMe，不懂PCIe，那基本是瞎搞。我见过太多工程师，NVMe协议背得滚瓜烂熟，结果调起板子来，BAR空间映射不对，死活枚举不到设备——嗯，这种坑我自己也踩过。
所以这一节，咱们把PCIe的几个核心概念捋清楚。不追求大而全，只讲NVMe开发中你一定会碰到的那些东西。
2.1 PCIe拓扑结构：树形层级与点对点
PCIe的拓扑结构，说白了就是一棵树。树根叫Root Complex（RC），树枝叫Switch，树叶叫Endpoint（EP）。NVMe SSD就是典型的Endpoint。
为什么会设计成树形？你想想看，如果所有设备都挂在一条总线上，那带宽怎么分？PCIe用点对点连接，每个设备都有自己的专用通道，这才有了高性能的基础。
核心要点：
- Root Complex (RC)：连接CPU和内存，是PCIe域的主控
- Switch：扩展端口，内部包含多个虚拟PCI桥
- Endpoint (EP)：功能设备，NVMe控制器就是EP
- PCIe Bridge：用于连接传统PCI总线，现在很少见了
我画了一张图，帮你理解这个层级关系：
这张图里，RC是老大，Switch是中间人，Endpoint是干活的。NVMe SSD作为Endpoint，通过Switch和RC通信，最终访问系统内存。
我的经验：调试NVMe驱动时，第一步永远是确认设备枚举是否成功。用lspci -vvv看看你的NVMe设备有没有出现在正确的Bus/Device/Function上。如果看不到，先查PCIe链路，别急着调NVMe队列。
2.2 PCIe配置空间：设备的身份证
每个PCIe设备，都有一个256字节的配置空间。这是PCIe协议规定的，NVMe设备也不例外。配置空间里存了什么？说白了就是设备的身份信息、能力描述、以及资源需求。
配置空间的前64字节是标准头部，所有PCIe设备都一样。后面的192字节是能力结构，不同设备可以定义自己的能力。
| 偏移 | 寄存器 | 说明 |
|---|---|---|
| 0x00 | Vendor ID | 厂商ID，NVMe设备通常为8086（Intel）、144d（Samsung）等 |
| 0x02 | Device ID | 设备ID，每个型号不同 |
| 0x04 | Command | 控制命令，如IO空间使能、内存空间使能、总线主控使能 |
| 0x06 | Status | 状态寄存器，反映设备当前状态 |
| 0x08 | Revision ID | 修订版本 |
| 0x09 | Class Code | 分类代码，NVMe属于Mass Storage Controller (01 08 02) |
| 0x10-0x24 | BAR0-BAR5 | 基地址寄存器，共6个，每个32位或64位 |
| 0x34 | Capabilities Pointer | 能力链表指针，指向第一个能力结构 |
注意：我曾经遇到一个坑——某款NVMe SSD的Vendor ID读出来是0xFFFF。这意味着什么？设备没被正确枚举！查了半天，原来是PCIe复位时序没满足。所以读配置空间时，先检查Vendor ID是不是0xFFFF，这是最基本的健康检查。
2.3 BAR空间与MMIO：CPU怎么和设备说话？
好，现在设备枚举成功了，CPU怎么和NVMe控制器通信？答案就是BAR空间和MMIO。
BAR，全称Base Address Register，是配置空间里的6个寄存器（BAR0-BAR5）。设备通过BAR告诉系统：我需要多少内存空间或IO空间，以及我希望映射到哪个地址。
MMIO，全称Memory-Mapped IO，就是把设备的寄存器映射到CPU的内存地址空间里。CPU读写这些地址，就等于在和设备通信。
NVMe设备通常只用BAR0，而且一定是64位的MMIO空间。为什么？因为NVMe的寄存器比较多，32位地址不够用。
BAR空间分配流程：
- 系统枚举设备，读取BAR寄存器
- 向BAR写入全1，再读回来，得到设备需要的空间大小
- 系统分配一段空闲的物理地址空间
- 将分配的基地址写入BAR寄存器
- 设备就知道自己的寄存器被映射到了哪里
举个例子，NVMe设备说我要4KB的MMIO空间。系统说好，我给你映射到物理地址0xF0000000。那CPU访问0xF0000000，就等于访问NVMe控制器的第一个寄存器。
// 伪代码：读取NVMe控制器的CAP寄存器（偏移0x00）
// 假设BAR0被映射到虚拟地址 bar0_vaddr
uint64_t cap = *(volatile uint64_t *)(bar0_vaddr + 0x00);
// cap里包含了NVMe控制器的版本号、队列深度限制等信息我的习惯：写驱动时，我会先打印BAR0的物理地址和映射后的虚拟地址。用ioremap()把物理地址映射到内核虚拟地址空间，然后直接读寄存器。如果读出来全是0xFF或者0x00，那肯定是映射有问题。
2.4 从PCIe角度看NVMe：一个完整的例子
咱们把上面这些串起来，看看一个NVMe SSD从上电到可用的完整流程：
- 上电复位：PCIe链路训练，建立连接
- 设备枚举：系统读取配置空间，发现NVMe设备
- BAR分配：系统读取BAR0，分配MMIO空间
- 驱动加载：NVMe驱动读取配置空间，获取BAR0地址
- MMIO映射：驱动将BAR0映射到虚拟地址空间
- 控制器初始化：通过MMIO读写NVMe寄存器，使能控制器
- 队列创建：创建管理队列和IO队列
- IO操作：提交命令，处理完成
你看，前3步是PCIe的活，后5步才是NVMe的活。但如果没有PCIe打好基础，NVMe根本跑不起来。
避坑指南：我曾经在调试一块NVMe SSD时，发现BAR0读出来的大小是0。这不可能啊！后来发现是设备处于D3冷状态，需要先唤醒。所以操作BAR之前，确保设备不在低功耗状态。
嗯，PCIe这块内容其实很深，但作为NVMe开发者，你掌握拓扑结构、配置空间、BAR和MMIO这三点就够了。下一节咱们正式进入NVMe的世界，从寄存器开始聊起。