3. NVMe命令集详解：Admin Command Set与NVM Command Set
NVMe的命体系，说白了就两大块：管理命令和数据命令。管理命令走Admin队列，数据命令走IO队列。这个区分很自然——你总不能让读写数据的命令和创建队列的命令混在一起吧？
我个人习惯把Admin命令集比作「控制面板」，NVM命令集比作「传送带」。控制面板负责配置、查询、管理；传送带只管把数据搬来搬去。今天我们就来拆开看看，这两块到底怎么玩。
3.1 Admin Command Set：控制面板上的那些按钮
Admin命令集里，最常用的就是Identify、Create IO SQ/CQ、Get Log Page这三个。我刚开始接触NVMe时，觉得Identify命令最无聊——不就是查个设备信息吗？后来才发现，这玩意儿是调试的命根子。
3.1.1 Identify命令：查户口
Identify命令用来获取控制器和命名空间的详细信息。你想想看，你要读写一块SSD，总得知道它支持多大队列深度、支持哪些特性吧？Identify就是干这个的。
命令结构很简单，通过CNS字段指定你要查什么：
struct nvme_identify {
__u8 opcode; // 0x06
__u8 flags;
__u16 command_id;
__le32 nsid; // 命名空间ID
__u64 rsvd2[2];
__le64 prp1; // 数据缓冲区地址
__le64 prp2;
__le32 cns; // 标识类型
__u32 rsvd11[5];
};CNS=0x00查控制器信息，CNS=0x01查命名空间信息。我在项目中遇到过一个问题：某款SSD返回的Identify数据里，MQES字段（最大队列深度）只有32，但驱动默认申请了64深度的队列。结果呢？创建队列时直接报错。所以，永远别硬编码队列深度，先Identify一下。
关键字段速查表：
| CNS值 | 含义 | 返回数据大小 |
|---|---|---|
| 0x00 | Identify Controller | 4096字节 |
| 0x01 | Identify Namespace | 4096字节 |
| 0x02 | Namespace List | 4096字节 |
3.1.2 Create IO SQ/CQ：搭桥铺路
IO队列不是天生就有的，你得自己创建。Create IO SQ和Create IO CQ是一对搭档——先建CQ，再建SQ，顺序不能乱。为什么？因为SQ完成的消息要发到CQ上，CQ得先存在。
我记得第一次写驱动时，把顺序搞反了，结果命令提交后一直没响应。查了半天才发现是CQ还没创建，SQ的完成事件无处可去。嗯，这种低级错误，犯一次就记住了。
struct nvme_create_cq {
__u8 opcode; // 0x05
__u8 flags;
__u16 command_id;
__le32 prp1; // CQ的内存地址
__le64 rsvd2[2];
__le16 cqid; // CQ ID
__le16 qsize; // 队列深度-1
__le16 cq_flags; // 物理连续、中断使能等
__u8 irq_vector; // 中断向量
__u8 rsvd3[3];
__le32 rsvd4[5];
};创建SQ的命令类似，但多了个cqid字段，指定这个SQ的完成事件发到哪个CQ上。一个CQ可以对应多个SQ，但一个SQ只能对应一个CQ。这个设计很巧妙——你想想看，多个提交队列共享一个完成队列，能省不少中断资源。
避坑指南：我曾经在调试时发现，创建队列后立即提交IO命令会失败。原因是队列创建命令还没完成，硬件还没准备好。正确的做法是：等待创建命令的完成通知，再提交IO。别偷懒，轮询CQ的Phase Tag也行。
3.1.3 Get Log Page：翻日志
Get Log Page命令用来获取控制器的日志信息。比如错误日志、健康信息（SMART）、固件槽位信息等。这玩意儿在排查问题时特别好用。
命令通过LID字段指定日志类型：
| LID值 | 日志名称 | 典型用途 |
|---|---|---|
| 0x01 | Error Information | 查看最近错误 |
| 0x02 | SMART / Health | 温度、寿命、磨损 |
| 0x03 | Firmware Slot | 固件版本信息 |
| 0x07 | Commands Supported and Effects | 查询支持的命令集 |
我个人习惯在驱动初始化时，先Get Log Page查一下Commands Supported and Effects日志。这能告诉我哪些命令是真正可用的，避免后续提交不支持的命令。
3.2 NVM Command Set：真正的数据搬运
Admin命令搞定了，接下来就是干活——读写数据。NVM命令集的核心就是Read、Write、Flush。这三个命令占了SSD工作量的99%。
3.2.1 Read/Write命令：搬砖
Read和Write命令的结构几乎一样，区别只在于opcode和方向。命令通过SLBA（起始逻辑块地址）和NLB（逻辑块数量）指定操作范围。
struct nvme_rw_command {
__u8 opcode; // Read: 0x02, Write: 0x01
__u8 flags;
__u16 command_id;
__le32 nsid;
__u64 rsvd2[2];
__le64 prp1;
__le64 prp2;
__le64 slba; // 起始逻辑块地址
__le16 nlb; // 逻辑块数量-1
__le16 control; // 控制标志
__u32 rsvd3[4];
};这里有个细节：NLB字段是实际数量减1。比如你要读4个块，NLB填3。为什么这么设计？我猜是为了兼容0值表示1个块的情况。嗯，NVMe规范里这种「减1」的编码方式很常见，习惯了就好。
注意：PRP1和PRP2是物理区域页面的指针。如果数据跨页了，PRP1指向第一个数据页，PRP2指向PRP列表。这个机制在驱动里处理起来有点绕，我建议你直接用SGL（Scatter Gather List）代替PRP，SGL更灵活，也更容易调试。
3.2.2 Flush命令：刷盘
Flush命令的作用是确保之前提交的所有写命令的数据都落盘了。说白了，就是让SSD把缓存里的数据写回NAND闪存。
命令结构很简单，opcode是0x00，只需要指定命名空间ID。但要注意：Flush是同步操作，它会阻塞后续命令直到完成。所以，别在关键路径上频繁调用Flush，否则性能会很难看。
我曾经在一个数据库项目中，看到有人每次写操作后都Flush一下。结果呢？IOPS从10万掉到了5000。后来改成每100次写操作Flush一次，性能才恢复正常。你想想看，Flush的本质是牺牲性能换数据安全，得找到平衡点。
3.3 知识体系总览
下面这张图把Admin命令集和NVM命令集的关系梳理清楚了。我建议你把它打印出来贴在工位上，写代码时瞄一眼，思路会清晰很多。
3.4 命令执行流程
不管Admin命令还是NVM命令，执行流程都一样：
- 构建命令：填充opcode、命令ID、PRP/SGL地址等字段
- 提交到SQ：将命令写入SQ的Tail指针位置，更新Doorbell
- 硬件执行：控制器从SQ取出命令，执行，结果写入CQ
- 获取完成：驱动轮询CQ或等待中断，读取完成状态
这个流程看起来简单，但每个环节都有坑。比如Doorbell的写入顺序——必须先写命令再写Doorbell，否则硬件可能读到不完整的命令。我曾经因为编译器优化导致Doorbell提前写入，排查了整整两天。后来加了wmb()内存屏障才解决。
我的建议：写驱动时，把命令提交封装成一个函数。函数内部严格按顺序执行：填充命令→内存屏障→更新Doorbell。这样既保证正确性，也方便调试。
好了，Admin命令集和NVM命令集的核心内容就这些。记住：Identify查户口，Create搭队列，Get Log Page翻日志；Read搬进来，Write搬出去，Flush保安全。把这几个命令吃透了，NVMe驱动开发就入门了。