dma_map_ops三种实现方式详解：direct、IOMMU与自定义映射

搞DMA映射的时候，dma_map_ops这个概念迟早会撞到你脸上。我最早看这块代码时也是一头雾水：不就是设备要块内存让硬件去读写吗，为什么要套这么多层函数指针？直到自己写了一个需要私有DMA池的驱动，才真正搞明白这套抽象的价值。这篇文章就把dma_map_ops实现的三种方式讲透，包括各自的使用场景、内核里的触发路径，以及调试时怎么确认当前设备到底走的哪套逻辑。内容比较贴近内核源码，适合BSP工程师、驱动开发者和对DMA子系统感兴趣的人，看过之后至少能少翻两三个小时的源码。

1. dma_map_ops到底是什么，为什么需要它

先看定义。在include/linux/dma-map-ops.h里，dma_map_ops是一个巨大的函数指针结构体，里面挂着alloc、free、map_page、unmap_page、map_sg、unmap_sg、dma_supported、get_sgtable等一大票回调。设备驱动调用dma_alloc_coherent、dma_map_single这类API时，最终都会通过这个结构体里的函数指针转发到具体的实现上。

有人可能会问，直接让驱动调硬件操作不就行了，搞一层间接寻址不是多此一举吗？举个例子：一个SoC上的USB控制器和GPU，前者可能走SMMU/IOMMU做地址映射，后者则因为历史原因直接访问物理地址。如果驱动里写死某一种映射方式，换一颗芯片或者换一种总线拓扑，驱动就得改。dma_map_ops把“映射逻辑”和“调用方”解耦，驱动只跟通用API打交道，底层映射策略由内核根据硬件能力、设备树属性、使能的IOMMU状态来决定。

内核里实际存在的实现方式很多，但抽象到实现思路上，主流就是三种：

• 直接映射：DMA地址等于物理地址（或者只是简单偏移），不需要IOMMU干预。
• IOMMU辅助映射：通过SMMU/IOMMU建立设备视角的I/O虚拟地址，把分散的物理页映射成连续的DMA地址。
• 自定义专用映射：驱动或平台自己注册一套dma_map_ops，覆盖默认行为，典型场景是私有DMA池、特殊地址约束、ZONE_DMA之外的内存管理。

这三种方式没有绝对的优劣，只有合不合适。直接映射最快但受限于地址连续性，IOMMU映射灵活但有TLB开销和页表维护成本，自定义映射最灵活但要求你非常清楚自己在干什么。

2. 三种实现方式的细节拆解

2.1 直接映射实现

直接映射的内核实现主要在kernel/dma/direct.c，对应dma_direct_ops和dma_noncoherent_ops这两个全局实例。名字里的direct很直白：phys_to_dma直接做运算，没有页表、没有IOMMU翻译，CPU看到的物理地址和DMA地址之间是线性关系。

怎么个线性关系？内核里dma_to_phys和phys_to_dma默认就是加上或减去一个全局偏移量。很多ARM32平台没有IOMMU，总线地址和物理地址完全一致，dma_addr_t就是phys_addr_t。这时候dma_map_single做的事情就非常“薄”：检查地址范围是否合法（比如是否落在设备可访问的DMA窗口内），然后做必要的cache维护，剩下的就是把物理地址原样返回。

为什么还分dma_direct_ops和dma_noncoherent_ops？关键在于cache coherence。如果设备是coherent的，CPU和DMA看到的是同一条cacheline，硬件帮你保证一致性，那就不需要软件介入。但绝大多数嵌入式平台的外设并不是硬件coherent，DMA可能会读到CPU cache里的旧数据，所以dma_noncoherent_ops比direct_ops多了arch_sync_dma_for_device和arch_sync_dma_for_cpu的调用，也就是常见dma_map_single里的cache clean/invalidate。

这里有个经典误区：直接映射并不等于不需要sync。很多人看到dma_direct_ops里的map_page就一个函数，以为啥都没做，实际上它会根据dev_is_dma_coherent判断是否需要做cache同步。之前我调一个网卡驱动，收发数据偶发错包，bullshit半天最后发现DMA mask设置没问题，问题出在驱动漏了dma_sync_single_for_cpu，CPU读的数据还是cache里的旧值。

直接映射的优势是路径极短、延迟低，没有TLB一致性负担，也不需要IOMMU硬件支持。缺点同样明显：设备必须能访问整个物理地址空间，或者说至少能覆盖你分配的内存所在区域，而且它没法解决外部DMA控制器只能用32位地址、但系统内存超过4G的场景。

2.2 IOMMU辅助映射实现

