LWN：新的 DMA-mapping API！

关注了就能看到更多这么棒的文章哦～

A new DMA-mapping API

By Jake Edge
May 15, 2025
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/1020437/

Leon Romanovsky 在 2025 年 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF) 峰会 的会议上开始发言，解释了他一直在改进的 DMA-mapping API (DMA 映射 API) 是一项集体努力。他、Chaitanya Kulkarni、Christoph Hellwig、Jason Gunthorpe 和其他人正在提议对该 API 进行现代化改造，并“使其更适合当前的 kernels (内核)”。他告诉与会的 storage (存储) 和 filesystem (文件系统) 开发者，这项提案的进展已经停滞，但它是许多领域进一步工作的基础，因此他希望能找到推进它的方法。

现有的 DMA API (DMA API) 是基于 struct page 的，这很好，但使用 DMA 需要 scatter-gather (SG) lists (分散收集列表，简称 SG list)，因此在这两种 formats (格式) 之间存在大量的转换。此外，许多 DMA users (DMA 用户) 有他们自己的数据传输 formats (格式)，这导致了更多的转换（在 SG lists 和原生格式之间）。

一个 struct scatterlist 有两个 fields (字段)，分别应该包含一个 CPU address (CPU 地址)（=page_link=）和一个 DMA address (DMA 地址)（=dma_address=），但对 scatterlist 的各种 (滥) 用改变了这些 fields 的含义。他说，对于 peer-to-peer DMA (点对点 DMA)， page_link 是一个合成的 CPU address ，用于从 page structure (页结构) 中获取信息。对于 dma-buf (DMA buffer，dma-buf) 的使用， page_link 为空，而 dma_address 是合成的，以便访问 device-private memory (设备私有内存)。Hellwig 指出，根据 documentation (文档)，dma-buf 的使用是明确无效的，但“dma-buf 的开发者无论如何反正就是这么做了，并且拒绝修复”。

因此，该 proposal (提案)（在峰会期间是 v7 版本，但现在是 v11 版本）“非常简单”，Romanovsky 说。有一套新的 API (API) 是基于对 DMA-mapping API 的精心重构；它的设计目标是与现有 API 在 bug (错误) 方面兼容。DMA users 将不再需要使用 SG lists ，而是能够直接管理他们自己的 I/O virtual address (IOVA) space (I/O 虚拟地址，简称 IOVA)，这由 I/O memory-management unit (IOMMU) (I/O 内存管理单元，简称 IOMMU) 提供。新 API 将针对使用 IOMMU path (IOMMU 路径) 的 DMA 进行优化；没有 IOMMU 的 systems (系统) 可以退回到使用现有 API。

他简要描述了该 API ，它在去年 11 月的一篇 LWN article (LWN 文章) 中有更全面的描述。它首先调用 dma_iova_try_alloc() 来分配 IOVA range (IOVA 范围)，然后调用 dma_iova_link() 来将 memory (内存) 映射到该 IOVA range 中。一旦所有相关的 memory 都被 mapped (映射)，就可以调用 =dma_iova_sync()=；与其在每次 mapping 时都进行 synchronization (同步)，这是一种优化，只对整个 IOVA range 进行一次开销很大的 synchronization operation (同步操作)。

Romanovsky 说，他和 Hellwig 将三到四个 subsystems (子系统)（“取决于你怎么算”）转换为使用新 API，作为 patch set (补丁集) 的一部分。其中最容易理解的是 virtual function I/O (VFIO) (虚拟功能 I/O，简称 VFIO) 的 live-migration (在线迁移) 代码。他展示了修改前后的代码；目前有三个独立的 loops (循环) 遍历表示大块 memory 的冗长的 SG lists ，这“仅仅是为了确保我们获得可以用于 program (编程) hardware (硬件) 的 DMA addresses 而进行的巨大工作量”。使用提议的 API，如果可以使用优化的 path ，这将在一个 loop 中完成；如果不能，它将回退到现有的 mechanism (机制)。

这项工作是大型 roadmap (路线图) 的一部分。其想法是最终为 dma-buf 以及其他 DMA users 移除 SG lists 的使用。目前这个 roadmap 只是一组 ideas (想法)，在新 API 等待期间，尚未进行具体的 work (工作)。

