NVMe CMB与DMA-BUF：内核设备内存共享接口之争

1. 从"第1个NVMe硬盘的第5个分区"说到控制器里的那小块神秘内存

最近后台总能刷到这么几个搜索词：/dev/nvme0n1p5是第 1 个 NVMe 硬盘的第 5 个分区吗、E5 平台配 NVMe 跑 Win10 启动一般要多久、用 NTLite 往老镜像里塞 USB3.0 和 NVMe 驱动、NVMe 固态怎么格式化。乍看都是普通用户问题，但它们其实指向同一个内核话题：NVMe 设备在操作系统里到底是怎么被暴露、被使用、被共享的。这个话题往下挖一层，就是标题里那个很硬核的争论——NVMe CMB 和 DMA-BUF 之间到底该用哪种内核接口。

1.1 /dev/nvme0n1p5 拆开是什么

先把用户热词解决掉。/dev/nvme0n1p5拆开是三层：nvme0代表第 0 个 NVMe 控制器（controller），n1代表这个控制器上的第 1 个 Namespace（命名空间），p5代表这个 Namespace 上的第 5 个分区。所以严格来说，它不是"第 1 个硬盘的第 5 个分区"，而是"第 1 个控制器的第 1 个 Namespace 的第 5 个分区"。消费级盘通常一个控制器一个 Namespace，简化成"第 1 块盘的第 5 个分区"问题不大，但理解成三层结构，后面聊内核就顺了。

块设备层把 Namespace 抽象成一个块设备，分区工具再在上面切分区。这一层用户能看见，也能操作。但 NVMe 控制器还有一层块设备完全看不见的东西，叫作 CMB（Controller Memory Buffer，控制器内存缓冲区）。CMB 既不是nvme0n1，也不是nvme0n1p5，它是控制器内部的一小块内存，通过 PCIe BAR 映射给主机访问。它离控制器核心最近，读写延迟比走系统总线的普通内存路径更可控，NVMe 规范甚至允许拿它放提交队列、完成队列、Shadow Doorbell 甚至数据缓冲。

问题来了：内核里那套专门用来在不同设备和用户态之间共享缓冲区的 DMA-BUF 接口，能不能也用来暴露这块 CMB？这个问题在 linux-nvme 和 dri-devel 两个圈子都吵过，吵的不仅是"能不能"，更是"该用哪种内核接口"。我先把技术底子铺开，再把我自己的取舍讲清楚。

1.2 从块设备往下看：CMB 一直没被用户态看见

你可能会有疑问：既然 CMB 这么好，为什么我用了这么多年 NVMe 盘，从来没见过它？因为 Linux 的块设备层只把 Namespace 呈现给文件系统，控制器内部的寄存器、BAR、队列内存这些都是驱动私有的。CMB 的映射和使用，从struct nvme_dev到你手上的应用，中间隔了好几个抽象层。普通用户感知不到，不代表它不重要。

实际上 Linux nvme 驱动很早就支持 CMB 了，只是使用方式非常克制。控制器 reset、队列分配、命令提交这些路径上，CMB 一直在参与，只是从来不出现在/sys/class/block/里。如果你想深挖一块 NVMe 盘到底有没有 CMB、CMB 多大、能拿来干什么，得去读控制器寄存器。这也是后面接口之争的第一个前提：CMB 是设备资源，不是通用内存，暴露它必须非常小心。

2. CMB 是什么，Linux 又拿它做了什么

2.1 规范视角：CMBLOC 与 CMBSZ 决定一切

从 NVMe 规范看，CMB 是控制器地址空间里的一段内存，通过 PCIe BAR 暴露。主机在 BAR 里有两个寄存器描述它：CMBLOC和CMBSZ。CMBLOC的低 3 位是 BIR（BAR Indicator Register），告诉系统 CMB 落在哪个 BAR；更高位给的是 CMB 在 BAR 内的偏移，按 4KB 对齐。CMBSZ的低 32 位是 SZ，真实大小按公式(SZ + 1) × 4KB计算。

CMBSZ 里还有一堆能力位。SDB 位标记这块 CMB 能不能放 Shadow Doorbell Buffer，SQR/CQR 位标记能不能放 Submission Queue 和 Completion Queue 的队列项，DTO 位标记是否定义了数据缓冲区域的偏移。这些能力位很重要，因为不是每块盘的 CMB 都支持全部功能。有些盘 CMB 只够放 Shadow Doorbell，有些盘 CMB 又能放队列又能放数据，保底能力完全不同。

