NVMe驱动开发入门：从PCIe枚举到块设备注册全链路解析

NVMe 这三个字母，很多人第一次看到是在买固态硬盘的时候——商家页面上写着"支持 NVMe 协议，读写 3500MB/s"，比 SATA 固态快了好几倍。但如果你是个搞嵌入式或者内核开发的，NVMe 对你的意义就完全不一样了：它是一个相对年轻、结构清晰、文档公开的存储协议，是入门复杂存储驱动开发最合适的切入点。我接触过不少做驱动的朋友，一上来就想啃 SCSI 或者 FC，结果被几十年的历史包袱和层层叠叠的兼容逻辑劝退。而 NVMe 从 2011 年诞生起就是为闪存设计的，队列模型干净、寄存器语义明确、命令集精简，你完全可以在几周内把从 PCIe 枚举到块设备注册的整条链路摸清楚。

这篇内容面向的是有一定 C 语言和 Linux 内核基础，但没怎么碰过存储子系统的开发者。我会从 NVMe 为什么适合入门讲起，把 PCIe 枚举、BAR 空间映射、队列创建、命令提交、中断处理这条主线拆开揉碎，再补充 U-Boot 阶段的初始化、内核里的调试手段、以及实际项目中容易踩的坑。读完你至少能做到：拿到一块 NVMe 盘或者一个 NVMe 控制器 IP，知道从哪里下手、每一步在干什么、出问题往哪个方向查。

1. 为什么 NVMe 是存储驱动入门的"最优解"

1.1 存储驱动开发的难度阶梯

存储驱动这个领域，难度差异极大。我大致把它分成几个层次：

NVMe 处在一个很甜的位置：它足够复杂，能让你学到现代存储驱动的核心概念（多队列、DMA、中断聚合、异步完成），但又没有 SCSI 那种几十年的历史沉积。你不需要理解"为什么这个命令要这样编码"这种考古问题，NVMe 的规范写得很清楚，每个字段都有明确定义。

1.2 NVMe 协议设计的"干净"体现在哪

我第一次读 NVMe 规范的时候，最直观的感受是：它把"队列"这件事做到了极致。

传统 SATA/AHCI 只有一个命令队列，深度 32。NVMe 支持最多 65535 个队列，每个队列深度也是 65535。这不是为了堆数字，而是因为闪存的并行性极强——一块 NVMe 盘内部可能有 8 个甚至 16 个闪存通道，如果只有一个队列，根本喂不满这些通道。

更关键的是，NVMe 的队列是成对出现的：提交队列（SQ）和完成队列（CQ）。主机往 SQ 里放命令，控制器处理完后往 CQ 里放完成项。这个模型比 AHCI 那种"写寄存器、读寄存器"的方式清晰太多，也更适合多核并发——每个 CPU 核可以有自己的队列对，互不干扰。

还有一个细节：NVMe 的命令格式是固定 64 字节的。前 16 个字节是通用字段（操作码、命令 ID、命名空间 ID 等），后面 48 字节是各命令特有的参数。这种定长设计让解析变得非常简单，你不需要像 SCSI 那样处理变长 CDB。

1.3 从 PCIe 到块设备：一条完整的链路

学 NVMe 驱动最大的收获，是你能走通一条从硬件到用户空间的完整路径：

用户程序 read()/write() ↓ VFS 层 ↓ 块设备层（bio、request） ↓ NVMe 驱动（nvme_queue_rq） ↓ NVMe 命令（SQ entry） ↓ PCIe 总线（MMIO 写门铃） ↓ NVMe 控制器硬件 ↓ 闪存介质

这条链路上每一层都有东西可学：VFS 怎么把文件操作转成块操作、块层怎么合并和调度请求、NVMe 驱动怎么把 request 转成 NVMe 命令、PCIe 怎么完成 MMIO 和 DMA、中断怎么从控制器回到 CPU。你把 NVMe 驱动搞明白了，再去看其他存储驱动，会发现很多概念是相通的。

我个人的经验是：如果你能独立写一个最简 NVMe 驱动，让它能识别盘、读出一个 LBA 的数据，那你对 Linux 存储子系统的理解就已经超过大部分只会调 API 的开发者了。

2. PCIe 枚举：NVMe 驱动之前必须先搞懂的事

2.1 枚举到底在枚举什么

很多人写 NVMe 驱动时，直接调用pci_register_driver就完事了，PCIe 枚举好像是内核自动完成的。但如果你在 U-Boot 阶段要初始化 NVMe，或者调试一个枚举失败的板子，就必须理解枚举的过程。

