解密 Linux 下 ARM SMMU 的 DMA 内存分配机制

1. 从音频播放说起：为什么需要SMMU来管理DMA内存？

想象一下你正在用手机听歌，音乐App通过扬声器流畅地播放着旋律。这个看似简单的过程，背后其实隐藏着一场精密的“内存接力赛”。音频数据需要从应用内存快速、准确地搬运到音频编解码器的缓冲区，这个搬运工就是DMA（直接内存访问）。DMA能让硬件设备不经过CPU，直接与内存“对话”，极大地提升了数据传输效率。

但在一个复杂的系统里，像音频、视频、网络这类设备众多，如果每个设备都能随意访问物理内存的任何角落，那将是一场灾难——设备A可能不小心改写了设备B甚至操作系统的关键数据，导致系统崩溃。这就需要一个“交通警察”来指挥和隔离，确保每个设备只能访问自己被允许的内存区域。在ARM架构的系统中，这个“警察”就是SMMU。

SMMU，全称系统内存管理单元，你可以把它理解为一个专门为I/O设备服务的“内存翻译官”和“保安”。它的核心工作有两件：一是地址翻译，把设备看到的“虚拟地址”转换成真实的物理内存地址；二是访问控制，检查设备是否有权限读写某块内存。而这一切的起点，就是当驱动程序调用类似dma_alloc_coherent()这样的函数，为DMA申请一块“安全”的内存时。

在Linux内核里，这个过程并不是SMMU直接完成的，而是通过一个更上层的抽象——IOMMU子系统来协调。SMMU作为ARM平台对IOMMU的具体硬件实现，通过注册一系列回调函数（比如map, attach_dev），将自己“插入”到IOMMU框架中。当音频驱动为DMA分配内存时，调用链会层层下探，最终触发SMMU的机制，完成从虚拟地址分配、物理页映射到页表配置的全过程。

所以，理解SMMU的DMA内存分配，就是理解现代异构计算系统中，如何安全、高效地让硬件设备协同工作的基石。接下来，我们就以最常见的ALSA音频子系统为例，一步步拆解这个流程。

2. 驱动视角：ALSA音频子系统如何发起DMA内存请求？

让我们先站在音频驱动开发者的角度看问题。在Linux的ALSA框架中，驱动程序需要为音频流准备DMA缓冲区。你很少会直接调用最底层的dma_alloc_coherent()，而是使用ALSA提供的一系列更友好的封装函数。

2.1 预分配：为性能与确定性做准备

音频播放对实时性要求极高，一次缓冲区分配失败导致的卡顿是无法接受的。因此，ALSA引入了预分配机制。核心函数是snd_pcm_lib_preallocate_pages()和snd_pcm_lib_preallocate_pages_for_all()。前者为单个音频子流（比如播放流）预分配缓冲区，后者则为PCM设备下的所有子流（播放和录制）一次性分配。

它们的核心逻辑在preallocate_pages()和preallocate_pcm_pages()函数中。我带你看看里面一个关键的“退让”策略，这在实际调试中非常有用：

static int preallocate_pcm_pages(struct snd_pcm_substream *substream, size_t size) {
    ...
    do {
        err = do_alloc_pages(card, dmab->dev.type, dmab->dev.dev, size, dmab);
        if (err != -ENOMEM)
            return err;
        size >>= 1; // 分配失败？那就把请求大小减半再试！
    } while (size >= snd_minimum_buffer); // 直到小于最小缓冲区（通常16KB）
    ...
}

这段代码揭示了一个重要细节：当系统内存紧张，无法一次性分配所需的大块连续内存时，ALSA会尝试分配更小的缓冲区。比如你请求256KB，它可能先试128KB，再试64KB……这保证了即使在内存压力下，音频基础功能仍能工作，只是可能影响高码率音频的播放。预分配的内存会被保存在substream->dma_buffer中，供后续使用。

2.2 运行时分配：动态的缓冲区管理