Linux 的 nvme 驱动会尝试把 CMB 映射成 CPU 可访问的虚拟地址，老版本用devm_ioremap，新版本在部分平台上会选devm_ioremap_wc。映射完之后，驱动内部的队列分配、门铃处理就可以基于 CMB 做文章。但这里有一个非常现实的问题：把队列放到 CMB 并不一定快。

2.2 驱动现状：队列能用，数据缓冲基本没人用

历史上 nvme 驱动有一段时间会尝试把 Submission Queue 的队头项放到 CMB，也就是use_cmb_sqes这个模块参数。后来因为部分控制器的 CMB 读写性能反而比系统内存还差，加上 CMB 和 CPU 的预取、写合并行为配合不好，这个功能默认就被关掉了。你现在翻drivers/nvme/host/pci.c，能看到 CMB 的映射逻辑，也能看到队列分配时对 CMB 的引用，但绝大多数情况下，它只是"声明支持"，并不会主动把所有队列都挪进去。

数据缓冲更是基本没人用。规范里 CMB 的 DTO 能力允许把一段 CMB 划成数据中转区，让控制器做 DMA 的跳板。但现实里数据缓冲动辄几 MB 甚至几十 MB，大部分盘的 CMB 总共才 4~64MB，控制器自己还要留一部分给门铃和队列，剩下的空间小得可怜。更关键的是，数据放 CMB 并没有带宽优势，数据还是要在 PCIe 上跑，控制器离得近不等于数据搬得快。

2.3 一块只有几兆字节的"控制器私房钱"

我用"控制器私房钱"这个词，是想强调一个容易被忽略的事实：CMB 是控制器自己的资源，不是系统的。它不像 system RAM 那样可以被页分配器随便切，也不像 CMA 那样能按需回收。控制器把这块 BAR 空间暴露给主机，主机可以用它，但所有权和生命周期都绑定在控制器上——控制器一 reset，CMB 里的内容全部作废。

这也决定了 CMB 和 DMA-BUF 的结合点：如果你想在多个设备之间共享一段 CMB，比如让 GPU 直接读 CMB 里的数据，或者让另一个加速器写 CMB 里的门铃，就必须有一套安全、可控、能管理生命周期的接口。DMA-BUF 恰好是这套接口最成熟的候选，但它的契约远比想象中要重。

3. DMA-BUF 不是一个普通内核接口，它是一整套"快递规则"

3.1 dma-buf 的生命周期和关键回调

DMA-BUF 是内核给硬件加速器准备的缓冲共享机制。它解决的痛点很直接：同一块内存，摄像头要写、GPU 要读、显示控制器要扫描、CPU 也可能要碰。大家拿着同一个 fd，各取所需，谁也不把别人冲掉。

导出一块 dma-buf 不是创个对象就完事。Exporter 要提供struct dma_buf_ops，里面最重要的几个回调：attach/detach让 importer 设备绑定上来；map_dma_buf返回sg_table，给 importer 提供可 DMA 的地址；mmap让用户态能 CPU 映射；begin_cpu_access/end_cpu_access处理缓存同步；release在最后一个引用释放时收尸。

这条链路的精髓在于：用户态拿到的是一个 fd，不是裸指针。fd 背后有引用计数，有 exporter 的完整回调，有 attach 语义。GPU 要访问这块 buffer，得先dma_buf_attach把自己挂上去，再dma_buf_map_attachment拿到 DMA 地址。这块地址在设备眼里长什么样，完全由 exporter 决定。CMB 想进来，就要接受这一整套规则。

3.2 heap 框架解决的问题

用户态最容易触达 dma-buf 的入口是 heap 框架。内核里有system_heap、cma_heap，用户态open("/dev/dma_heap/system")，然后ioctl(DMA_HEAP_IOCTL_ALLOC)拿一个 dma-buf fd。这个 fd 可以传给 DRM、V4L2、RDMA，所有 importer 一视同仁。

heap 框架解决的问题是"谁来分配、怎么分配"。System heap 从页分配器拿内存，CMA heap 从连续内存区拿内存。它对上层屏蔽了分配细节，只留下一个干净的用户态接口。这也是很多人一看到 CMB 就想到 heap 的原因：如果 CMB 也能注册成一个 heap，用户态就能像分配系统内存一样分配控制器内存，然后顺手把 fd 丢给 GPU。听起来很完美，但问题恰恰出在"像分配系统内存"这六个字上。

3.3 CMB 和 dma-buf 契约的三个根本冲突