第二种是依赖IOMMU的映射，内核实现主要在kernel/dma/iommu.c，对应dma_iommu_ops。它的工作方式和直接映射完全不同：驱动调dma_map_single时，内核会通过iommu_dma_alloc_iova分配一块I/O虚拟地址范围，然后为这段虚拟地址建立页表，把物理页映射进去。返回给驱动的是IOVA，不是物理地址。

这么做的好处很明显。一是可以把物理上不连续的页面映射成DMA视角下连续的地址块，这对那些要求DMA描述符地址连续的控制器特别有用。二是可以隔离设备的内存访问，设备只能看到它被授权的IOVA范围，访问越界直接触发IOMMU fault，而不是悄悄破坏内核数据。这在虚拟化场景里几乎是必需品。

实现路径上的关键函数包括iommu_dma_map_page、iommu_dma_map_sg等。内核会使用IOMMU domain的iommu_map/unmap接口处理页表，同时会考虑IOMMU的输入地址粒度（typical page size）、地址宽度、是否支持superpage等能力来优化映射。

IOMMU映射不是免费的午餐。每次map/unmap都有页表操作，sg映射还需要做合并判断，频繁短小DMA会导致明显的性能开销，所以内核提供了iommu_dma_alloc_iova + iommu_dma_protect等机制做IOTLB缓存。实际项目里如果追求大流量下的DMA性能，一是尽量复用已映射的缓冲区而不是频繁map/unmap，二是查看IOMMU是否支持并启用了大页映射。

另外，不是有IOMMU就一定走dma_iommu_ops。内核会在设备初始化阶段检查IOMMU是否已经为这个设备创建了default domain，如果没有或者被显式绕过，就会fallback到其他ops。后面第3节细说切换逻辑。

2.3 自定义专用实现

第三种是自定义实现，也就是驱动或平台自己填充一个dma_map_ops结构体，然后通过dma_ops指针挂到设备上。这种方式在通用内核里不多见，但存在两类典型场景。

第一类是设备有非常特殊的内存需求，比如DMA引擎希望buffer放在某个固定的SRAM区域，或者要求物理地址满足某些对齐约束，而通用DMA层无法表达。此时驱动可以在probe里拿到platform_device的dma_ops，覆盖其中若干回调，或直接替换成自己实现的ops。内核里有不少老式DMA控制器驱动就是这么干的。

第二类是虚拟化/半虚拟化场景下的前端驱动。虚拟设备不能直接操作物理地址，需要用一套特殊的映射规则来同步内存，比如Xen的xen_swiotlb_dma_ops就把DMA操作重定向到swiotlb bounce buffer上。虽然最终还是要借助swiotlb或IOMMU落地，但从架构看，它确实是完全自定义的一套dma_map_ops。

自定义实现的注意事项很多，挑几个关键的：

• 回调必须实现完整。Linux内核不会因为你没填sync函数就报错，但运行时行为会莫名其妙。比如只填了map_page没填sync，DMA方向和缓存维护就没人管了。
• 要处理好dma_mask和dma_ops的关系。很多时候自定义ops配上一个过小的dma_mask，会让上层的DMA API直接返回错误。
• 如果覆盖了alloc/free，要注意默认dma_alloc_coherent走的是dev->dma_mem的pool，还是全局的atomic pool，不要和默认行为打架。

我自己写自定义ops时踩过一个坑：没有在free回调里把dev->dma_mem标回空闲状态，导致驱动反复卸载加载后DMA内存越用越少，用kmemleak也查不出问题，最后发现是私有pool没有正确回收。

3. 内核是怎么决定用哪种方式的

这几种ops不是驱动自己选的，是内核在设备探测阶段根据硬件配置和内核参数推出来的。搞清楚这个流程，比背源码要有用得多。

设备什么时候绑定dma_ops？在device的probe路径上，具体来说是在dma_configure里。ACPI和DeviceTree两套描述方式都会走这个函数。内核会先看设备是否关联了IOMMU，再看IOMMU domain是否创建成功，最后再判断平台是否强制使用swiotlb或直接映射。

大致决策顺序可以理解为：

1. 判断设备是否已经绑定了driver-specific的dma_ops，如果绑了，直接用驱动自己的。
2. 判断IOMMU是否可用，且设备是否已经attach到IOMMU domain。如果可用，dma_ops设为dma_iommu_ops。
3. 判断平台是否支持direct映射，并且dma_mask合理。如果支持，就设置为dma_direct_ops或dma_noncoherent_ops。
4. 都不满足，使用swiotlb作为最后的fallback。在x86上如果内存超过4G又没有IOMMU，大概率会走这段路径。