预分配发生在设备初始化阶段。而在音频流实际启动（hw_params阶段），驱动会调用snd_pcm_lib_malloc_pages()来获取最终使用的DMA缓冲区。这个函数的逻辑更偏向“实用主义”：

1. 检查现有缓冲区：如果运行时已经有一个DMA缓冲区，且大小足够，就直接复用，返回0（表示缓冲区未改变）。这避免了重复分配的开销。
2. 使用预分配缓冲区：如果子流有预分配的缓冲区（substream->dma_buffer.area不为空），且大小足够，就优先使用它。这是最理想的快速路径。
3. 实时分配：如果上述都不满足，才调用do_alloc_pages()进行真正的内存分配。新分配的缓冲区信息会更新到运行时状态中。

这种分层策略兼顾了性能与灵活性：预分配保障了确定性，运行时复用避免了开销，动态分配则应对了变化的需求。

2.3 最终的统一入口：snd_dma_alloc_pages

无论预分配还是运行时分配，最终都会汇聚到snd_dma_alloc_pages()这个统一入口。它是ALSA内存分配的“路由器”，根据不同的DMA内存类型，选择不同的底层分配器：

int snd_dma_alloc_pages(int type, struct device *device, size_t size, struct snd_dma_buffer *dmab) {
    ...
    switch (type) {
        case SNDRV_DMA_TYPE_CONTINUOUS: // 普通连续内存
            dmab->area = alloc_pages_exact(size, gfp);
            break;
        case SNDRV_DMA_TYPE_VMALLOC:    // 通过vmalloc分配
            dmab->area = __vmalloc(size, gfp);
            break;
#ifdef CONFIG_HAS_DMA
        case SNDRV_DMA_TYPE_DEV:        // 设备DMA内存（走IOMMU/SMMU）
        case SNDRV_DMA_TYPE_DEV_UC:     // 设备非缓存内存
            snd_malloc_dev_pages(dmab, size);
            break;
#endif
        ...
    }
}

对于连接到SMMU的设备，我们走的是SNDRV_DMA_TYPE_DEV这个分支，它会调用snd_malloc_dev_pages()，而这里，终于出现了我们熟悉的dma_alloc_coherent()。至此，请求正式从ALSA子系统移交给了Linux内核的DMA API层。

3. DMA API层：IOMMU框架如何介入分配流程？

当调用dma_alloc_coherent(dev, size, &dma_handle, gfp)时，故事进入了内核的DMA映射核心。这个函数只是一个简单的包装，实际工作由dma_alloc_attrs()完成。它的执行逻辑是一条清晰的三段式决策链：

3.1 第一站：设备专属的Coherent内存池

首先，内核会尝试从设备的coherent内存池中分配。这是一个由平台代码（通常通过设备树）声明的特殊内存区域，专供某个设备DMA使用。

void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs) {
    if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr))
        return cpu_addr; // 如果池里有，直接返回！
    ...
}

dma_alloc_from_dev_coherent()内部使用位图来管理这个内存池，分配速度很快。但并非所有设备都有这个“特权”，这通常用于某些有严格内存位置要求的嵌入式设备。对于大多数通用设备，这一步会失败，流程继续。

3.2 决策点：走直接映射还是IOMMU映射？

接下来是关键决策：dma_alloc_direct(dev, ops)。这个函数判断是否绕过IOMMU，使用直接DMA映射。判断依据主要是设备的DMA掩码和总线限制。简单来说，如果设备支持的DMA地址范围足够小，且物理上可以直接访问所有内存，就可能绕过IOMMU以提升性能。

但对于连接到SMMU的设备，答案通常是“否”。这时，内核会使用设备的dma_ops中的alloc回调函数。而这个dma_ops，正是在设备探测时，由IOMMU子系统通过arch_setup_dma_ops() -> iommu_setup_dma_ops()设置的。对于ARM SMMU，这个操作集就是iommu_dma_ops，其.alloc回调指向了iommu_dma_alloc。

