有段时间我被一个问题折腾得够呛一台 196GB 内存的服务器插着一张很常见的板载千兆网卡跑着跑着 dmesg 里突然冒出一串Out of SWIOTLB memory然后网卡直接瘫痪网络中断。那天晚上我翻了三个多小时内核代码才算把 SWIOTLB 这个既透明又无处不在的组件彻底搞清楚。后来做机密计算相关的项目又发现 AMD SEV、Intel TDX 的环境里SWIOTLB 几乎成了 DMA 路径上的必经之地地位比很多人以为的重要得多。这篇文章就把我从 DMA 基础概念、SWIOTLB 工作原理、参数调优一路到机密计算场景下的完整理解写下来适合正在追 DMA 报错的内核开发者、搞虚拟化和机密计算的平台工程师以及想弄明白“为什么 dma_map 会慢”的驱动开发者。1. 从 DMA 到 SWIOTLB这块“软件缓冲区”到底解决什么问题1.1 DMA 的本职工作与三种典型失败DMA 的全称是 Direct Memory Access说白了就是让外设绕过 CPU 直接读写内存。CPU 只要把要传输的缓冲区的物理地址告诉设备设备就能自己把数据搬进搬出搬完了再发个中断通知 CPU。这个机制省掉了 CPU 逐字节复制是网卡、磁盘控制器、GPU、USB 控制器等外设高性能工作的基础。但 DMA 有一个前提设备得“够得着”你给它的那块内存。这里会碰见三类经典问题寻址位宽限制。很多设备只有 32 根地址线只能访问 4GB 以下的内存。但服务器内存动辄几十 GB、上百 GB驱动分配出来的 sk_buff、bio buffer 很可能落在 4GB 之上设备一读就是错误地址。没有 IOMMU。IOMMU 相当于给设备加了一层地址翻译和隔离能把设备访问的 IOVA 映射到任意物理地址。但嵌入式平台、老式 x86 板子经常没有 IOMMU或者驱动压根没走 IOMMU 路径。内存加密。SEV、TDX 这类机密计算场景下内存内容是用客户机密钥加密的设备去读读回来全是一堆密文根本没法用。设备访问内存必须是“共享”或者“未加密”的页面。这三种情况本质上是同一个问题软件手里有一块内存但设备直接读不了。怎么办最直接的办法就是在设备能访问的区域里先准备一块“中转”内存把数据先搬到那里再让设备去操作。这个中转机制就是 SWIOTLB。1.2 名字里有 TLB但它不是 TLBSWIOTLB 全称 Software Input Output Translation Lookaside Buffer中文社区一般叫“软件 IO 地址翻译后备缓冲区”或者干脆叫“软 TLB”。第一次看见这个名字的人很容易误会以为它和 CPU 里的 TLB 一样是做虚拟地址翻译的。CPU 的 TLB 是硬件组件负责缓存虚拟地址到物理地址的映射。SWIOTLB 里面虽然带着 Translation 这个词但它不翻译任何地址它干的活是把数据复制到一块预先保留好的、设备可访问的物理内存区域里然后把这块区域的物理地址交给设备。换句话说它用“拷数据”代替“转地址”本质是一个 bounce buffer弹跳缓冲区。之所以叫 TLB纯粹是历史原因早期内核开发者把这块保留内存看成某种“IO 地址映射表”的替代品。理解到这一层再看代码里的swiotlb_*函数就不会懵了。1.3 它和 IOMMU 是竞争还是互补很多人会问都上 IOMMU 了还要 SWIOTLB 干嘛答案是两者解决的问题不完全一样。IOMMU 解决的是“地址可达性”把设备的 IOVA 翻译成任意物理地址设备只需要访问一段连续的 IOVA 就行。SWIOTLB 解决的是“数据可见性”当设备访问的内存内容对它来说不可见、不可解时只有把数据搬到设备能正确处理的区域硬件层面的“隔阂”才能消除。在机密计算场景里IOMMU 可以把 IOVA 映射到客户机的共享内存但共享内存里的数据如果是加密的IOMMU 也帮不了你解密。所以哪怕是 IOMMU 正常工作SWIOTLB 依然可能被强制启用。这个后面第四章会展开。2. 核心机制缓冲池设计、槽位管理和一次 DMA 搬运的完整过程2.1 内存布局与数据结构SWIOTLB 在内核启动早期就从物理内存里保留一块连续区域这部分内存叫作io_tlb_mem。每个io_tlb_mem底下有若干io_tlb_slot每个 slot 是固定大小的槽位。关键参数先列出来参数值说明IO_TLB_SHIFT11slot 大小 2^11 2048 字节IO_TLB_SIZE2048最小对齐粒度IO_TLB_SEGSIZE128一次映射最多占用的连续 slot 数默认缓冲池大小64 MiB即 32768 个 slot内核配置开关CONFIG_SWIOTLBx86、arm64 等主流架构默认开启代码层面最核心的三个结构是struct io_tlb_mem保存整个缓冲池的基地址、slot 数组、索引、剩余可用 slot 数、水位线等全局状态。struct io_tlb_slot每个槽位有一个list链表节点用于维护空闲槽位链表还有一个orig_addr字段记录这个槽位当前对应的原始缓冲区地址dma_unmap时要靠它把数据拷回原来的位置。mem-pool数组用于快速管理不同对齐需求的槽位分配。启动时内核会打印一段类似下面的日志告诉你 SWIOTLB 已经映射好$ dmesg | grep -i swiotlb [ 0.000000] software IO TLB: area num 1, size 64.00 MiB, mapped at 0x00000000fed00000看到size 64.00 MiB就知道默认池已经建好了。2.2 一次 dma_map_single 的完整旅程驱动想给设备传数据一般不会直接写寄存器给物理地址而是调用 DMA APIdma_addr_t dma_map_single(struct device *dev, void *buf, size_t size, enum dma_data_direction dir);这个函数内部最终会走向dma_direct_map_page。当内核判断当前设备的 DMA mask 无法覆盖缓冲区地址、或者 SWIOTLB 被强制启用时就会进入swiotlb_map路径。完整过程可以拆成六步获取原始缓冲区信息。拿到buf的物理地址和长度。检查是否需要 bounce。如果设备本身就能直接访问这块内存直接返回物理地址SWIOTLB 完全不参与。查找空闲槽位。swiotlb_tbl_map_single在io_tlb_mem里找一段足够长的连续空槽。因为 DMA 设备拿到的必须是物理上连续的内存所以至少得凑够size/2048向上取整个槽位。复制数据。如果数据传输方向是DMA_TO_DEVICECPU 往设备写内核直接把原始缓冲区的内容memcpy到 SWIOTLB 槽位里。如果方向是DMA_FROM_DEVICE设备往内存写这一步不复制等设备写完之后在 unmap 阶段再拷回。返回 SWIOTLB 物理地址。驱动拿到的是 SWIOTLB 槽位的地址不是原来的buf地址。unmap 时反向搬运。dma_unmap_single时对于DMA_FROM_DEVICE内核把槽位里的数据复制回原始缓冲区同时把槽位释放回空闲链表。所以dma_map_single慢很多时候不是 DMA API 本身慢而是 SWIOTLB 多了一次内存拷贝。网络收包时每包都要 copy吞吐一大开销立刻暴露。2.3 为什么 slot 是 2KB默认 64 MiB2KB 这个数字不是拍脑袋定的。历史上 DMA 设备常见的 descriptor、磁盘扇区、网络包缓冲区很多都按 2KB 对齐或做整数倍分配。2KB 粒度既能把内存浪费控制在可接受范围又能减少分配大段连续内存的失败概率。默认 64 MiB 则是个折中。太少了高吞吐场景容易耗尽太多了这 64 MiB 是启动时一次性保留给 SWIOTLB 的平时不用就白白浪费。64 MiB 在 64 位系统上不算大又能撑住绝大多数虚拟化场景的 DMA 压力。内核还限定了一次 DMA 映射最多占用 128 个连续 slot也就是单次映射最大 256 KiB避免一个驱动一次性把整个缓冲池占光。3. 参数调优与动态扩容把 SWIOTLB 调到跟你的场景匹配3.1 内核参数与配置项SWIOTLB 的可调参数主要写在内核 command line 里简单总结如下内核参数作用典型用法swiotlbforce强制所有 DMA 都走 SWIOTLB即便设备可以直接访问调试、验证功能swiotlb256指定 SWIOTLB 缓冲池大小为 256 MiB高吞吐压力场景swiotlboff尝试关闭 SWIOTLB仅在确定设备不需要且无加密场景时用部分架构不保证生效iommuswiotlb让 IOMMU 路径强制回退到 SWIOTLB排查 IOMMU 相关 DMA 问题CONFIG_SWIOTLB_DYNAMIC编译选项开启动态扩容5.19 内核默认在部分架构上开启swiotlbforce是排查问题时的老朋友。它能把所有 DMA 流量都压进 SWIOTLB方便你观察缓冲池压力配合 trace 事件能快速确认“到底哪些驱动在走 bounce 路径”。但生产环境千万不要长期开性能会明显打折。3.2 Linux 5.19 之后的动态 SWIOTLB老版本的 SWIOTLB 是“一次分配终身使用”。启动时保留 64 MiB之后无论压力多大池子就那么大满了就打印Out of SWIOTLB memory。这对嵌入式或者内存紧张的场景很不友好。Linux 5.19 引入了动态 SWIOTLB 机制。简单说当默认池用完时内核会尝试从系统的可用内存里再划分出一块新的io_tlb_mempool追加进去动态扩充可用槽位。这带来两个实际好处默认配置下不用担心 64 MiB 不够因为压力上来后池子能自己长大。平时没压力时不会白白占用几十 MiB 的保留内存按需分配更符合容器化、资源受限环境的需求。动态 SWIOTLB 依赖CONFIG_SWIOTLB_DYNAMIC编译选项。遇到老内核上频繁的 SWIOTLB 耗尽除了调swiotlb大内存我一般还会看一眼发行版内核有没有开这个选项能不开新内核就不开。3.3 性能开销到底有多大SWIOTLB 本质上是用 CPU 拷贝换设备可达性所以它的开销最直观的体现就是 memcpy。实测中纯 CPU 大规模拷贝的吞吐很容易跑上 10 GB/s但 DMA 路径上的拷贝还有 cache 颠簸、TLB miss、内存屏障等额外成本。网络收包场景里一旦触发 SWIOTLB bouncePPS 吞吐跌个 30%~50% 是常见现象。我的优化经验按优先级排列先检查驱动是否正确设置了 dma_mask。很多设备明明支持 64 位寻址驱动却只设了 32 位导致内核误判设备够不着高地址走了 SWIOTLB。把dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))补上问题立刻消失。再用 IOMMU 解决地址碎片。没有内存加密需求时直接让 IOMMU 映射 IOVA比 bounce buffer 的 memcpy 划算得多。最后才考虑加大 SWIOTLB 池。加大只是缓解压力不会消除拷贝开销。4. 机密计算时代内存加密如何让 SWIOTLB 变成绕不开的路径4.1 SME/SEV/TDX 的内存加密语义机密计算的核心诉求是虚拟机运行时宿主机管理员、Hypervisor、甚至物理硬件上的其他软件都看不到客户机的敏感数据。AMD SME 在物理地址上拿一个专门的位置当作加密位C-bit置位后 CPU 访问这块内存会自动用系统密钥加解密。SEV 在此基础上进一步把加密粒度做到每台虚拟机独立密钥。Intel TDX 也是类似思路把内存划分成 private 和 shared 两类。问题来了设备发起 DMA 时访问内存用的是物理地址它可没有 CPU 那套加解密逻辑。如果客户机 DMA 缓冲区是加密的设备读出来的就是一堆密文。这时候要么让设备访问“shared”内存要么让 DMA 数据走一段特殊硬件路径否则数据根本没法用。4.2 机密虚拟机里的 DMA 数据流以运行在 SEV/TDX 虚拟机里的 virtio-net 为例。客户机驱动想要发包驱动调用dma_map_single映射 sk_buff。内核发现内存加密已启用且这块页面是 private 状态直接让设备访问会导致设备读到密文。于是走向 SWIOTLB把数据复制到共享/未加密的内存区域。设备或者宿主机侧的 vhost 后端从共享内存里读取明文数据。你可以在客户机里看到类似日志$ dmesg | grep -i swiotlb [ 0.000000] software IO TLB: area num 1, size 64.00 MiB, mapped at ...正常加密虚拟机启动后swiotlb几乎总是被强制启用这不是 Bug而是刻意设计。内核在检测到 SME/SEV/TDX 激活时会把swiotlb_force设置成强制模式保证所有 DMA 流量都先经过共享内存中转。这是 SWIOTLB 从“地址兜底”变成“机密计算必经之路”的根本原因。4.3 有了 IOMMU 为什么还是离不开 SWIOTLB在机密计算场景里IOMMU 依然在但它管的是地址翻译管不了加解密。即使 IOMMU 把设备的 IOVA 映射到了客户机的 shared 页面前提也得是那块页面本来就是未加密的。如果驱动拿了 private 页面去映射IOMMU 只会照常翻译地址数据内容还是密文。所以 SWIOTLB 和 IOMMU 在机密计算里是配合关系IOMMU 负责把设备地址翻译到正确位置SWIOTLB 负责把数据从 private 内存搬到 shared 内存。少了哪一个DMA 都没法正常工作。这里也解释了一个让很多人困惑的现象机密虚拟机里网络吞吐看起来比普通虚拟机差不少。因为每个包多一次完整的内存拷贝再加上页面属性切换的额外开销性能下降是实打实的。想在机密环境里优化 DMA唯一的出路是让驱动从一开始就分配共享内存比如 virtio 的VIRTIO_F_ACCESS_PLATFORM配合共享页分配能减少一部分 bounce 开销。5. 实战排查从报错信息到完整定位链路5.1 常见报错与含义SWIOTLB 相关报错其实不算罕见我把最常见的几个列出来报错内容含义常见原因swiotlb buffer is full (sz: 8192 bytes), total 65536 (slots), used 65536 (slots)缓冲池槽位耗尽驱动大量映射没及时 unmap或池子配小Out of SWIOTLB memoryDMA 映射失败与上一条同因DMA 层直接返回失败kernel: DMA-API: device driver maps memory ...DMA API 检测到异常驱动用法有问题开了 CONFIG_DMA_API_DEBUGswiotlb: coherent allocation failed一致性分配失败内存紧张或分配尺寸超过池子能力看到swiotlb buffer is full第一反应不是去调大参数而是先确认有没有驱动泄漏了 DMA 映射。DMA 映射和内存一样需要配对dma_map之后忘了dma_unmapSWIOTLB 槽位就永远被占着。5.2 案例一宿主机上大量磁盘 IO 触发 SWIOTLB 耗尽我之前处理过一个现场KVM 宿主机跑着十几个虚机某个时间段所有虚机磁盘 IO 大面积卡死dmesg 里一直刷Out of SWIOTLB memoryhost 上 SWIOTLB 用了 100%。当时我们假设是 SWIOTLB 池太小直接把swiotlb2048加上了结果只是把故障推迟了几小时。后来我用 ftrace 把 SWIOTLB 的事件抓出来发现罪魁祸首是某个自定义驱动它在中断上下文里做 DMA 映射但在完成处理后少调了一次dma_unmap_single。每次中断都泄漏若干槽位一天下来池子就空了。修复驱动后swiotlb64都稳稳的。排查这类问题建议按这个顺序来# 1. 确认当前 SWIOTLB 使用率 $ cat /sys/kernel/debug/swiotlb/io_tlb_used 32768 # 2. 抓 SWIOTLB 相关 trace 事件 $ echo 1 /sys/kernel/debug/tracing/events/swiotlb/enable $ cat /sys/kernel/debug/tracing/trace | grep swiotlb # 3. 配合 perf 看调用栈定位到底是哪个驱动在映射 $ perf record -e probe:swiotlb_tbl_map_single -ag -- sleep 10 $ perf report/sys/kernel/debug/swiotlb/目录下有io_tlb_nslabs、io_tlb_used、io_tlb_hiwater等文件能直观看到当前使用量和水位线是定位 SWIOTLB 压力最直接的入口。5.3 案例二rk3588 的 “failed to reset the DMA” 与 SWIOTLB 无关最近搜索 DMA 相关话题时发现 rk3588 的网卡驱动报failed to reset the dma是高频问题。这个报错很容易让人误以为和 SWIOTLB 有关毕竟都有 DMA 三个字母。实际上这是stmmac驱动在初始化硬件 DMA 控制器时复位操作超时导致的。常见根因是时钟没配好、PHY 芯片供电不稳、或者网卡工作在 promisc 模式下被硬件 bug 卡住这是 MAC 层面的问题跟 Linux 软件层面的 SWIOTLB 一点关系都没有。看到这类错误排查方向应该是检查设备树里clock-frequency、ref-clock配置。检查 PHY 的 reset GPIO 和供电时序。看stmmac初始化失败时打印的前置日志确认是 DMA reset 还是 MDIO 通讯异常。顺便说一句搜索“DMA”这个词时你会看到大量 STM32、GD32、串口 DMA、ADC 多通道 DMA 的内容那些是单片机裸机或 RTOS 场景的外设 DMA和 Linux 内核里的 DMA API、SWIOTLB 完全是两套体系。看到这类文章时先分清上下文别在 Linux 内核追问题的时候被 MCU 的经验带偏。5.4 一套通用的定位套路综合我这些年追 DMA 问题的经验遇到 SWIOTLB 相关故障按这个链路走基本不会跑偏先看 dmesg 有没有swiotlb buffer is full或Out of SWIOTLB memory有就先看使用率和水位线。再查当前 kernel cmdline 里有没有swiotlb参数确认池子大小是否符合业务预期。用 ftrace 或perf probe抓swiotlb_tbl_map_single的调用栈找到是哪个驱动在大量触发 bounce。检查这个驱动的 dma_mask 设置是否正确以及 map/unmap 是否成对。最后才考虑调整swiotlb大小或启用动态 SWIOTLB。这套顺序能避免最常见的误区一上来就加内存参数结果只是把问题盖住了。6. 最后再分享几个容易被忽略的细节swiotlbforce不是性能调优工具是调试工具。长跑swiotlbforce会让所有 DMA 都多一次拷贝性能显著下滑。排查完毕后记得去掉。SWIOTLB 的拷贝方向容易搞反。DMA_FROM_DEVICE是设备写内存unmap 时才把 SWIOTLB 槽位里的数据拷回原始缓冲区DMA_TO_DEVICE是 map 时就把数据拷入槽位。搞反方向会导致数据错乱而且这种错乱特别隐蔽可能几十万包才出现一次。不要迷信“加大 swiotlb 就没问题了”。池子加大只是把故障点往后推根因十有八九是驱动泄漏或者 dma_mask 配置错误。我在生产环境见过太多把swiotlb6553664GB写进 cmdline 最后照样崩的案例。机密计算场景下SWIOTLB 是“必要的恶”。不要试图关掉它而是尽量让驱动使用共享页面、走设备端解密的硬件路径才能把 bounce 开销降到最低。说实话SWIOTLB 这套机制写得并不复杂但因为它在“设备能不能访问内存”这个问题上处在最底层一旦出错表象千变万化排查起来很考验对 DMA 路径的整体理解。希望这篇文章能帮你少走点弯路。
深入理解 SWIOTLB：从 DMA 原理到机密计算调优
有段时间我被一个问题折腾得够呛一台 196GB 内存的服务器插着一张很常见的板载千兆网卡跑着跑着 dmesg 里突然冒出一串Out of SWIOTLB memory然后网卡直接瘫痪网络中断。那天晚上我翻了三个多小时内核代码才算把 SWIOTLB 这个既透明又无处不在的组件彻底搞清楚。后来做机密计算相关的项目又发现 AMD SEV、Intel TDX 的环境里SWIOTLB 几乎成了 DMA 路径上的必经之地地位比很多人以为的重要得多。这篇文章就把我从 DMA 基础概念、SWIOTLB 工作原理、参数调优一路到机密计算场景下的完整理解写下来适合正在追 DMA 报错的内核开发者、搞虚拟化和机密计算的平台工程师以及想弄明白“为什么 dma_map 会慢”的驱动开发者。1. 从 DMA 到 SWIOTLB这块“软件缓冲区”到底解决什么问题1.1 DMA 的本职工作与三种典型失败DMA 的全称是 Direct Memory Access说白了就是让外设绕过 CPU 直接读写内存。CPU 只要把要传输的缓冲区的物理地址告诉设备设备就能自己把数据搬进搬出搬完了再发个中断通知 CPU。这个机制省掉了 CPU 逐字节复制是网卡、磁盘控制器、GPU、USB 控制器等外设高性能工作的基础。但 DMA 有一个前提设备得“够得着”你给它的那块内存。这里会碰见三类经典问题寻址位宽限制。很多设备只有 32 根地址线只能访问 4GB 以下的内存。但服务器内存动辄几十 GB、上百 GB驱动分配出来的 sk_buff、bio buffer 很可能落在 4GB 之上设备一读就是错误地址。没有 IOMMU。IOMMU 相当于给设备加了一层地址翻译和隔离能把设备访问的 IOVA 映射到任意物理地址。但嵌入式平台、老式 x86 板子经常没有 IOMMU或者驱动压根没走 IOMMU 路径。内存加密。SEV、TDX 这类机密计算场景下内存内容是用客户机密钥加密的设备去读读回来全是一堆密文根本没法用。设备访问内存必须是“共享”或者“未加密”的页面。这三种情况本质上是同一个问题软件手里有一块内存但设备直接读不了。怎么办最直接的办法就是在设备能访问的区域里先准备一块“中转”内存把数据先搬到那里再让设备去操作。这个中转机制就是 SWIOTLB。1.2 名字里有 TLB但它不是 TLBSWIOTLB 全称 Software Input Output Translation Lookaside Buffer中文社区一般叫“软件 IO 地址翻译后备缓冲区”或者干脆叫“软 TLB”。第一次看见这个名字的人很容易误会以为它和 CPU 里的 TLB 一样是做虚拟地址翻译的。CPU 的 TLB 是硬件组件负责缓存虚拟地址到物理地址的映射。SWIOTLB 里面虽然带着 Translation 这个词但它不翻译任何地址它干的活是把数据复制到一块预先保留好的、设备可访问的物理内存区域里然后把这块区域的物理地址交给设备。换句话说它用“拷数据”代替“转地址”本质是一个 bounce buffer弹跳缓冲区。之所以叫 TLB纯粹是历史原因早期内核开发者把这块保留内存看成某种“IO 地址映射表”的替代品。理解到这一层再看代码里的swiotlb_*函数就不会懵了。1.3 它和 IOMMU 是竞争还是互补很多人会问都上 IOMMU 了还要 SWIOTLB 干嘛答案是两者解决的问题不完全一样。IOMMU 解决的是“地址可达性”把设备的 IOVA 翻译成任意物理地址设备只需要访问一段连续的 IOVA 就行。SWIOTLB 解决的是“数据可见性”当设备访问的内存内容对它来说不可见、不可解时只有把数据搬到设备能正确处理的区域硬件层面的“隔阂”才能消除。在机密计算场景里IOMMU 可以把 IOVA 映射到客户机的共享内存但共享内存里的数据如果是加密的IOMMU 也帮不了你解密。所以哪怕是 IOMMU 正常工作SWIOTLB 依然可能被强制启用。这个后面第四章会展开。2. 核心机制缓冲池设计、槽位管理和一次 DMA 搬运的完整过程2.1 内存布局与数据结构SWIOTLB 在内核启动早期就从物理内存里保留一块连续区域这部分内存叫作io_tlb_mem。每个io_tlb_mem底下有若干io_tlb_slot每个 slot 是固定大小的槽位。关键参数先列出来参数值说明IO_TLB_SHIFT11slot 大小 2^11 2048 字节IO_TLB_SIZE2048最小对齐粒度IO_TLB_SEGSIZE128一次映射最多占用的连续 slot 数默认缓冲池大小64 MiB即 32768 个 slot内核配置开关CONFIG_SWIOTLBx86、arm64 等主流架构默认开启代码层面最核心的三个结构是struct io_tlb_mem保存整个缓冲池的基地址、slot 数组、索引、剩余可用 slot 数、水位线等全局状态。struct io_tlb_slot每个槽位有一个list链表节点用于维护空闲槽位链表还有一个orig_addr字段记录这个槽位当前对应的原始缓冲区地址dma_unmap时要靠它把数据拷回原来的位置。mem-pool数组用于快速管理不同对齐需求的槽位分配。启动时内核会打印一段类似下面的日志告诉你 SWIOTLB 已经映射好$ dmesg | grep -i swiotlb [ 0.000000] software IO TLB: area num 1, size 64.00 MiB, mapped at 0x00000000fed00000看到size 64.00 MiB就知道默认池已经建好了。2.2 一次 dma_map_single 的完整旅程驱动想给设备传数据一般不会直接写寄存器给物理地址而是调用 DMA APIdma_addr_t dma_map_single(struct device *dev, void *buf, size_t size, enum dma_data_direction dir);这个函数内部最终会走向dma_direct_map_page。当内核判断当前设备的 DMA mask 无法覆盖缓冲区地址、或者 SWIOTLB 被强制启用时就会进入swiotlb_map路径。完整过程可以拆成六步获取原始缓冲区信息。拿到buf的物理地址和长度。检查是否需要 bounce。如果设备本身就能直接访问这块内存直接返回物理地址SWIOTLB 完全不参与。查找空闲槽位。swiotlb_tbl_map_single在io_tlb_mem里找一段足够长的连续空槽。因为 DMA 设备拿到的必须是物理上连续的内存所以至少得凑够size/2048向上取整个槽位。复制数据。如果数据传输方向是DMA_TO_DEVICECPU 往设备写内核直接把原始缓冲区的内容memcpy到 SWIOTLB 槽位里。如果方向是DMA_FROM_DEVICE设备往内存写这一步不复制等设备写完之后在 unmap 阶段再拷回。返回 SWIOTLB 物理地址。驱动拿到的是 SWIOTLB 槽位的地址不是原来的buf地址。unmap 时反向搬运。dma_unmap_single时对于DMA_FROM_DEVICE内核把槽位里的数据复制回原始缓冲区同时把槽位释放回空闲链表。所以dma_map_single慢很多时候不是 DMA API 本身慢而是 SWIOTLB 多了一次内存拷贝。网络收包时每包都要 copy吞吐一大开销立刻暴露。2.3 为什么 slot 是 2KB默认 64 MiB2KB 这个数字不是拍脑袋定的。历史上 DMA 设备常见的 descriptor、磁盘扇区、网络包缓冲区很多都按 2KB 对齐或做整数倍分配。2KB 粒度既能把内存浪费控制在可接受范围又能减少分配大段连续内存的失败概率。默认 64 MiB 则是个折中。太少了高吞吐场景容易耗尽太多了这 64 MiB 是启动时一次性保留给 SWIOTLB 的平时不用就白白浪费。64 MiB 在 64 位系统上不算大又能撑住绝大多数虚拟化场景的 DMA 压力。内核还限定了一次 DMA 映射最多占用 128 个连续 slot也就是单次映射最大 256 KiB避免一个驱动一次性把整个缓冲池占光。3. 参数调优与动态扩容把 SWIOTLB 调到跟你的场景匹配3.1 内核参数与配置项SWIOTLB 的可调参数主要写在内核 command line 里简单总结如下内核参数作用典型用法swiotlbforce强制所有 DMA 都走 SWIOTLB即便设备可以直接访问调试、验证功能swiotlb256指定 SWIOTLB 缓冲池大小为 256 MiB高吞吐压力场景swiotlboff尝试关闭 SWIOTLB仅在确定设备不需要且无加密场景时用部分架构不保证生效iommuswiotlb让 IOMMU 路径强制回退到 SWIOTLB排查 IOMMU 相关 DMA 问题CONFIG_SWIOTLB_DYNAMIC编译选项开启动态扩容5.19 内核默认在部分架构上开启swiotlbforce是排查问题时的老朋友。它能把所有 DMA 流量都压进 SWIOTLB方便你观察缓冲池压力配合 trace 事件能快速确认“到底哪些驱动在走 bounce 路径”。但生产环境千万不要长期开性能会明显打折。3.2 Linux 5.19 之后的动态 SWIOTLB老版本的 SWIOTLB 是“一次分配终身使用”。启动时保留 64 MiB之后无论压力多大池子就那么大满了就打印Out of SWIOTLB memory。这对嵌入式或者内存紧张的场景很不友好。Linux 5.19 引入了动态 SWIOTLB 机制。简单说当默认池用完时内核会尝试从系统的可用内存里再划分出一块新的io_tlb_mempool追加进去动态扩充可用槽位。这带来两个实际好处默认配置下不用担心 64 MiB 不够因为压力上来后池子能自己长大。平时没压力时不会白白占用几十 MiB 的保留内存按需分配更符合容器化、资源受限环境的需求。动态 SWIOTLB 依赖CONFIG_SWIOTLB_DYNAMIC编译选项。遇到老内核上频繁的 SWIOTLB 耗尽除了调swiotlb大内存我一般还会看一眼发行版内核有没有开这个选项能不开新内核就不开。3.3 性能开销到底有多大SWIOTLB 本质上是用 CPU 拷贝换设备可达性所以它的开销最直观的体现就是 memcpy。实测中纯 CPU 大规模拷贝的吞吐很容易跑上 10 GB/s但 DMA 路径上的拷贝还有 cache 颠簸、TLB miss、内存屏障等额外成本。网络收包场景里一旦触发 SWIOTLB bouncePPS 吞吐跌个 30%~50% 是常见现象。我的优化经验按优先级排列先检查驱动是否正确设置了 dma_mask。很多设备明明支持 64 位寻址驱动却只设了 32 位导致内核误判设备够不着高地址走了 SWIOTLB。把dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))补上问题立刻消失。再用 IOMMU 解决地址碎片。没有内存加密需求时直接让 IOMMU 映射 IOVA比 bounce buffer 的 memcpy 划算得多。最后才考虑加大 SWIOTLB 池。加大只是缓解压力不会消除拷贝开销。4. 机密计算时代内存加密如何让 SWIOTLB 变成绕不开的路径4.1 SME/SEV/TDX 的内存加密语义机密计算的核心诉求是虚拟机运行时宿主机管理员、Hypervisor、甚至物理硬件上的其他软件都看不到客户机的敏感数据。AMD SME 在物理地址上拿一个专门的位置当作加密位C-bit置位后 CPU 访问这块内存会自动用系统密钥加解密。SEV 在此基础上进一步把加密粒度做到每台虚拟机独立密钥。Intel TDX 也是类似思路把内存划分成 private 和 shared 两类。问题来了设备发起 DMA 时访问内存用的是物理地址它可没有 CPU 那套加解密逻辑。如果客户机 DMA 缓冲区是加密的设备读出来的就是一堆密文。这时候要么让设备访问“shared”内存要么让 DMA 数据走一段特殊硬件路径否则数据根本没法用。4.2 机密虚拟机里的 DMA 数据流以运行在 SEV/TDX 虚拟机里的 virtio-net 为例。客户机驱动想要发包驱动调用dma_map_single映射 sk_buff。内核发现内存加密已启用且这块页面是 private 状态直接让设备访问会导致设备读到密文。于是走向 SWIOTLB把数据复制到共享/未加密的内存区域。设备或者宿主机侧的 vhost 后端从共享内存里读取明文数据。你可以在客户机里看到类似日志$ dmesg | grep -i swiotlb [ 0.000000] software IO TLB: area num 1, size 64.00 MiB, mapped at ...正常加密虚拟机启动后swiotlb几乎总是被强制启用这不是 Bug而是刻意设计。内核在检测到 SME/SEV/TDX 激活时会把swiotlb_force设置成强制模式保证所有 DMA 流量都先经过共享内存中转。这是 SWIOTLB 从“地址兜底”变成“机密计算必经之路”的根本原因。4.3 有了 IOMMU 为什么还是离不开 SWIOTLB在机密计算场景里IOMMU 依然在但它管的是地址翻译管不了加解密。即使 IOMMU 把设备的 IOVA 映射到了客户机的 shared 页面前提也得是那块页面本来就是未加密的。如果驱动拿了 private 页面去映射IOMMU 只会照常翻译地址数据内容还是密文。所以 SWIOTLB 和 IOMMU 在机密计算里是配合关系IOMMU 负责把设备地址翻译到正确位置SWIOTLB 负责把数据从 private 内存搬到 shared 内存。少了哪一个DMA 都没法正常工作。这里也解释了一个让很多人困惑的现象机密虚拟机里网络吞吐看起来比普通虚拟机差不少。因为每个包多一次完整的内存拷贝再加上页面属性切换的额外开销性能下降是实打实的。想在机密环境里优化 DMA唯一的出路是让驱动从一开始就分配共享内存比如 virtio 的VIRTIO_F_ACCESS_PLATFORM配合共享页分配能减少一部分 bounce 开销。5. 实战排查从报错信息到完整定位链路5.1 常见报错与含义SWIOTLB 相关报错其实不算罕见我把最常见的几个列出来报错内容含义常见原因swiotlb buffer is full (sz: 8192 bytes), total 65536 (slots), used 65536 (slots)缓冲池槽位耗尽驱动大量映射没及时 unmap或池子配小Out of SWIOTLB memoryDMA 映射失败与上一条同因DMA 层直接返回失败kernel: DMA-API: device driver maps memory ...DMA API 检测到异常驱动用法有问题开了 CONFIG_DMA_API_DEBUGswiotlb: coherent allocation failed一致性分配失败内存紧张或分配尺寸超过池子能力看到swiotlb buffer is full第一反应不是去调大参数而是先确认有没有驱动泄漏了 DMA 映射。DMA 映射和内存一样需要配对dma_map之后忘了dma_unmapSWIOTLB 槽位就永远被占着。5.2 案例一宿主机上大量磁盘 IO 触发 SWIOTLB 耗尽我之前处理过一个现场KVM 宿主机跑着十几个虚机某个时间段所有虚机磁盘 IO 大面积卡死dmesg 里一直刷Out of SWIOTLB memoryhost 上 SWIOTLB 用了 100%。当时我们假设是 SWIOTLB 池太小直接把swiotlb2048加上了结果只是把故障推迟了几小时。后来我用 ftrace 把 SWIOTLB 的事件抓出来发现罪魁祸首是某个自定义驱动它在中断上下文里做 DMA 映射但在完成处理后少调了一次dma_unmap_single。每次中断都泄漏若干槽位一天下来池子就空了。修复驱动后swiotlb64都稳稳的。排查这类问题建议按这个顺序来# 1. 确认当前 SWIOTLB 使用率 $ cat /sys/kernel/debug/swiotlb/io_tlb_used 32768 # 2. 抓 SWIOTLB 相关 trace 事件 $ echo 1 /sys/kernel/debug/tracing/events/swiotlb/enable $ cat /sys/kernel/debug/tracing/trace | grep swiotlb # 3. 配合 perf 看调用栈定位到底是哪个驱动在映射 $ perf record -e probe:swiotlb_tbl_map_single -ag -- sleep 10 $ perf report/sys/kernel/debug/swiotlb/目录下有io_tlb_nslabs、io_tlb_used、io_tlb_hiwater等文件能直观看到当前使用量和水位线是定位 SWIOTLB 压力最直接的入口。5.3 案例二rk3588 的 “failed to reset the DMA” 与 SWIOTLB 无关最近搜索 DMA 相关话题时发现 rk3588 的网卡驱动报failed to reset the dma是高频问题。这个报错很容易让人误以为和 SWIOTLB 有关毕竟都有 DMA 三个字母。实际上这是stmmac驱动在初始化硬件 DMA 控制器时复位操作超时导致的。常见根因是时钟没配好、PHY 芯片供电不稳、或者网卡工作在 promisc 模式下被硬件 bug 卡住这是 MAC 层面的问题跟 Linux 软件层面的 SWIOTLB 一点关系都没有。看到这类错误排查方向应该是检查设备树里clock-frequency、ref-clock配置。检查 PHY 的 reset GPIO 和供电时序。看stmmac初始化失败时打印的前置日志确认是 DMA reset 还是 MDIO 通讯异常。顺便说一句搜索“DMA”这个词时你会看到大量 STM32、GD32、串口 DMA、ADC 多通道 DMA 的内容那些是单片机裸机或 RTOS 场景的外设 DMA和 Linux 内核里的 DMA API、SWIOTLB 完全是两套体系。看到这类文章时先分清上下文别在 Linux 内核追问题的时候被 MCU 的经验带偏。5.4 一套通用的定位套路综合我这些年追 DMA 问题的经验遇到 SWIOTLB 相关故障按这个链路走基本不会跑偏先看 dmesg 有没有swiotlb buffer is full或Out of SWIOTLB memory有就先看使用率和水位线。再查当前 kernel cmdline 里有没有swiotlb参数确认池子大小是否符合业务预期。用 ftrace 或perf probe抓swiotlb_tbl_map_single的调用栈找到是哪个驱动在大量触发 bounce。检查这个驱动的 dma_mask 设置是否正确以及 map/unmap 是否成对。最后才考虑调整swiotlb大小或启用动态 SWIOTLB。这套顺序能避免最常见的误区一上来就加内存参数结果只是把问题盖住了。6. 最后再分享几个容易被忽略的细节swiotlbforce不是性能调优工具是调试工具。长跑swiotlbforce会让所有 DMA 都多一次拷贝性能显著下滑。排查完毕后记得去掉。SWIOTLB 的拷贝方向容易搞反。DMA_FROM_DEVICE是设备写内存unmap 时才把 SWIOTLB 槽位里的数据拷回原始缓冲区DMA_TO_DEVICE是 map 时就把数据拷入槽位。搞反方向会导致数据错乱而且这种错乱特别隐蔽可能几十万包才出现一次。不要迷信“加大 swiotlb 就没问题了”。池子加大只是把故障点往后推根因十有八九是驱动泄漏或者 dma_mask 配置错误。我在生产环境见过太多把swiotlb6553664GB写进 cmdline 最后照样崩的案例。机密计算场景下SWIOTLB 是“必要的恶”。不要试图关掉它而是尽量让驱动使用共享页面、走设备端解密的硬件路径才能把 bounce 开销降到最低。说实话SWIOTLB 这套机制写得并不复杂但因为它在“设备能不能访问内存”这个问题上处在最底层一旦出错表象千变万化排查起来很考验对 DMA 路径的整体理解。希望这篇文章能帮你少走点弯路。