第一个冲突是分配模型。dma-buf 的底层思维是"从某个分配器拿出一块内存"，而 CMB 不是能随便切的页。它总量小，控制器自己要用，分配粒度、对齐、可映射长度都受 BAR 布局限制。你想做一个 CMB heap，必须先解决控制器内部队列和用户态分配之间的资源互斥。

第二个冲突是 CPU 访问类型。系统内存默认是 Write-Back 缓存，mmap 之后随便读写。CMB 一般要用 Write-Combining 映射，CPU 写有合并效应，读却非常慢。dma-buf 的begin_cpu_access/end_cpu_access语义是为普通缓存内存设计的，放到 WC 映射上会变得很别扭——你让 importer 做一次同步，它可能付出的代价远超想象。

第三个冲突是 DMA 地址语义。map_dma_buf返回的sg_table是要给 importer 设备做 DMA 用的。CMB 的地址是 PCIe BAR 上的地址，不是系统内存地址。如果 importer 在 IOMMU 后面，系统地址和总线地址之间还有一层翻译，CMB 这种 BAR 地址要额外处理，否则 DMA 会直接撞墙。这三个冲突，就是"NVMe CMB 到 DMA-BUF 内核接口之争"的真正内核。

4. 接口之争：四条路线谁更适合 CMB

4.1 路线一：给 CMB 做一个专用 dma-buf heap

最直观的方案，是在drivers/dma-buf/heaps/里加一个nvme-cmb-heap。每个支持 CMB 的控制器注册一个 heap，用户态open("/dev/dma_heap/nvme0cmb")，申请 1~2MB，拿 fd 传给 GPU。dma-buf 框架负责 fd 生命周期，exporter ops 负责 mmap 和 DMA 地址，看起来顺理成章。

但很快你会撞上一堵墙：heap 是通用分配器概念，要求内存可拆分、可回收、可统计。CMB 不是。CMB 总量小，控制器自己还要用，不可能把整个 CMB 都交给 heap。剩下那点空间怎么和驱动内部队列分配器互斥？你需要专门写一个资源管理器。为几 MB 内存写资源管理器，还要支持热插拔、控制器 reset、多 namespace，维护成本非常高。

这还不算完。heap 框架假设内存可以被任意设备 attach 并做 DMA，但 CMB 的 DMA 地址只在 PCIe 拓扑允许的范围内有效。有些 importer 设备在另一个 PCIe 域里，或者被 IOMMU 挡着，你导出的 buffer 它根本用不了。heap 的通用性在这里反而成了包袱。

4.2 路线二：从 NVMe ioctl 直接吐一个 dma-buf fd

另一派人认为，别搞通用 heap，直接在 nvme 的 ioctl 里加一个命令，返回 dma-buf fd。这样更直接：想要哪段就导哪段，只暴露 SDB 区域，或者只暴露 DTO 数据区。权限也可以挂在文件节点上，root 或特定 cgroup 才拿得到。

这个方案的好处是边界清晰。NVMe 驱动对自己设备上的 CMB 有完全的控制力，导出的每一段都经过了能力位校验。exporter 的 ops 不需要做通用分配器，只需要管理"哪段 BAR 内存被谁拿走了"。

缺点是 ioctl 是块设备 ABI，往里面塞 DRM 圈子的概念有点突兀。以后每个想用这个能力的内核模块，都得先学会解析一个块设备 ioctl 返回的 fd。而且 dma-buf 的价值恰恰在于通用性，你把它绑死在 nvme 上，等于把快递柜做成了只有一把钥匙的保险柜。将来换了别的设备，这套接口没法复用。

4.3 路线三：先做通用"设备内存 heap"抽象

还有人提出更宏大的方案：既然 CMB 算"设备内存"，不如先把 dma-buf heap 框架扩展成支持设备内存的通用框架，再让 CMB、GPU VRAM、FPGA SRAM 都往里塞。这个方向在邮件列表上吵得最凶。

问题在于设备内存不像 system RAM 那样有统一语义。有的只能 CPU 读，有的要 WC 映射，有的根本不能让 CPU 碰，有的还分 read-only/write-only 区域。要把这些差异全塞进一个通用 heap 框架，就必须定义一堆属性：缓存模式、对齐、是否可回收、是否可 CPU 映射、是否需要 IOMMU 绕过。定义到最后，DMA-BUF 的契约会膨胀得让所有人头疼。

我见过太多为了"通用性"先搭抽象层、最后被现实打脸的例子。设备内存的抽象不是不能做，而是应该等真的有五六个不同形态的消费方出现再做。现在只有一个 CMB，就急着造通用框架，大概率是过度设计。