3.3 核心分配器：iommu_dma_alloc的两种路径

iommu_dma_alloc()是IOMMU框架下DMA内存分配的核心。它根据配置和参数，主要选择两条路径：

路径一：iommu_dma_alloc_remap（支持重映射的复杂分配） 当内核配置了CONFIG_DMA_REMAP、分配标志允许阻塞（gfpflags_allow_blocking(gfp)），且没有强制要求内存物理连续（DMA_ATTR_FORCE_CONTIGUOUS）时，会走这条更强大的路径。它能够处理非连续物理页，并通过vmap将它们映射到一段连续的虚拟地址空间。这对于需要大缓冲区但系统内存碎片化严重的场景非常有用。其步骤堪称经典：

1. 计算分配参数：根据SMMU Domain支持的页大小位图（pgsize_bitmap），确定分配粒度。
2. 分配物理页：调用__iommu_dma_alloc_pages()，它会尝试以最大的连续页块分配，失败则逐步减小块大小，直到成功。
3. 分配IOVA地址：调用iommu_dma_alloc_iova()，在设备的IO虚拟地址空间中划出一段地址。
4. 创建散列表：使用sg_alloc_table_from_pages()将物理页数组组织成scatter-gather列表，描述这段可能不连续的内存。
5. 建立SMMU映射：通过iommu_map_sg_atomic()，将上一步得到的sg列表映射到IOVA地址。这一步会最终调用SMMU驱动来填充页表。
6. 重映射到内核虚拟空间：通过dma_common_pages_remap()，将物理页再次映射到一段连续的内核虚拟地址，方便CPU访问。

路径二：iommu_dma_alloc_pages + 映射（简单分配） 如果不满足上述条件，则走这条更直接的路径。它先通过iommu_dma_alloc_pages()分配物理页（或从DMA池中分配），然后调用__iommu_dma_map()直接将单个物理页映射到IOVA地址。这条路径适用于原子上下文或需要物理连续内存的场景。

无论哪条路径，最终都产出了两个关键地址：一个是给设备用的DMA总线地址（即IOVA），存储在dma_handle中；另一个是给CPU用的内核虚拟地址，作为函数返回值。设备使用前者来读写数据，CPU使用后者来准备数据，而SMMU负责两者的自动转换。

4. SMMU的舞台：IOVA分配与页表映射详解

现在，压力给到了SMMU这边。分配流程中最具SMMU特色的部分，莫过于IOVA地址空间的分配和页表映射的建立。

4.1 IOVA管理：红黑树与缓存的艺术

iommu_dma_alloc_iova()函数负责在设备的IO虚拟地址空间（IOVA Domain）中分配一段地址。这个空间由struct iova_domain管理，其核心是一颗红黑树，用于高效管理和查找已分配的IOVA区间。

分配策略是“从高地址向下分配”（top-down）。函数首先会尝试从IOVA缓存（iova_rcache_get）中快速获取一个合适大小的空闲区间。这个缓存按2的幂次方大小（如4K, 8K, 16K...）维护，可以极大提升高频、小内存分配的效率。

如果缓存未命中，则执行常规分配alloc_iova_fast -> alloc_iova -> __alloc_and_insert_iova_range。这个过程会遍历红黑树，从指定的上限地址（limit_pfn）开始，向下寻找第一个能容纳请求大小的空闲缝隙。这个上限地址至关重要，它由dev->coherent_dma_mask、dev->bus_dma_limit和SMMU Domain的几何限制（aperture_end）三者共同决定，取最小值。

dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
if (domain->geometry.force_aperture)
    dma_limit = min(dma_limit, (u64)domain->geometry.aperture_end);

这里有个针对PCI设备的优化：如果DMA掩码大于32位（即支持64位地址），会先尝试在低4GB地址空间（DMA_BIT_MASK(32)）分配，这有助于兼容一些旧设备或固件。分配成功后，新的IOVA区间会被插入红黑树，并可能加入到缓存中，供后续快速分配。

