深入 Linux DMA-BUF（二）：CPU 访问、Cache 一致性与 Exporter 实战

从 dma_buf_ops 到用户态 mmap，一文讲透 DMA-BUF 的 CPU 访问体系

本文是《深入 Linux DMA-BUF》系列第二篇。第一篇讲了 dma-buf 的整体架构、零拷贝原理和引用计数机制。本篇聚焦实操层面：当 CPU 需要直接读写 dma-buf 时该怎么做、Cache 一致性问题如何避坑、以及如何从零实现一个最简单的 Exporter 驱动。基于 Linux mainline / AOSP GKI kernel（common 仓库）。

上一篇我们知道，dma-buf 的核心价值是「零拷贝」——让 GPU、Camera、显示控制器等硬件通过 DMA 直接共享同一块物理内存，CPU 完全不参与搬运。

但现实中，CPU 也经常需要直接读写 dma-buf。比如软件格式转换、CPU 渲染、调试 dump 内存内容，这些场景都绕不开「CPU 访问 dma-buf」这个问题。

一旦 CPU 参与进来，就会引入一个棘手的问题：Cache 一致性。CPU 写的数据可能还在 Cache 里没刷到内存，GPU 直接从内存读就拿到了旧数据；反过来，GPU 写了内存，CPU 从 Cache 读到的还是旧数据。这类 bug 难以复现，一旦踩中排查极其痛苦。

本文从 dma_buf_ops 回调接口出发，彻底讲清楚 CPU 访问 dma-buf 的完整路径和正确姿势。

一、dma_buf_ops：Exporter 的「服务菜单」

在第一篇里，我们知道 Exporter 是「分配物理内存的一方」，Importer 是「使用这块内存的一方」。但 Exporter 具体向框架承诺提供哪些服务？这就是 dma_buf_ops 的职责。

Exporter Driver
    │
    └─ 注册 dma_buf_ops（服务菜单）
            ├── map_dma_buf     ← "我能为你的设备建 DMA 映射"（必须）
            ├── unmap_dma_buf   ← "我能拆 DMA 映射"（必须）
            ├── release         ← "我能释放内存"（必须）
            ├── mmap            ← "我能让用户态直接 mmap"（可选）
            ├── vmap/vunmap     ← "我能给内核 CPU 用连续虚拟地址"（可选）
            ├── begin_cpu_access← "CPU 要访问了，我来做 Cache 准备"（可选）
            └── end_cpu_access  ← "CPU 访问完了，我来刷 Cache"（可选）

完整回调结构

/* include/linux/dma-buf.h (Linux mainline / AOSP GKI) */
struct dma_buf_ops {
    /* 可选：设备 attach/detach 时的钩子 */
    int  (*attach)(struct dma_buf *, struct dma_buf_attachment *);
    void (*detach)(struct dma_buf *, struct dma_buf_attachment *);

    /* 必须：DMA 映射/解映射（供 Importer 调用） */
    struct sg_table *(*map_dma_buf)(struct dma_buf_attachment *,
                                    enum dma_data_direction);
    void (*unmap_dma_buf)(struct dma_buf_attachment *,
                           struct sg_table *, enum dma_data_direction);

    /* 必须：释放物理内存（f_count 降为 0 时触发） */
    void (*release)(struct dma_buf *);

    /* 可选：用户态 mmap 支持 */
    int (*mmap)(struct dma_buf *, struct vm_area_struct *);

    /* 可选：内核态 CPU 连续虚拟地址访问 */
    int  (*vmap)(struct dma_buf *, struct iosys_map *);
    void (*vunmap)(struct dma_buf *, struct iosys_map *);

    /* 可选：Cache 同步钩子 */
    int  (*begin_cpu_access)(struct dma_buf *, enum dma_data_direction);
    int  (*end_cpu_access)(struct dma_buf *, enum dma_data_direction);
};

哪些必须实现？

⚠️ 只实现必须的三个回调，就能让 dma-buf 正常工作于纯硬件 DMA 场景。若要支持 CPU 访问，则需要额外实现 mmap 和 begin/end_cpu_access。

二、CPU 访问 dma-buf：两条路径

dma-buf 不只给硬件 DMA 用。CPU 也可以直接访问 dma-buf 物理内存，但路径和注意事项完全不同。

两条路径对比