PCIe 枚举的本质是遍历拓扑、分配资源。系统启动时，RC（Root Complex）不知道下面挂了多少设备、每个设备需要多少地址空间。枚举就是：

1. 从总线 0、设备 0、功能 0 开始扫描
2. 读配置空间的 Vendor ID，如果是 0xFFFF 说明没有设备
3. 如果有设备，读它的 Header Type，判断是桥还是端点
4. 如果是桥，继续扫描它下面的总线
5. 记录每个设备需要的 BAR 空间大小
6. 统一分配 MMIO 和 I/O 地址

这个过程在 Linux 内核里由pci_scan_child_bus等一系列函数完成，在 U-Boot 里也有对应的pci_scan_bus实现。

2.2 BAR 空间：NVMe 寄存器的"门牌号"

NVMe 控制器在 PCIe 配置空间里有几个 BAR，最重要的是BAR0。BAR0 指向 NVMe 的寄存器集合，包括：

• CAP（Controller Capabilities）：偏移 0x00，8 字节，告诉你控制器支持多少队列、队列深度多大、有没有可选特性
• VS（Version）：偏移 0x08，4 字节，NVMe 规范版本
• CC（Controller Configuration）：偏移 0x14，4 字节，用来使能控制器、设置队列参数
• CSTS（Controller Status）：偏移 0x1C，4 字节，反映控制器当前状态
• AQA（Admin Queue Attributes）：偏移 0x24，4 字节，管理队列的深度
• ASQ（Admin Submission Queue Base Address）：偏移 0x28，8 字节
• ACQ（Admin Completion Queue Base Address）：偏移 0x30，8 字节

写驱动第一步就是读 CAP，看看控制器到底支持什么。比如 CAP 的 bit 0-15 是 MQES（Maximum Queue Entries Supported），表示队列最大深度。如果 MQES 是 0x3FF，那队列深度最大就是 1024。

/* 读取 CAP 寄存器，判断控制器能力 */ u64 cap = readq(dev->bar + NVME_REG_CAP); u16 mqes = cap & 0xFFFF; u8 dstrd = (cap >> 32) & 0xF; /* 门铃寄存器步长 */ u8 timeout = (cap >> 24) & 0xFF; /* 超时值 */

这里有个容易忽略的点：门铃寄存器（Doorbell）的步长不是固定的。CAP 里的 DSTRD 字段告诉你每个队列的门铃寄存器占多少字节（通常是 4 字节，但可能是 8、16 等）。如果你按固定 4 字节去算门铃地址，在某些控制器上就会写错位置。

2.3 枚举失败的常见原因

我在实际项目中遇到过好几次 PCIe 枚举失败，总结下来大概这几类：

链路训练失败：PCIe 是高速差分信号，对走线阻抗、参考时钟、电源质量都很敏感。如果链路没训练起来，配置空间读出来全是 0xFFFF。这时候要用示波器看参考时钟有没有、看 LTSSM 状态机卡在哪一步。

BAR 空间分配冲突：如果系统里多个设备需要的 MMIO 空间超过了 RC 能提供的窗口，后面的设备就分配不到地址。这种情况在嵌入式板子上很常见，因为 RC 的 MMIO 窗口往往配得比较小。

复位时序问题：有些 NVMe 盘上电后需要一段时间才能响应配置空间访问。如果枚举太早，可能读到无效数据。PERST# 信号的释放时机很关键。

调试 PCIe 枚举，lspci -vvv是最基本的工具。如果连设备都看不到，先确认物理链路；如果能看到设备但 BAR 没分配，检查 RC 的窗口配置；如果 BAR 分配了但驱动 probe 失败，那就是驱动层面的问题了。

3. 队列机制：NVMe 性能的命脉

3.1 提交队列与完成队列的协作

NVMe 的队列对（Queue Pair）是驱动和控制器之间沟通的桥梁。每个队列对包含一个 SQ 和一个 CQ，它们在内存里的结构是环形缓冲区。

SQ 里的每个条目是 64 字节的命令，CQ 里的每个条目是 16 字节的完成项。驱动维护两个指针：

• SQ Tail Doorbell：驱动写这个门铃，告诉控制器"我又放了新命令"
• CQ Head Doorbell：驱动写这个门铃，告诉控制器"我处理完这些完成项了"

控制器那边也有两个指针：

• SQ Head：控制器内部维护，表示它处理到哪了
• CQ Tail：控制器内部维护，表示它写了多少完成项