4.4 路线四：什么都不做，把 P2P 用起来

第四条路线最反直觉：别做 CMB dma-buf 了，把 P2P DMA 用起来。现有pci_p2pdma机制已经允许一个设备的 DMA 直接访问另一个设备暴露的内存。NVMe 和 GPU 的场景里，正确的做法是让 NVMe 控制器直接把数据 DMA 到 GPU 显存，而不是绕道 CMB。

原因很简单：CMB 是控制器自己的内存，数据要先从 SSD 闪存搬到 CMB，再从 CMB 搬到 GPU，两次 PCIe 事务。P2P 只需要一次。带宽上 CMB 方案没有任何优势，延迟上也不占理，因为 CMB 离控制器近不等于离 GPU 近。

那 CMB dma-buf 什么时候还有价值？我想到三个场景。平台不支持 PCIe P2P（比如 IOMMU 挡路、PCIe 拓扑不允许）；需要把 Shadow Doorbell 或门铃区域暴露给另一个 agent，做极低延迟命令提交；虚拟化场景里想把 CMB 映射给 VM。这些场景很窄，但真实存在。所以"什么都不做"也不是什么都不做，而是不做数据路径，保留窄场景的旁路。

4.5 四条路线对照

5. 我的取舍与踩坑记录：一个驱动工程师的实操注记

5.1 怎么确认你手上这块盘到底有没有 CMB

先说排查方法。最省事的是看 dmesg 或 sysfs，但路径和格式因内核版本而异，不算稳定 ABI。排障时我会直接读 BAR 寄存器：先用lspci -vvv找 BAR 的物理地址，再用工具读偏移0x8和0xC。下面是一个典型的操作流程：

# 查看指定 NVMe 控制器（这里假设 01:00.0）的 BAR lspci -vvv -s 01:00.0 | grep -A5 "Region 0" # 假设 BAR0 物理地址是 0x91000000（用 lspci 看到的实际值替换） pcimem 0x91000000 0x8 w # 读 CMBLOC pcimem 0x91000000 0xc w # 读 CMBSZ

CMBLOC的 BIR 位告诉你 CMB 落在哪个 BAR，CMBSZ的低 32 位算出容量。比如CMBSZ = 0xFFF，CMB 大小就是(0xFFF + 1) × 4KB = 16MB。注意pcimem是直接操作设备寄存器的调试工具，权限校验、总线锁定一概没有，搞错了轻则读回垃圾，重则把控制器弄挂。我建议只在专门用来折腾的调试盘上这么玩，别拿生产环境的盘试。

5.2 我踩过的坑：dto、wc 映射、生命周期、sg 表

第一个坑是能力位不看全。不是所有盘的 DTO 都置位，很多消费级盘的 CMB 只支持 SDB，不支持数据缓冲。你拿这样的 CMB 去做 dma-buf，只能当门铃旁路用，不能当数据中转区。上层如果不查能力位就直接导入 buffer，跑起来就是各种诡异的 readback 错误。

第二个坑是 WC 映射。CMB 如果用devm_ioremap_wc映射，CPU 读性能极差，多次写之间还有合并窗口。dma-buf 的mmap一旦暴露给用户态，用户态随便做一次读循环，就能把整个子系统的性能拖垮。必须把映射属性写进 dma-buf 的导出信息里，让 importer 知道别当普通系统内存用。

第三个坑是生命周期。dma-buf fd 的生命周期和控制器 reset 是不对齐的。nvme 控制器一 reset，CMB 里的内容全部失效，但用户态手里的 fd 可能还开着。你必须让所有已导出的 dma-buf 在 reset 路径上统一失效，或者至少在 exporter ops 里把后续访问变成错误码。这个坑在普通 heap 里根本不存在，因为系统内存不会被 reset。

第四个坑是 sg_table 的 DMA 地址。map_dma_buf返回的 sg 不能走dma_map_page那套逻辑，因为 CMB 没有struct page。你需要手动构造 sg，把dma_address填成 BAR 物理地址，dma_length填成块长度。示意代码如下：

static struct sg_table *nvme_cmb_map_dma_buf(struct dma_buf_attachment *attach, enum dma_data_direction dir) { struct nvme_cmb_buf *buf = attach->dmabuf->priv; struct sg_table *sgt; sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); if (!sgt) return ERR_PTR(-ENOMEM); if (sg_alloc_table(sgt, 1, GFP_KERNEL)) { kfree(sgt); return ERR_PTR(-ENOMEM); } sg_init_table(sgt->sgl, 1); sgt->sgl->length = buf->size; sg_dma_mark_bus_addr(sgt->sgl, buf->bar_dma_addr); return sgt; }