4.2 页表映射：构建SMMU的“地图”

拿到IOVA和物理页后，就需要通过iommu_map_sg_atomic()建立映射。对于SMMUv3，其驱动提供的map回调是arm_smmu_map()，它进一步调用IO页表库的arm_lpae_map()。

ARM LPAE（长描述符页表）格式与CPU的MMU页表类似，是一种多级页表结构。__arm_lpae_map()函数递归地遍历页表层级：

1. 根据当前层级和IOVA，定位到页表项（PTE）指针。
2. 如果当前层级的块大小（如2MB）与要映射的大小匹配，则初始化该PTE为一个块描述符，直接指向物理地址。
3. 如果不匹配，则需要继续向下级查找。如果下一级页表不存在，则分配新的页表页，并在当前层级的PTE中安装一个表描述符，指向新页表。
4. 重复此过程，直到最末级，将PTE初始化为页描述符，完成映射。

页表项的内容由arm_lpae_prot_to_pte()构造，包含了内存属性（如设备内存、写回缓存）、访问权限（读/写、特权）、共享性等关键信息。这些属性必须与dma_alloc_attrs()调用时传递的prot参数一致，确保设备访问行为符合预期。

4.3 上下文描述符：设备的“入场券”

仅仅有页表还不够，SMMU需要知道哪个设备使用哪套页表。这就是上下文描述符的作用。在设备连接到SMMU Domain时（arm_smmu_attach_dev），驱动会为设备创建一个上下文描述符，并写入SMMU设备的上下文描述符表中。

这个描述符包含了关键信息：

• TTBR0：阶段1页表的基础地址（即我们刚构建的页表的物理地址）。
• TCR：页表控制寄存器，控制地址空间大小、粒度等。
• MAIR：内存属性索引寄存器，定义内存类型。
• ASID：地址空间ID，用于区分不同进程的地址空间（在SMMU中常用于PCIe PASID）。

当设备发起一次DMA传输，并带上它的StreamID（和可能的SubstreamID/PASID）时，SMMU硬件会用这些ID索引到对应的上下文描述符，加载其TTBR0，然后根据IOVA遍历页表，最终找到物理地址。至此，一次完整的地址翻译完成。

5. 实战与调优：不同分配策略对性能的影响

理解了机制，我们更要关注如何用好它。不同的DMA内存分配策略，对系统性能、稳定性和功能有显著影响。

5.1 分配策略对比：coherent vs streaming

首先，要分清两种主要的DMA映射类型：

• 一致性映射：通过dma_alloc_coherent()分配。CPU和设备对内存的修改彼此立即可见，无需软件执行缓存维护操作。内核通过分配不可缓存或写回写分配的内存来实现。优点是编程简单，缺点是可能牺牲一些CPU访问性能。
• 流式映射：通过dma_map_single()/dma_map_sg()等临时建立映射。CPU和设备看到的缓存视图可能不一致，需要在映射/解映射时使用dma_sync_single_for_device/cpu()来同步缓存。性能更高，但编程更复杂。

对于音频DMA缓冲区，由于CPU需要频繁填充数据，设备需要连续读取，通常使用一致性映射。ALSA的snd_dma_alloc_pages()在SNDRV_DMA_TYPE_DEV类型下，最终就是调用dma_alloc_coherent()。

5.2 关键参数调优：DMA掩码与IOVA空间

驱动中设置的DMA掩码（dma_set_mask_and_coherent）对SMMU分配有直接影响。

• 设置过小：例如设备支持40位地址，却只设置了32位掩码。那么IOVA分配器只能在低4GB空间寻找空闲区间，容易导致该区域碎片化甚至耗尽，引发分配失败。
• 设置过大：超出SMMU硬件实际支持的输入地址大小（IAS）。虽然分配可能成功，但SMMU无法翻译高位地址，会导致地址错误故障。
• 最佳实践：查阅SoC手册，将设备的coherent_dma_mask设置为与SMMU的IAS一致。例如SMMUv3 IAS=40，则使用dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40))。