这个机制的关键在于：驱动和控制器通过门铃和内存中的指针来同步，而不是通过锁或者轮询。驱动写 SQ Tail Doorbell 是一个 MMIO 写操作，控制器硬件会感知到这个写，然后去内存里取命令。

/* 提交命令的典型流程 */ static void nvme_submit_cmd(struct nvme_queue *nvmeq, struct nvme_command *cmd) { u16 tail = nvmeq->sq_tail; memcpy(&nvmeq->sq_cmds[tail], cmd, sizeof(*cmd)); if (++tail == nvmeq->q_depth) tail = 0; writel(tail, nvmeq->q_db); /* 写 SQ Tail Doorbell */ nvmeq->sq_tail = tail; }

3.2 管理队列与 I/O 队列的区别

NVMe 有两类队列：管理队列（Admin Queue）和I/O 队列。

管理队列只有一个，在控制器初始化时创建。它负责处理 Identify、Set Features、Get Features、Create I/O Queue 等管理命令。管理队列的 SQ 和 CQ 基地址通过 ASQ 和 ACQ 寄存器告诉控制器。

I/O 队列可以有多个，由驱动通过管理命令动态创建。每个 I/O 队列对通过Create I/O Completion Queue和Create I/O Submission Queue两个命令建立。创建时需要指定队列 ID、深度、中断向量等信息。

为什么要分两类？因为管理命令和 I/O 命令的优先级、处理路径不同。管理命令不频繁但很重要，I/O 命令量大且要求低延迟。分开之后，I/O 路径可以做到无锁、无阻塞。

3.3 中断聚合与轮询的取舍

NVMe 支持两种完成通知方式：中断和轮询。

中断模式下，控制器写完 CQ 后会触发 MSI-X 中断，驱动在中断处理函数里处理完成项。这种方式 CPU 占用低，但中断本身有开销（上下文切换、缓存失效）。

轮询模式下，驱动主动检查 CQ 里有没有新完成项。这种方式延迟极低，但会占满一个 CPU 核。

实际驱动通常混合使用：先开中断，如果短时间内完成项很多，就切换到轮询；空闲一段时间后再切回中断。Linux 内核的 NVMe 驱动里有nvme_poll和中断处理的配合逻辑。

还有一个重要概念是中断聚合（Interrupt Coalescing）。控制器可以配置成"攒够 N 个完成项再发中断"或者"等 T 微秒再发中断"，减少中断次数。这个通过 Set Features 命令配置。

我在做高性能场景调优时发现，中断聚合的参数对吞吐影响很大。聚合太激进，延迟会上去；聚合太保守，CPU 都耗在中断处理上了。一般需要根据实际负载压测来调。

4. 从零初始化一个 NVMe 控制器

4.1 控制器使能的标准流程

NVMe 控制器的初始化有一套标准流程，规范里写得很清楚：

1. 等待 CSTS.RDY = 0：确保控制器处于禁用状态
2. 配置 AQA：设置管理队列的深度
3. 配置 ASQ 和 ACQ：告诉控制器管理队列在内存的哪里
4. 配置 CC：设置 I/O 命令集、仲裁机制、页大小等
5. 设置 CC.EN = 1：使能控制器
6. 等待 CSTS.RDY = 1：确认控制器已经就绪

/* 简化的控制器使能流程 */ static int nvme_enable_ctrl(struct nvme_dev *dev) { /* 等待控制器禁用 */ if (nvme_wait_ready(dev, false)) return -ENODEV; /* 配置管理队列 */ writel(dev->q_depth - 1, dev->bar + NVME_REG_AQA); writeq(dev->admin_q.sq_dma, dev->bar + NVME_REG_ASQ); writeq(dev->admin_q.cq_dma, dev->bar + NVME_REG_ACQ); /* 配置 CC */ u32 cc = readl(dev->bar + NVME_REG_CC); cc &= ~NVME_CC_IOCQES_MASK; cc |= (4 << NVME_CC_IOCQES_SHIFT); /* 完成项 16 字节 */ cc &= ~NVME_CC_IOSQES_MASK; cc |= (6 << NVME_CC_IOSQES_SHIFT); /* 命令 64 字节 */ cc |= NVME_CC_EN; writel(cc, dev->bar + NVME_REG_CC); /* 等待就绪 */ return nvme_wait_ready(dev, true); }

这里有个细节：CC 里的 IOSQES 和 IOCQES 必须和实际命令/完成项大小匹配。SQ 条目是 64 字节，所以 IOSQES = 6（2^6 = 64）；CQ 条目是 16 字节，所以 IOCQES = 4（2^4 = 16）。写错了控制器行为未定义。