判断IOMMU是否可用的具体函数是arch_setup_dma_ops，ARM64下调用acpi_dma_configure或of_dma_configure时，会解析iommu-map或iommus属性，进而调用iommu_probe_device。如果IOMMU probe成功，会把dev->dma_ops覆盖为iommu_dma_ops。如果IOMMU初始化失败或者没有对应的fwspec，就会落回direct。

留一个检查小技巧：在设备probe之后，可以在驱动里打印dev->dma_ops指针，并对比它等于哪个全局ops。也可以查看/sys/kernel/debug/iommu/下面的domain信息，看设备是否真的attach在IOMMU上。比起读代码，这一步能直接告诉你设备实际走了哪条路。

还要提一下dma_mask的作用。不论怎么确定ops，dma_map_page这类API的入口会有dma_capable检查，如果地址超出了设备的dma_mask，直接映射会失败，IOMMU映射则会尝试用swiotlb bounce buffer或直接返回错误。这也是为什么很多平台明明有IOMMU，某些分配依然走了swiotlb。

4. 切换逻辑里的隐藏细节与过滤条件

实际看到的代码不会像我上面描述得那么干净，因为内核还要处理很多过滤条件。最常见的就是DMA范围限制、ZONE_DMA和platform bus上的特殊设备。

在ARM64上，如果SoC的某些外设只能访问低端内存，即使有IOMMU，内核也可能不使用完整IOVA空间，而是把IOVA范围限制在设备允许的DMA范围内。这个范围来自device-tree里的dma-ranges属性或ACPI的_DMA方法。IOMMU domain创建时会对IOVA分配器做限制，超出范围的映射会直接失败，而不会静默帮你绕过。

还有一个容易忽略的是iommu=pt这种内核参数。如果使能了pass-through模式，即使IOMMU硬件存在，内核也不会为设备建立IOVA映射，dma_ops会跳过iommu_dma_ops，直接回到direct映射。这是为了性能或调试IOMMU问题时常用的手段，但也意味着你失去了IOMMU的地址隔离保护。

另外，dma_map_ops里还有一个名为get_merge_boundary的回调，用来指示DMA合并能力。IOMMU映射下可以把页表连续的内存合并成更大的DMA段，direct映射则受限于物理连续性。很多驱动调blk_queue_max_segment_size设置最大合并段时，如果不了解底层ops的能力，配出的参数可能偏保守或偏激进。

再具体一点，dma_direct_alloc实现里会判断是否使用CMA、是否要保证32位地址，以及是否需要在atomic context下分配。这些逻辑集中在kernel/dma/direct.c的__dma_direct_alloc里。对照dma_iommu_alloc的实现，差距非常明显：iommu版本多了iova分配、页表映射、prot计算，代码路径长很多。测量DMA分配耗时的话，direct方式通常在亚微秒级，iommu方式在微秒级甚至更高，具体取决于TLB和页表cache的状态。

5. 实操验证与调试方法

单看源码很容易绕晕，我建议的做法是直接写一个小驱动来验证当前平台走的是哪种ops。下面这段代码在probe时打印关键信息，能快速定位路径。

#include <linux/init.h> #include <linux/module.h> #include <linux/platform_device.h> #include <linux/dma-mapping.h> static int ops_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; const struct dma_map_ops *ops = get_dma_ops(dev); dev_info(dev, "dma_ops: %p\n", ops); if (ops == &dma_direct_ops) dev_info(dev, "using dma_direct_ops\n"); else if (ops == &dma_noncoherent_ops) dev_info(dev, "using dma_noncoherent_ops\n"); else if (ops == &dma_iommu_ops) dev_info(dev, "using dma_iommu_ops\n"); else dev_info(dev, "using custom ops\n"); dev_info(dev, "coherent: %d, mask: %llx\n", dev->dma_coherent, *dev->dma_mask); return 0; } static int ops_remove(struct platform_device *pdev) { return 0; } static struct platform_driver ops_driver = { .probe = ops_probe, .remove = ops_remove, .driver = { .name = "ops-probe", }, }; module_platform_driver(ops_driver); MODULE_LICENSE("GPL");

在设备树里加一个compatible为"ops-probe"的节点，加载驱动后看内核log就能知道当前的ops。如果显示using custom ops，再用address-of运算符对照源码里的全局变量地址，基本能定位到具体是哪个实现。

还有一个debugfs入口值得看。很多IOMMU驱动会在/sys/kernel/debug/iommu/下面暴露domain和设备的关系。查看设备是否在某个domain的device列表中，可以判断IOMMU路径是否真正生效。

