一、音频smmu 内存访问问题

在工作中，遇到一个smmu问题，主要log信息如下：

arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from soc:spf_core_platform:qcom,msm-audio-ion!
arm-smmu 15000000.apps-smmu: FAR = 0x000000001fff8000
arm-smmu 15000000.apps-smmu: PAR = 0x0000000000000000
arm-smmu 15000000.apps-smmu: FSR = 0x40000408 [PF R SS]
arm-smmu 15000000.apps-smmu: FSYNR0 = 0x320002
arm-smmu 15000000.apps-smmu: FSYNR1 = 0xe00e
arm-smmu 15000000.apps-smmu: context bank# = 0x30
arm-smmu 15000000.apps-smmu: TTBR0 = 0x0000000000000000
arm-smmu 15000000.apps-smmu: TTBR1 = 0x0000000000000000
arm-smmu 15000000.apps-smmu: SCTLR = 0x0a5f00e7 ACTLR = 0x00000003
arm-smmu 15000000.apps-smmu: CBAR = 0x0001f300
arm-smmu 15000000.apps-smmu: MAIR0 = 0xf404ff44 MAIR1 = 0x0000efe4
arm-smmu 15000000.apps-smmu: SID = 0x1001
arm-smmu 15000000.apps-smmu: Client info: BID=0x7, PID=0x0, MId=0xe
arm-smmu 15000000.apps-smmu: soft iova-to-phys=0x00000000bc299000
arm-smmu 15000000.apps-smmu: hard iova-to-phys(ATOS)=0x00000000bc299000

1、从堆栈来看大致可以了解到, 这是由于SMMU监测到某个模块非法的访问DMA地址后, 引起了内核崩溃. 那么, 为何有这个错误SMMU访问错误? 这个错误又是哪个模块导致的? 是在什么情况下引起的SMMU内存错误了? 这不得不从SMMU本身说起.

继续来看下问题的日志. 堆栈的前面一部分是有关SMMU的状态寄存器:
FAR(Fault Address Register): 表示发生错误的IO虚拟地址
PAR(Physical Address Register): 发生错误时查找到的物理地址, 这里是全0, 说明相应的IOVA地址没有映射
FSR(Fault Status Register): 表示SMMU错误的类型(转换/权限等), 这里的值0x40000408 [PF R SS], 说明是一个读操作时引起的页表访问错误
TTBRm(Translation Table Base Address):
TTBR0: 保存Translation Table0的基地址
TTBR1: 保存Translation Table1的基地址
SID(Stream ID): SID是对应设备使用SMMU映射内存时的标识

重点看下如下两行日志, 我们可以知道发生内存映射异常的IOVA地址是0x1fff8000, 对应的SID是0x1001

arm-smmu 15000000.apps-smmu: FAR = 0x000000001fff8000
arm-smmu 15000000.apps-smmu: SID = 0x1001

SID一般在设备树DTS的配置中指定的或者可以在modem代码中查看

路径：/trustzone_images/core/settings/kernel/iortlib/config/xxx/xxx.c

2、理清楚这些SMMU的日志只是第一步, 但是对于为何会发生SMMU访问异常还是毫无头绪. 这个只能通过阅读驱动源代码弄清楚代码流程才能一步步揭开迷雾了.

网卡需要传数据时, 获取到当前的缓冲区对应的DMA内存地址(IOVA)后, 通过SMMU向对应的RAM地址传输数据
发送完成后, 通过中断告知驱动有数据需要接收
CPU接收到中断后, 驱动会把DMA的映射解除, 数据交由CPU处理; 接着驱动把对应的数据发送到协议栈继续处理

那么, 问题来了, SMMU是何时收到DMA访问异常错误的了? 是在第三个步骤, 驱动解除DMA地址映射后, 有地方再次尝试使用该DMA地址导致的吗? 从驱动的逻辑来看, 每次传送完成, DMA地址与RAM地址解除映射后, 没有地方会再次尝试获取该DMA地址了(对应buffer的DMA地址已经置空). 退一步说, 如果是驱动使用的时候发生的问题, 那么异常的堆栈应该会打印出来, 但是现在只有SMMU相关的日志.

所以, 问题的源头只能是在网卡通过SMMU往对应的DMA地址发送数据的时候, 就是说如果网卡给DMA传输数据的大小超过了预分配的buffer的大小的话, SMMU会发现对应的DMA地址没有映射到物理地址, 从而报错. 解决问题的办法也很简单, 只需要把buffer大小由原来的1538修改为2048(2kb)就可以了:

从高通给的一些问题案例来说, 一般SMMU都是由于需要传输的数据大小与实际的buf大小不一致导致的. 总的说来, SMMU的问题看起来十分棘手, 但只要把基本的概念与原理弄清楚, 把代码流程梳理完整, 解决这类问题并不是件十分困难的事情.

二、smmu 相关知识学习

1、概述

简单来说, SMMU(System Memory Management Unit)是ARM为外设访问系统RAM提供了一种类似于MMU的虚拟内存访问机制, 外设可以通过DMA直接访问RAM, 而无需CPU的干预. 如此, 外设可以通过一个虚拟的地址即可访问物理地址(可以不连续), 做到了不同外设之间IO地址空间的彼此独立与隔离. 因此, SMMU也通常被称为IOMMU(Input/Output MMU).

下图是从ARM SMMU Spec手册里的一张SMMU简图: SMMU为设备与RAM之间构建了一个设备虚拟地址(IOVA)与物理地址之间的映射关系, 每次执行DMA数据传输的时候, 都要通过SMMU将IOVA地址翻译成对应的物理地址.

那么对于设备驱动来说, 如何使用SMMU了? 不妨来看下SMMU相关的API.

arm_iommu_create_mapping: 配置设备所要使用的VA(Virtual Address, 虚拟地址)的范围
arm_iommu_attach_device: 将分配好的VA地址范围与设备绑定, 并开启SMMU地址转换
dma_map_single/dma_unmap_single: 分配/去除某个DMA地址, 这种方式是异步的, 常用于一次性传输的场景(传输完成后DMA的映射即解除了)
dma_alloc_coherent/dma_free_coherent: 一致性(consistent), 同步(synchronous)的DMA内存分配方法, 确保CPU与设备的数据始终是同步的, 一般用于需要常驻内存的一些数据
这里不对IOMMU的代码做深入分析了. 有关IOMMU相关的流程可以参考内核代码:

kernel/drivers/iommu: SMMU驱动, 用于配置SMMU, 为设备驱动提供接口
kernel/arch/arm64/mm: 与平台相关的SMMU的页表分配的实现

2、smmu寄存器

FAR(Fault Address Register): 表示发生错误的IO虚拟地址
PAR(Physical Address Register): 发生错误时查找到的物理地址, 这里是全0, 说明相应的IOVA地址没有映射
FSR(Fault Status Register): 表示SMMU错误的类型(转换/权限等), 这里的值0x40000408 [PF R SS], 说明是一个读操作时引起的页表访问错误
TTBRm(Translation Table Base Address):
TTBR0: 保存Translation Table0的基地址
TTBR1: 保存Translation Table1的基地址
SID(Stream ID): SID是对应设备使用SMMU映射内存时的标识

参考
https://mp.weixin.qq.com/s/IsNUsalsE2sZOd2AJlXtjQ?poc_token=HLeZ2WWjwsFSMFprJ21xG6cSnuJWTNdnE0gRy9h5
https://zhuanlan.zhihu.com/p/662140784
https://zhuanlan.zhihu.com/p/650483261