路径一：硬件 DMA 访问（零拷贝，第一篇讲的）
─────────────────────────────────────────────
Importer
  │
  ├─ dma_buf_attach(dev)          ← 注册设备意图
  ├─ dma_buf_map_attachment()     ← 获取 sg_table（IOVA 路线图）
  │
  └─ 硬件 DMA 控制器按 sg_table 直接访问物理内存
          ↑ CPU 全程不参与，无 Cache 问题 ✅

路径二：CPU 访问（本篇重点）
─────────────────────────────────────────────
用户态：
  mmap(fd) → dma_buf_ops->mmap → 建立 VMA 映射 → CPU 读写
  ⚠️ 必须通过 DMA_BUF_IOCTL_SYNC 同步 Cache

内核态：
  dma_buf_vmap() → 获取连续虚拟地址 → CPU 读写
  ⚠️ 必须调用 begin/end_cpu_access 同步 Cache

三种访问方式对比

用户态 mmap 完整流程

用户空间可以直接对 dma-buf fd 调用 mmap()，像操作普通内存一样读写：

// 1. 获取 dma-buf fd（通常通过 ioctl 从驱动获取）
int fd = get_dmabuf_fd_via_ioctl();

// 2. mmap 到用户虚拟地址空间
void *addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
//   内核流程：mmap() → dma_buf_mmap_internal() → dma_buf_ops->mmap()
//             → Exporter 驱动建立物理页 → VMA 映射完成

// 3. 访问前：告知内核 CPU 准备开始访问（触发 Cache Invalidate）
struct dma_buf_sync sync;
sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
ioctl(fd, DMA_BUF_IOCTL_SYNC, &sync);

// 4. CPU 读写（此时 Cache 已同步，安全）
memcpy(dst, addr, size);
// 或 memset(addr, 0, size);

// 5. 访问后：告知内核 CPU 访问结束（触发 Cache Clean/Flush）
sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
ioctl(fd, DMA_BUF_IOCTL_SYNC, &sync);

// 6. 解除映射
munmap(addr, size);

⚠️ 省略 DMA_BUF_IOCTL_SYNC 是最常见的踩坑点，症状是「偶现画面花屏/数据错乱，重启就好」。

三、Cache 一致性：最容易踩的坑

Cache 一致性问题是 CPU 访问 dma-buf 时最容易踩、最难排查的坑。理解它需要先搞清楚数据在系统中的两个存储位置。

为什么会有 Cache 不一致？

硬件架构（简化）：

  CPU Core
    │
    └─ L1/L2 Cache ──────────────────────────┐
                                              │
  GPU / Camera / NPU                          │
    │                                         │
    └─ DMA 控制器 ──── IOMMU ─────────────►  DDR（物理内存）
                                              │
                                       ← CPU Cache 也缓存这里的数据

问题一：CPU 写 → Device 读（Cache 未刷回 DDR）

CPU 写 → 数据存在 CPU L1/L2 Cache（DDR 里还是旧数据）
                                    ↓
                     Device DMA 从 DDR 读 → 读到旧数据 ❌

问题二：Device 写 → CPU 读（DDR 已更新但 Cache 是旧数据）

Device DMA 写 DDR → DDR 有最新数据
                                    ↓
CPU 读 → 命中 Cache 旧缓存行 → 读到旧数据 ❌

begin/end_cpu_access 的 Cache 操作

dma-buf 框架通过 begin_cpu_access / end_cpu_access 这对接口来强制同步 Cache：

正确的 CPU 访问时序：

[Device 写 DDR 完成]
        ↓
begin_cpu_access(DMA_FROM_DEVICE)   ← Cache Invalidate（清掉旧缓存）
        ↓
CPU 读取 → 直接从 DDR 读最新数据 ✅
        ↓
end_cpu_access(DMA_FROM_DEVICE)     ← 无操作

硬件加速例外：若 SoC 的 GPU/Camera 通过 CCI（Cache Coherent Interconnect）缓存一致性总线接入，硬件自动维护 Cache 一致性，begin/end_cpu_access 可以实现为空函数，无需软件手动维护。

四、编写最简单的 Exporter 驱动

理解了接口，我们来看如何实现一个能工作的 Exporter。以下是最小骨架，只实现必须的三个回调。

完整最小实现

#include <linux/dma-buf.h>
#include <linux/module.h>

/* 私有数据：描述实际分配的物理内存 */
struct my_dmabuf_priv {
    void        *vaddr;   // 内核虚拟地址（如 dma_alloc_coherent 返回）
    dma_addr_t   paddr;   // DMA 物理地址
    size_t       size;
    struct device *dev;
};