4.2 Identify 命令：了解你的盘

控制器使能后，第一件事是发 Identify 命令，搞清楚这个盘长什么样。Identify 有两个重要的 CNS（Controller or Namespace Structure）值：

• CNS = 0x01：Identify Controller，返回控制器级别的信息（型号、序列号、支持的队列数、支持的命名空间数等）
• CNS = 0x00：Identify Namespace，返回指定命名空间的信息（容量、LBA 格式、支持的读写命令等）

Identify 返回的数据结构很大，控制器信息有 4096 字节，命名空间信息也是 4096 字节。里面每个字段都有明确含义，比如：

• NN（Number of Namespaces）：控制器支持多少个命名空间
• LBAF（LBA Format）：支持的 LBA 格式，包括块大小
• AWUN/AWUPF：原子写单元大小
• SGLS：散射聚集列表支持情况

/* 发送 Identify 命令 */ static int nvme_identify_ctrl(struct nvme_dev *dev, struct nvme_id_ctrl *id) { struct nvme_command c = {0}; c.identify.opcode = nvme_admin_identify; c.identify.cns = NVME_ID_CNS_CTRL; return nvme_submit_admin_cmd(dev, &c, id, sizeof(*id)); }

4.3 创建 I/O 队列并注册块设备

管理队列跑通后，就可以创建 I/O 队列了。每个 I/O 队列对需要：

1. 分配 SQ 和 CQ 的内存（DMA 一致性内存）
2. 发 Create I/O CQ 命令
3. 发 Create I/O SQ 命令
4. 配置中断（MSI-X）

创建完成后，驱动会为每个命名空间注册一个块设备（gendisk）。用户空间的read()/write()最终会变成 NVMe 的 Read/Write 命令。

/* 创建 I/O 完成队列 */ static int nvme_create_cq(struct nvme_dev *dev, int qid, u16 depth) { struct nvme_command c = {0}; c.create_cq.opcode = nvme_admin_create_cq; c.create_cq.qid = cpu_to_le16(qid); c.create_cq.qsize = cpu_to_le16(depth - 1); c.create_cq.pc = 1; /* 物理连续 */ c.create_cq.irq_vector = cpu_to_le16(qid); return nvme_submit_admin_cmd(dev, &c, NULL, 0); }

创建队列时最容易出错的是队列 ID 的分配。管理队列固定是 ID 0，I/O 队列从 1 开始。如果你重复使用同一个 ID，控制器会返回错误。另外，队列深度必须是 2 的幂次或者至少是偶数，具体看控制器要求。

5. U-Boot 阶段的 NVMe 初始化

5.1 为什么要在 U-Boot 里支持 NVMe

很多人觉得 U-Boot 只要能加载内核就行了，NVMe 支持可有可无。但在实际产品里，U-Boot 支持 NVMe 有几个实际价值：

从 NVMe 盘启动：有些设备没有 eMMC 或者 SPI Flash，系统就装在 NVMe 盘上。U-Boot 必须能读 NVMe 盘才能加载内核。

固件更新：通过 U-Boot 往 NVMe 盘写固件镜像，比在系统里更新更可靠。

快速验证硬件：板子刚回来，系统还没跑起来，用 U-Boot 的 NVMe 命令测一下盘能不能识别、能不能读写，是最快的硬件验证手段。

5.2 U-Boot NVMe 驱动的结构

U-Boot 的 NVMe 驱动在drivers/nvme/目录下，核心文件是nvme.c。它的结构和内核驱动类似，但简化了很多：

• 只支持一个管理队列和一个 I/O 队列
• 不支持多命名空间（通常只用第一个）
• 中断处理简化（U-Boot 里通常用轮询）

U-Boot 里初始化 NVMe 的入口是nvme_init，它会：

1. 调用 PCIe 枚举，找到 NVMe 设备
2. 映射 BAR0
3. 使能控制器
4. 发 Identify 命令
5. 创建 I/O 队列
6. 注册块设备

/* U-Boot 里读 NVMe 盘的简化流程 */ int nvme_read(struct udevice *dev, ulong blknr, lbaint_t blkcnt, void *buffer) { struct nvme_dev *ndev = dev_get_priv(dev); struct nvme_command c = {0}; c.rw.opcode = nvme_cmd_read; c.rw.nsid = cpu_to_le32(ndev->nsid); c.rw.slba = cpu_to_le64(blknr); c.rw.length = cpu_to_le16(blkcnt - 1); /* 设置 PRP 列表指向 buffer */ return nvme_submit_io_cmd(ndev, &c, buffer, blkcnt * 512); }