但他展示了 DMA maintainer (DMA 维护者) Robin Murphy 的 response (回复)，这让 Romanovsky“不清楚现在该如何进行”。早些时候在 thread (讨论串) 中，Murphy 明确拒绝 了这些 patches (补丁)，但在 Romanovsky 看来，没有“未解决的 technical objections (技术反对意见)”。他强调了 Murphy 在 thread 中最后一封 email (电子邮件) 的结尾句子，这句话似乎并没有指向一个 resolution (解决方案) 的方向：

And there is no obligation for maintainers to accept code with obvious significant issues just because they don't have the time or inclination to personally engage in trying to fix said issues.

Dan Williams 建议打破僵局的一种方法是指出开发者们想要哪些被阻止的 features (功能)。例如，一些 confidential computing (可信计算) features 正被阻止，等待新的 DMA API。简单地列出放弃使用 SG lists 的更多计划并不能证明需要这些 changes (更改) 的 use cases (用例)；Williams 建议让这些 use cases 更加清晰可见，以“极其清楚地”表明新 API 的必要性。

David Howells 说，他期待着从 crypto layer (加密层) 中移除 SG-list 的支持。在使用 DMA 加密和解密 network traffic (网络流量) 时，存在大量不必要的 SG-list 创建；他认为 crypto layer 的实际操作并不需要 SG lists。James Bottomley 说，SG 处理 是为了支持 crypto accelerators (加密加速器) 而存在的，而“几乎没有人”拥有这些设备；crypto 开发者 认为支持 SG lists 是一个错误，因为 accelerators 很少。Hellwig 说，确实有一些 accelerator drivers (加速器驱动) 使用 SG lists，但许多 crypto 开发者希望移除这一功能功能；不幸的是，他说，crypto maintainer 希望用一个更复杂的接口 来取代它。

Chuck Lever 说，新 API“看起来非常好，我迫不及待地想真正使用它”。他指出，他是“RDMA rw interface (RDMA 读写接口)”的 maintainer (维护者) 之一，并问 Hellwig 是否会将其改为使用新 API。Hellwig 说，这当然应该改变，但他没有时间或 hardware 来做；他愿意帮助任何想做这项工作的人，并认为这只需要几天的努力。

Luis Chamberlain 问 Romanovsky 是否能“尽他所能地”描述 Murphy 对该 patch set 的 objection (反对)。长时间的停顿后，Romanovsky 说：“老实说，我不知道”；他说他曾试图从回复中找到“任何合理之处，任何我们可以采取的 action item (待办事项)”，但都无能为力。Hellwig 说存在“很多细微的 nitpicks (细节问题)”，他不确定是否属实；如果属实，需要更好地描述。Murphy 总体上的 objection 是“它将过多的 low-level knowledge (低级知识) 推给了 DMA API 的使用者”，Hellwig 说。但 Gunthorpe 说，这正是新 API 的重点；Hellwig 表示同意，并指出 Murphy 的反对“至少是部分有效的”，尽管他不同意。

Williams 问，开发者们需要什么样的帮助；“是仅仅‘用 use cases 淹没这个领域’，还是‘提供一个 wrapper API’？”。Hellwig 说，在为各种 users 添加支持方面的工作一直在添加 wrappers (封装)，使其更容易使用，并将 low-level details (低级细节) 从驱动中隐藏起来；这项工作旨在成为一个构建模块，允许 subsystems (子系统) 为 DMA 使用它们特定的 data structures (数据结构)，而不是让 drivers 个别处理这些细节。

Gunthorpe 同意，让人们提交他们的 use cases 和他们对使用该功能的兴趣将会很有用，这对 Murphy 和另一位 DMA maintainer Marek Szyprowski 都有帮助。他说，没有人建议忽略 Murphy 的抱怨，但 DMA interface (DMA 接口) 的各种 user 正在强力推动这些更改。也许看到更多的 use cases 会鼓励 Murphy 花更多时间在这上面。Williams 认为这是一个好的方向，并建议“所有人都来发表意见，但要友善”。

截至五月初，Szyprowski 已经 将 patches 合入 了他的 dma-mapping-next branch (dma-mapping-next 分支)，这大概是为了将新 API 合入 6.16 kernel (6.16 内核)。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～