这段只是示意，真正提交补丁还要处理 attach 语义、地址重映射和 IOMMU 情况。但核心思想是明确的：CMB 的 sg 是"总线地址直填"，不是从struct page映射出来的。我见过不少实现把sg_set_page硬套在 CMB 上，最后只在特定平台上没崩，换一台机器就露馅。

5.3 现阶段我的方案和 checklist

我自己的立场很明确：现阶段不支持为了 CMB 去造通用 device memory heap。数据路径走 P2P，CMB 最多做一个门铃/命令队列的低延迟旁路，而且只通过窄接口暴露。

如果你也在调研这个方向，我强烈建议按下面的 checklist 走一遍：

• 先确认硬件的 DTO/SDB 能力位，没有能力位就放弃对应用途
• 算清可用容量：CMB 总大小减去控制器保留部分，剩下的才是能导出的
• 明确使用模型：门铃旁路还是数据中转，不要混用
• 确认 CPU 映射属性：WC、UC 还是 Cacheable，写进导出信息
• 设计生命周期策略：控制器 reset 路径上，所有已导出 dma-buf 必须统一失效
• 想清楚 IOMMU 策略：绕过、还是走pci_p2pdma辅助函数
• 在真实平台上测带宽和延迟，而不是只看 sysfs 数字

这套流程能帮你过滤掉大部分纸上谈兵的设计。我也见过不少团队在第一步就倒下——他们手里的盘根本没有可用的数据型 CMB，却已经写了三页设计文档。

6. 热词背后：用户看到的速度，内核欠的账

6.1 启动时间不是一块盘的独角戏

回到开头那些热词。有人搜 E5 平台 NVMe 跑 Win10 启动要多久，有人搜怎么往旧镜像里塞驱动，有人搜固态格式化。这些问题的共同点，是用户把"快"简单地等同于"盘快"。实际上启动时间有一大半花在 UEFI 固件、设备初始化、驱动加载和 PCIe 链路训练上，NVMe 的裸顺序读速度早在启动阶段就用不着。内核里 CMB 到 DMA-BUF 的接口之争也是一样：技术方案好不好，由整个链路决定，而不由某一个寄存器决定。

你可能会问，这和 CMB dma-buf 有什么关系？关系大了。CMB 如果做得好，可以把命令提交的门铃延迟压下去，让控制器响应更快；做得不好，反而会让驱动为了兼容 CMB 多绕几层跳转，整体变慢。用户感知到的"快"，是无数个这样的小决策共同堆出来的。

6.2 格式化、驱动注入和命名：都是"接口"的表象

再往深一层，/dev/nvme0n1p5、NTLite 注入驱动、格式化对齐，这些都是"接口"的表象。命名是内核 block 层和 nvme 驱动把控制器、Namespace、分区三层结构翻译给用户；驱动注入是操作系统在引导早期找到存储设备之前的鸡生蛋问题；格式化对齐是文件系统和闪存页、块之间的对齐问题。CMB 到 DMA-BUF 的接口之争，本质上也是同一件事：怎么把控制器的能力安全、高效、可维护地交到上层手里。

如果你只是普通用户，那这三个热词对应的操作照着做就行。但如果你也写内核驱动，或者做上层存储架构，我建议你多想想接口设计的共性问题：谁拥有资源、谁分配、谁回收、生命周期怎么对齐、安全边界怎么画。CMB 只是这些问题的又一个具体样本。

6.3 这场接口之争最终会以什么形式落到你手上

以后你在内核邮件列表里看到nvme: add cmb dma-buf support这类补丁标题，先别急着夸，按我上面那套 checklist 过一遍。至少要问三个问题：它导出的到底是门铃区域还是数据缓冲？它怎么处理控制器 reset？它有没有绕过 IOMMU？这三个问题能过滤掉九成看着漂亮、落地就翻车的方案。

我自己在实验室里折腾过一段 CMB 做门铃旁路的原型。结论是：门铃旁路确实能把命令提交延迟压下去几十纳秒，但那点收益在真实业务里几乎被驱动栈其他部分的开销稀释干净。反而是 P2P 数据路径带来的吞吐提升，一测就看得见。所以我的建议很明确：数据走 P2P，CMB 留给控制器自己，别没事找事把它包装成通用 dma-buf。如果哪天你的场景真需要控制器内存出现在 importer 的地址空间里，再回来把那条窄接口做扎实，你绕过的每一个通用抽象，都是将来替你省掉的一次维护噩梦。