5.3 U-Boot 下调试 NVMe 的实用命令

U-Boot 提供了一组 NVMe 命令，调试时非常有用：

nvme scan # 扫描 NVMe 设备 nvme info # 显示设备信息 nvme read <addr> <blk> <cnt> # 读数据到内存 nvme write <addr> <blk> <cnt> # 从内存写数据 nvme identify <nsid> <addr> # 发 Identify 命令

我一般拿到新板子的调试顺序是：

1. pci命令看 PCIe 设备有没有枚举到
2. pci bar看 BAR 有没有分配
3. nvme scan看 NVMe 设备能不能识别
4. nvme info看盘的信息对不对
5. nvme read读几个块，用md命令看数据

如果nvme scan就失败了，问题在控制器初始化；如果 scan 成功但 read 失败，问题在队列或者 PRP 设置。

U-Boot 的 NVMe 驱动有个坑：DMA 地址必须是物理地址。U-Boot 通常不开 MMU（或者开了也是恒等映射），所以虚拟地址等于物理地址。但如果你在开了 MMU 的 U-Boot 里跑，就要注意地址转换。

6. 内核 NVMe 驱动的调试手段

6.1 用 ftrace 跟踪命令流程

Linux 内核的 NVMe 驱动已经非常成熟，但调试时你还是需要知道命令走到哪了。ftrace是最轻量的工具：

# 跟踪 NVMe 相关函数 echo function > /sys/kernel/debug/tracing/current_tracer echo 'nvme_*' > /sys/kernel/debug/tracing/set_ftrace_filter echo 1 > /sys/kernel/debug/tracing/tracing_on # 执行一些 I/O 操作 cat /sys/kernel/debug/tracing/trace

你可以看到nvme_queue_rq、nvme_submit_cmd、nvme_process_cq等函数的调用顺序和时间戳。如果某个命令提交后很久没有完成，就能定位到是卡在提交还是卡在完成。

6.2 用 nvme-cli 做协议级调试

nvme-cli是用户空间的 NVMe 管理工具，但它能做的事情远不止看盘信息：

nvme list # 列出所有 NVMe 设备 nvme id-ctrl /dev/nvme0 # Identify Controller nvme id-ns /dev/nvme0n1 # Identify Namespace nvme get-feature /dev/nvme0 -f 0x07 # 读 Number of Queues nvme set-feature /dev/nvme0 -f 0x07 -v 8 # 设置队列数 nvme admin-passthru /dev/nvme0 --opcode=0x06 # 发任意管理命令 nvme io-passthru /dev/nvme0n1 --opcode=0x02 # 发任意 I/O 命令

admin-passthru和io-passthru特别有用，你可以直接发原始命令，观察控制器返回什么。比如你想测试某个不常用的命令，不用改驱动，直接用 passthru 就能验证。

6.3 性能问题的排查思路

NVMe 性能不达标，排查顺序一般是：

先看队列数：nvme get-feature -f 0x07看实际用了多少队列。如果只有一个队列，多核性能肯定上不去。

再看中断亲和性：cat /proc/interrupts | grep nvme看中断分布在哪些 CPU 上。如果都集中在一个核，需要调整 IRQ affinity。

然后看 I/O 调度器：cat /sys/block/nvme0n1/queue/scheduler。NVMe 盘通常建议用none（无调度器），因为盘本身足够快，调度器反而增加延迟。

最后看队列深度：cat /sys/block/nvme0n1/queue/nr_requests。深度太小会导致请求排队，深度太大可能浪费内存。

# 调整 NVMe 队列深度和调度器 echo none > /sys/block/nvme0n1/queue/scheduler echo 1024 > /sys/block/nvme0n1/queue/nr_requests

我遇到过一个案例：某国产 NVMe 盘在 Linux 下性能只有标称的一半。查了半天发现是驱动默认只创建了 1 个 I/O 队列，而盘支持 16 个。改成多队列后性能直接翻倍。所以拿到新盘，先确认队列数有没有配对。

7. 那些文档里不会写的踩坑经验

7.1 PRP 与 SGL 的选择

NVMe 读写命令的数据传输有两种方式：PRP（Physical Region Page）和SGL（Scatter Gather List）。