/* ① map_dma_buf：为 Importer 设备建立 DMA 映射，返回 sg_table */
static struct sg_table *my_map_dma_buf(struct dma_buf_attachment *attach,
                                        enum dma_data_direction dir)
{
    struct my_dmabuf_priv *priv = attach->dmabuf->priv;
    struct sg_table *sgt;

    sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
    sg_alloc_table(sgt, 1, GFP_KERNEL);
    sg_set_buf(sgt->sgl, priv->vaddr, priv->size);
    dma_map_sgtable(attach->dev, sgt, dir, 0);  // 建立 IOMMU 映射
    return sgt;
}

/* ② unmap_dma_buf：解除 DMA 映射 */
static void my_unmap_dma_buf(struct dma_buf_attachment *attach,
                               struct sg_table *sgt,
                               enum dma_data_direction dir)
{
    dma_unmap_sgtable(attach->dev, sgt, dir, 0);
    sg_free_table(sgt);
    kfree(sgt);
}

/* ③ release：f_count 降为 0，释放物理内存 */
static void my_release(struct dma_buf *dmabuf)
{
    struct my_dmabuf_priv *priv = dmabuf->priv;
    dma_free_coherent(priv->dev, priv->size, priv->vaddr, priv->paddr);
    kfree(priv);
}

/* 注册回调集 */
static const struct dma_buf_ops my_dmabuf_ops = {
    .map_dma_buf   = my_map_dma_buf,
    .unmap_dma_buf = my_unmap_dma_buf,
    .release       = my_release,
    /* 可选扩展：.mmap、.begin_cpu_access、.end_cpu_access */
};

导出并返回 fd

int my_create_dmabuf(struct device *dev, size_t size)
{
    struct my_dmabuf_priv *priv;
    struct dma_buf *dmabuf;
    int fd;

    /* 1. 分配私有数据和物理内存 */
    priv = kzalloc(sizeof(*priv), GFP_KERNEL);
    priv->dev  = dev;
    priv->size = size;
    priv->vaddr = dma_alloc_coherent(dev, size, &priv->paddr, GFP_KERNEL);

    /* 2. 定义导出参数 */
    DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
    exp_info.ops   = &my_dmabuf_ops;
    exp_info.size  = size;
    exp_info.flags = O_CLOEXEC;
    exp_info.priv  = priv;

    /* 3. 导出 dma_buf 对象（f_count = 1）*/
    dmabuf = dma_buf_export(&exp_info);

    /* 4. 转换为用户态可用的 fd（f_count 不变）*/
    fd = dma_buf_fd(dmabuf, O_CLOEXEC);

    return fd;  /* 通过 ioctl 返回给用户态 */
}

Exporter 完整工作流

Exporter Driver
    │
    ├─ dma_alloc_coherent()        ← 分配物理内存
    ├─ 填充 dma_buf_export_info
    ├─ dma_buf_export()            ← 创建 dma_buf，f_count = 1
    ├─ dma_buf_fd()                ← 生成 fd，返回给用户态
    │
用户态 App
    ├─ 收到 fd，传给 GPU/Camera（Importer）
    │   或者自己 mmap(fd) 做 CPU 访问
    │
Importer Driver（GPU 等）
    ├─ dma_buf_get(fd)             ← 获取 dma_buf 指针，f_count++
    ├─ dma_buf_attach(dev)         ← 注册设备
    ├─ dma_buf_map_attachment()    ← 触发 map_dma_buf 回调，得到 sg_table
    └─ 硬件 DMA 按 sg_table 访问物理内存 ✅

总结

读完本文，你应该能回答这些问题：

• ✅ dma_buf_ops 有哪些回调？哪些必须实现，哪些可选？
• ✅ CPU 访问 dma-buf 有哪两条路径？各自适合什么场景？
• ✅ 用户态如何通过 mmap + DMA_BUF_IOCTL_SYNC 安全读写 dma-buf？
• ✅ Cache 一致性问题的根因是什么？begin/end_cpu_access 做了什么？
• ✅ 如何用最少代码实现一个能工作的 Exporter 驱动？

核心结论：dma-buf 的零拷贝优势在纯硬件 DMA 场景下才能完整发挥。一旦引入 CPU 访问，Cache 一致性就成了必须面对的工程问题。正确使用 DMA_BUF_IOCTL_SYNC（用户态）和 begin/end_cpu_access（内核态）是避免数据错乱 bug 的关键。

附录：本文涉及的关键内核接口