遇到DMA报错时，比如IOMMU fault或者data abort，查日志里的地址信息能反推是IOVA还是物理地址。IOVA地址一般在设备使用的地址窗口内，物理地址则可能落在系统RAM范围内。这个区分能帮你判断是哪一段映射出了问题。

6. 三种方式的性能对比和选型建议

直接说结论：对性能极其敏感、DMA描述符短小频繁的场景，direct映射是最好的；需要大块连续DMA缓冲区、但物理内存碎片化严重时，IOMMU映射更靠谱；特殊内存布局或虚拟化场景，只能走自定义ops。

从实测数据看，在ARM64平台上做PCIe网卡DMA测试，direct路径的单次map/unmap开销大约在100ns量级，IOMMU路径则在1us量级，而且IOMMU路径在IOTLB miss时会有一个明显的等待。这个差距在高吞吐场景下会被放大，因为每个网络包都可能触发map/unmap。

选型建议可以总结成一张表：

需要强调：别一上来就追新追复杂。项目里如果direct方式能满足地址窗口需求，就别强行引入IOMMU，IOMMU页表缺失导致的fault排查比普通DMA错误难一个量级。

7. 常见问题与排查技巧实录

实际操作中最多的问题集中在cache一致性、地址越界和ops误匹配上。下面列几个高频场景。

7.1 DMA数据错乱，表现为偶发跳变

这是典型的cache coherence问题。dma_noncoherent_ops路径下，map后、unmap前必须有对应的cache clean/invalidate操作。如果你看到驱动里既没调dma_sync_single_for_device，也没在map/unmap里做同步，就要怀疑这个问题。加打印确认设备dma_coherent是否为0，若为0则必须在合适位置补sync调用。

7.2 设备收到总线错误或IOMMU fault

先分清楚是IOVA fault还是物理地址越界。IOMMU fault日志里通常会带device、domain和fault地址。如果fault地址是随机值且很大概率不属于任何IOVA区间，多半是DMA描述符里填了CPU物理地址而不是dma_addr_t。这种情况在驱动从dma_alloc_coherent换成dma_map_single时最容易犯，返回值一个是内核虚拟地址、一个是DMA地址，别搞混。

7.3 dma_alloc_coherent返回NULL，但系统内存明明充足

检查dma_mask是否太小。dma_alloc_coherent默认会试图满足mask要求，如果mask是32位而系统内存全在4G以上，又没配CMA区域，直接映射大概率分配失败。可以在内核cmdline加coherent_pool=增大原子池，或者使用dma_set_mask_and_coherent设置更宽掩码。如果平台支持，也可以考虑走IOMMU路径来扩展地址范围。

7.4 驱动里改ops不生效

有些驱动尝试在probe里直接写dev->dma_ops来覆盖默认行为，结果却还是老路径。原因是dma_configure和dma_ops设置可能发生在bus的probe早期，你的赋值可能被后面覆盖。正确做法是使用dma_map_ops机制里允许的钩子，比如通过iommu_set_dma_domain来设置domain，或是在platform_driver的probe之前用bus_notifier介入，而不是简单赋值。

7.5 怎么确认swiotlb是否被使用

看内核log里有没有类似“Using IOMMU for DMA”或“no DMA zone”之类的字样。也可以直接读dmesg里的swiotlb初始化信息。如果设备和dma_ops显示direct路径，但dma_map_single却出现bounce buffer行为，说明平台把swiotlb强制开启。大部分情况下这是由内存布局或内核参数决定的，驱动层面很难绕开。

8. 给新手的上手路径建议

如果之前没接触过DMA映射层，直接啃dma-map-ops.h头文件容易劝退。我的建议是按照“从API到实现，再从实现回到API”的顺序来学。

先熟读Documentation/core-api/dma-api.rst，搞清楚dma_map_single、dma_alloc_coherent、dma_map_sg这几个高频API的语义和调用时机。然后打开kernel/dma/direct.c，通读dma_direct_map_page和dma_direct_alloc两个函数，再用gdb或ftrace对比走IOMMU时对应函数路径的差异。最后再回看dma_map_ops结构体，你会发现每个回调的含义都变得具体了。

实践层面，最推荐的方式是拿一个支持IOMMU的开发板，分别在内核cmdline加和不加iommu相关参数，跑同一个DMA驱动，观察log和性能差异。这种对比实验能让你一次性理解三种方式的边界。

我个人的体会是，dma_map_ops这套抽象虽然初看很绕，但一旦理解成“把DMA地址翻译策略做成可插拔模块”，整个内核DMA子系统就豁然开朗了。后续再看网卡、显卡、音频等驱动里的DMA相关代码，基本都能一眼看穿它走的是哪条路。