PRP 是 NVMe 最早支持的方式，它用两个指针（PRP1 和 PRP2）描述数据缓冲区。如果数据不超过一个页，PRP1 直接指向数据；如果超过一个页，PRP1 指向一个 PRP 列表，PRP2 指向列表的下一页。

SGL 更灵活，支持任意长度的分散聚集列表，但需要控制器支持（CAP 里的 SGL 位）。

大部分驱动默认用 PRP，因为兼容性好。但 PRP 有个限制：每个 PRP 列表项必须页对齐。如果你的数据缓冲区不是页对齐的，就要额外处理。

/* PRP 设置的简化逻辑 */ static void nvme_set_prp(struct nvme_command *c, dma_addr_t dma, u32 len) { c->rw.prp1 = cpu_to_le64(dma); if (len <= PAGE_SIZE) { c->rw.prp2 = 0; } else { /* 需要 PRP 列表 */ c->rw.prp2 = cpu_to_le64(prp_list_dma); } }

7.2 超时与复位处理

NVMe 命令有可能超时。超时后驱动要做的不是简单重试，而是复位控制器。因为超时可能意味着控制器内部状态异常，重试可能返回错误数据。

复位流程：

1. 设置 CC.EN = 0
2. 等待 CSTS.RDY = 0
3. 重新初始化控制器
4. 重新创建队列
5. 重新挂载命名空间

这个过程在 Linux 内核里由nvme_reset_ctrl完成。如果你自己写驱动，一定要实现超时检测和复位，否则一个命令卡住整个系统就挂了。

7.3 命名空间与分区表

NVMe 的命名空间（Namespace）概念容易和分区混淆。一个 NVMe 控制器可以有多个命名空间，每个命名空间是一个独立的逻辑块设备。命名空间下面才是分区表（MBR/GPT）。

在 Linux 里，/dev/nvme0是控制器，/dev/nvme0n1是命名空间 1，/dev/nvme0n1p1是命名空间 1 上的第一个分区。

有些盘出厂时命名空间是未格式化的，需要先发 Format NVM 命令。这个命令会擦除整个命名空间的数据，用之前一定要确认。

# 格式化命名空间（谨慎操作） nvme format /dev/nvme0n1 --lbaf=0 --ses=1

7.4 电源管理与热插拔

NVMe 支持多种电源状态（PS0-PS4），PS0 是全速，PS4 是最低功耗。驱动可以通过 Set Features 命令切换电源状态。

热插拔方面，PCIe 支持热插拔，但需要硬件和软件配合。硬件上需要热插拔控制器，软件上需要处理 SURPRISE DOWN 和 LINK DOWN 事件。NVMe 盘被拔出时，驱动要能安全地清理资源，不能崩溃。

我在一个项目里遇到过 NVMe 盘热插拔后系统 panic 的问题。原因是驱动没有正确处理nvme_remove和中断的竞争。后来加了引用计数和状态检查才解决。热插拔路径的代码一定要仔细测。

8. 从 NVMe 出发，还能往哪深入

把 NVMe 驱动跑通之后，你会发现很多方向可以继续深入。

多队列与性能调优：研究怎么根据 CPU 核数分配队列、怎么设置中断亲和性、怎么调中断聚合参数。这块直接关系到实际产品的性能表现。

NVMe over Fabrics：把 NVMe 命令封装到网络协议里传输，包括 NVMe over RDMA、NVMe over TCP。这是数据中心存储的前沿方向。

ZNS（Zoned Namespace）：NVMe 的新特性，把闪存按区域管理，适合顺序写入场景。对文件系统和数据库都有影响。

PCIe 底层调试：如果你对 PCIe 本身感兴趣，可以研究 LTSSM 状态机、均衡（Equalization）、PTM（Precision Time Measurement）等。这些在高速信号调试时很有用。

虚拟化场景：在虚拟机里模拟 NVMe 控制器，或者做 NVMe 设备的直通。这涉及到 VFIO、IOMMU 等技术。

我个人的建议是：先把一个最简 NVMe 驱动写出来，能读能写就行。然后在这个基础上加功能：多队列、中断聚合、超时复位、电源管理。每加一个功能，你对存储子系统的理解就深一层。等你能独立调试一个真实的 NVMe 硬件问题，比如链路训练失败或者性能不达标，那就算真正入门了。

最后分享一个我常用的验证方法：写一个用户态程序，用ioctl直接发 NVMe passthru 命令，绕过文件系统直接和盘交互。这样你能精确控制每个命令的参数，观察控制器的原始返回。对于理解协议细节，这比看代码有效得多。