IOVA空间的大小（在iommu_dma_init_domain中设置）也至关重要。它默认是dev->coherent_dma_mask的值。在内存较大的服务器系统上，为高性能设备配置足够大的IOVA空间，可以减少分配冲突，提升吞吐量。

5.3 预分配的利与弊

回到开头的ALSA预分配，它是个双刃剑：

• 优点：
  • 确定性：在系统启动、内存充裕时完成分配，避免运行时因内存不足导致音频中断。
  • 性能：避免了音频流启动时分配内存的延迟，满足实时性要求。
  • 复用：多个子流可共享预分配的大缓冲区。
• 缺点：
  • 内存占用：即使没有音频播放，预分配的内存也被长期占用，可能影响其他应用。
  • 潜在浪费：预分配的大小是估计值，可能多于实际需要。

因此，在嵌入式等内存敏感场景，可能需要调整preallocate_dma内核参数或修改驱动，减少预分配大小，甚至关闭预分配，采用完全的动态管理。

5.4 调试技巧：当SMMU报错时怎么办？

SMMU驱动通过事件队列报告错误。常见的故障及排查思路：

1. Translation Fault (0x10)：IOVA无法翻译为物理地址。

   • 可能原因：页表映射未建立、映射已释放、IOVA超出分配范围。
   • 排查：检查dma_alloc_coherent是否成功，DMA地址dma_handle是否在映射有效期内被使用。

2. Stream Disabled Fault (0x06)：设备对应的StreamID未被启用。

   • 可能原因：设备树中SMMU节点配置错误，或驱动未成功将设备attach到SMMU domain。
   • 排查：检查iommu-map设备树属性，确认驱动probe流程中iommu_attach_device调用成功。

3. Permission Fault (0x13)：设备试图以无权限的方式（如写只读区域）访问内存。

   • 可能原因：prot参数设置错误，如将只读缓冲区配置为可写。
   • 排查：检查DMA映射时的权限标志，对比设备访问行为。

开启内核调试选项CONFIG_ARM_SMMU_V3_DEBUG，可以获取更详细的事件日志。结合devmem工具查看SMMU寄存器状态，以及使用iommu debugfs接口（如/sys/kernel/debug/iommu/）查看domain和设备的映射信息，是定位SMMU问题的有效手段。

6. 总结与展望：掌握SMMU DMA分配的精髓

从ALSA驱动的一个简单调用，到SMMU硬件页表项的一次写入，Linux内核为我们构建了一条复杂而精密的DMA内存分配流水线。这条路径的核心思想是分层与抽象：驱动使用子系统的友好接口，子系统委托给DMA API，DMA API通过IOMMU框架适配具体硬件，最终由SMMU驱动完成硬件编程。

理解这个过程，不仅能帮助我们在驱动开发中正确使用DMA API，避免内存错误和安全漏洞，更能让我们在系统性能调优时有的放矢。比如，当音频出现间歇性爆音时，你会知道去检查IOVA空间是否碎片化；当某个设备DMA性能低下时，你会考虑是否误用了coherent映射，或者DMA掩码设置不当。

随着异构计算和虚拟化的发展，SMMU的角色越发重要。例如，在虚拟化场景中，SMMU的二级翻译（Stage-2）可以配合虚拟机的IOMMU，实现设备对客户机物理地址的直接访问（IOVMFD）。而PASID特性的普及，使得单个设备能支持多个独立的地址空间，为云计算中的SR-IOV、用户态驱动等高级特性奠定了基础。

因此，深入理解SMMU的DMA内存分配机制，不仅是掌握Linux内核驱动开发的关键一环，更是通往现代高性能、安全计算系统核心的必经之路。下次当你享受无损音乐时，或许会想起，正是这套精妙的机制，在无声处保障着数据的洪流有序奔腾。