简介：这份资源围绕直接存储（DMA Remapping）技术展开，面向操作系统内核开发者、驱动工程师及计算机体系结构学习者，帮助理解PCI设备与系统内存之间安全高效的数据传输机制。压缩包内仅含1个C语言源文件，整体约9KB，属于轻量级代码阅读材料，核心内容应为DMA重映射功能的实现或管理逻辑。代码中预计涉及DMA翻译表的创建与更新、设备注册与初始化、设备物理地址到内存地址的转换、重映射中断处理以及地址空间隔离等安全机制，同时可能包含缓存一致性与预读取等性能优化策略，以及地址对齐错误、越界访问等异常检测与报告逻辑。已有173人学习关注，适合希望深入理解DMAR硬件组件工作原理、在操作系统层面实现直接存储管理或开发相关驱动程序的读者参考研读。
1. 直接存储到底绕过了什么：从 dmar.rar 里翻出来的那点硬货
很多人第一次看到“直接存储”这四个字，脑子里蹦出来的是“绕过文件系统直接怼硬盘”。方向对了一半，但真正让这套东西值钱的，是它把数据通路里最容易被忽视的一层——内核页缓存和块设备调度——给短路了。我拿到dmar.rar这个包的时候，第一反应是又一个改了个名字的 IO 库，解压看完目录结构才发现，它是一套围绕 Direct Memory Access Remap 思路做的用户态直接存储访问示例，核心目标只有一个：让应用层的数据缓冲区直接和存储控制器对话，中间不经过内核的 bounce buffer 拷贝。
这玩意儿解决的是真实存在的痛点。你在做高吞吐日志写入、视频帧落盘、或者数据库 WAL 顺序写的时候，常规write()调用看着简单，实际上数据从用户缓冲区到磁盘要经历“用户态→内核页缓存→块层→驱动→DMA 映射”这条长链路，每一次拷贝都是 CPU 周期和内存带宽的消耗。dmar.rar里提供的代码路径，是把用户态已经对齐的缓冲区通过 DMA 重映射机制直接挂到存储设备的传输描述符上，内核只负责建立映射和回收，不参与数据搬运。适合谁？适合那些已经用O_DIRECT踩过坑、发现页对齐和块大小限制太折磨人、想再往下走一步的存储方向工程师。不适合刚学文件 IO 的新手，因为里面涉及 IOMMU、 scatter-gather 列表和完成队列，抽象层次掉了一大截。
2. 拆开 dmar.rar：目录结构、编译链路与第一个可跑通的直接存储写
2.1 包内文件布局与各模块职责
解压之后不要急着make，先花五分钟把目录树看清楚。dmar.rar的典型布局是这样的：顶层一个Makefile，一个include/放公共头文件，一个src/放核心实现，一个examples/放调用示例，外加一个scripts/放环境检查脚本。核心文件通常包括dmar_core.c、dmar_queue.c、dmar_map.c和dmar_compat.h。dmar_core.c负责初始化 DMA 重映射域和分配 IOMMU 页表；dmar_queue.c实现提交队列和完成队列的环形缓冲区管理；dmar_map.c处理用户缓冲区到设备可见地址的映射与解除映射；dmar_compat.h做内核版本差异的宏适配，因为 IOMMU 相关 API 在不同内核小版本之间改过签名。
我一般会先看Makefile里的KDIR变量指向哪里，确认它期望的内核头文件路径和你当前运行的内核是否一致。不一致的话，编译能过但加载模块时会报version magic错误。examples/下面通常有一个simple_write.c，这个文件是整包最值得先读的，因为它把“打开设备→分配对齐缓冲区→建立映射→提交写请求→等待完成→解除映射”这条完整链路用不到两百行代码串起来了。
2.2 编译与加载：从 make 到 insmod 的完整命令
假设你已经把包解压到/opt/dmar，并且当前内核头文件已经安装。编译步骤不复杂，但每一步都有讲究。
# 进入源码目录 cd /opt/dmar # 查看 Makefile 里内核路径是否指向当前运行内核 grep KDIR Makefile # 如果指向 /lib/modules/$(uname -r)/build 则直接编译 make -j$(nproc) # 编译产物通常在 src/ 下，检查 .ko 文件是否生成 ls -l src/*.ko # 加载模块前先确认 IOMMU 在 BIOS 和内核里都开了 dmesg | grep -i iommu # 加载模块 sudo insmod src/dmar_core.ko # 确认模块已加载并查看它注册的字符设备主设备号 lsmod | grep dmar cat /proc/devices | grep dmar编译阶段最常见的翻车是内核头文件版本和运行内核不匹配。make报错asm/rwonce.h: No such file或者implicit declaration of function 'iommu_map'，基本都是这个原因。解决方法是安装linux-headers-$(uname -r)并把KDIR显式指过去。加载阶段如果insmod返回Operation not permitted，先检查 Secure Boot 是否开着，开了的话未签名模块加载不进去，要么签名要么在 BIOS 里关掉。dmesg | grep -i iommu如果没有任何输出，说明 IOMMU 没启用，后面所有直接映射都无从谈起，需要进 BIOS 打开 VT-d 或 AMD-Vi。
2.3 第一个直接存储写请求：代码逐段拆解
examples/simple_write.c是整个包里最值得逐行读的文件。下面这段代码是我根据包内示例整理出的核心逻辑，保留了关键调用和参数。
#include <dmar.h> #include <fcntl.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #define BUF_SIZE (1024 * 1024) // 1MB 缓冲区 #define ALIGNMENT 4096 // 页对齐，通常等于系统页大小 int main(void) { int dev_fd; void *buf; dmar_handle_t *handle; dmar_map_t *map; ssize_t ret; // 打开 dmar 字符设备，路径由模块加载后创建 dev_fd = open("/dev/dmar0", O_RDWR); if (dev_fd < 0) { perror("open /dev/dmar0"); return -1; } // 分配页对齐的用户态缓冲区，必须对齐否则映射会失败 if (posix_memalign(&buf, ALIGNMENT, BUF_SIZE) != 0) { perror("posix_memalign"); close(dev_fd); return -1; } memset(buf, 0xAB, BUF_SIZE); // 填充测试数据 // 初始化 dmar 句柄，绑定到设备文件描述符 handle = dmar_init(dev_fd); if (!handle) { perror("dmar_init"); free(buf); close(dev_fd); return -1; } // 建立用户缓冲区到设备可见地址的映射 map = dmar_map_buffer(handle, buf, BUF_SIZE, DMAR_DIR_WRITE); if (!map) { perror("dmar_map_buffer"); dmar_destroy(handle); free(buf); close(dev_fd); return -1; } // 提交写请求，offset 为设备内偏移，这里从 0 开始写 ret = dmar_submit_write(handle, map, 0, BUF_SIZE); if (ret < 0) { perror("dmar_submit_write"); dmar_unmap_buffer(handle, map); dmar_destroy(handle); free(buf); close(dev_fd); return -1; } // 等待完成，超时设为 5000 毫秒 ret = dmar_wait_completion(handle, 5000); if (ret < 0) { perror("dmar_wait_completion"); } // 清理顺序不能乱：先解映射，再销毁句柄，最后释放缓冲区 dmar_unmap_buffer(handle, map); dmar_destroy(handle); free(buf); close(dev_fd); return ret < 0 ? -1 : 0; }这段代码的逻辑链条是：打开设备 → 分配对齐内存 → 初始化句柄 → 建立 DMA 映射 → 提交写 → 等待完成 → 逆序清理。参数上最需要盯住的是posix_memalign的对齐值，ALIGNMENT必须等于系统页大小，x86 上通常是 4096，ARM64 上可能是 64K，写死 4096 在 ARM 服务器上会直接映射失败。dmar_map_buffer的第四个参数DMAR_DIR_WRITE表示这块缓冲区是写给设备的，如果方向搞反，IOMMU 会拒绝映射并返回-EACCES。dmar_wait_completion的超时单位是毫秒，设太小在慢速设备上会频繁超时，设太大出问题时排查周期会拉长，我一般先用 5000 跑通再按实际设备延迟调整。
编译这个示例需要链接libdmar，包里的Makefile通常已经写好了-ldmar -lpthread。如果你手动编译，命令是gcc -o simple_write simple_write.c -I../include -L../src -ldmar -lpthread。运行前确认/dev/dmar0存在且权限允许当前用户读写，否则open会返回Permission denied。
3. 直接存储的映射机制与队列参数：为什么你的 IOMMU 域老是不够用
3.1 DMA 重映射域与地址翻译的底层逻辑
直接存储能成立的前提是 IOMMU 把设备发出的地址翻译成物理地址。dmar.rar里的dmar_core.c在初始化时会创建一个 DMA 重映射域，这个域本质上是一棵多级页表，设备看到的虚拟地址经过这棵页表查到真正的物理页。每个域有独立的地址空间，所以不同进程或不同设备可以互不干扰地使用相同的设备虚拟地址。问题在于，IOMMU 的域数量是有限的，典型 x86 平台上 IOVA 空间和域描述符都有上限。如果你的应用频繁创建和销毁映射而不复用域，很快就会遇到dmar_map_buffer返回-ENOMEM或者-EBUSY。
我见过最常见的误用是每次写请求都调一次dmar_init和dmar_destroy，把域当一次性资源用。正确做法是一个长期运行的工作线程持有一个dmar_handle_t，所有映射和提交都复用这个句柄，只在进程退出时销毁。dmar_map_buffer内部会尝试在已有域里找空闲 IOVA 区间，复用句柄能让 IOVA 分配器保持热状态，减少碎片。
3.2 提交队列深度与完成队列超时的参数调优
dmar_queue.c里有两个关键参数：提交队列深度和完成队列深度。它们决定了一次能挂多少请求、完成事件能缓冲多少。默认值通常偏保守，提交队列 64、完成队列 128。在高吞吐场景下，这个深度会导致提交频繁阻塞，因为队列满了之后dmar_submit_write会等待空闲槽位。
调整方式是在模块加载时传参：sudo insmod src/dmar_core.ko sq_depth=256 cq_depth=512。但别拍脑袋往大了设，队列深度受限于连续内存分配大小，设太大在内存碎片化时insmod会直接失败。我一般按“预期并发请求数 × 2”来估，比如你同时有 100 个写请求在飞，设 256 就够。完成队列超时参数cq_timeout_ms默认 10000，在 NVMe 设备上可以降到 2000，在机械盘上反而要升到 30000，因为寻道延迟波动大。
注意：修改队列深度后必须重新加载模块，运行中无法动态调整。重新加载前确保没有进程还持有
/dev/dmar0，否则rmmod会报Device or resource busy。
3.3 缓冲区对齐与 scatter-gather 列表的边界条件
直接存储对缓冲区的物理连续性有要求。dmar_map_buffer接受的是虚拟地址，但底层需要把对应的物理页填进 scatter-gather 列表。如果缓冲区跨越了非连续物理页，映射逻辑会尝试构建多段 SG 列表。这里有个隐藏边界：SG 列表的段数上限由dmar_core.c里的MAX_SG_SEGMENTS宏控制，默认 32。一个 1MB 的缓冲区如果物理页碎片化严重，可能超过 32 段，映射就会失败并返回-EINVAL。
规避方法是尽量分配大页。在 Linux 上可以用mmap加MAP_HUGETLB分配 2MB 大页，这样 1MB 缓冲区最多占一个页，SG 段数直接降到 1。如果不能用大页，那就把单次映射的缓冲区大小控制在 64KB 以内，减少跨页概率。examples/里还有一个sg_test.c，专门用来打印不同大小缓冲区的 SG 段数，调优前先跑一遍这个，心里有数再改参数。
4. 避坑与排查：直接存储翻车现场记录
4.1 映射成功但写入数据全是 0x00
现象：dmar_submit_write返回成功，dmar_wait_completion也正常完成，但读回设备数据发现全是零。原因通常是缓冲区在映射之后被memset或者被其他线程改写，而 CPU 缓存没有刷到设备可见的内存。直接存储绕过了内核页缓存，但 CPU 的 L1/L2 缓存还在。解决方式是在dmar_map_buffer之后、dmar_submit_write之前，对缓冲区做一次显式的 cache flush，或者把缓冲区映射为非缓存属性。dmar.rar的dmar_map.c里有一个dmar_flush_buffer函数，但示例代码里没调用，需要自己加上。
4.2 insmod 报 Unknown symbol iommu_map
现象：编译通过，加载时dmesg显示Unknown symbol iommu_map (err -2)。原因是内核配置里 IOMMU 支持没有编进内核或者编成了模块但没加载。检查/boot/config-$(uname -r)里CONFIG_IOMMU_SUPPORT和CONFIG_INTEL_IOMMU（或CONFIG_AMD_IOMMU）是否为y或m。如果是m，先modprobe intel_iommu再加载dmar_core.ko。另外，如果内核启动参数里加了iommu=off，那所有 IOMMU 功能都被禁用，必须去掉这个参数重启。
4.3 高并发下完成队列溢出丢事件
现象：压力测试跑几分钟后，dmar_wait_completion开始随机返回超时，但设备端显示请求已完成。原因是完成队列深度不够，短时间内大量完成事件涌入，环形缓冲区溢出，旧事件被覆盖。解决方法是增大cq_depth模块参数，同时在应用层用多个线程分别等待不同的完成队列实例。dmar.rar支持创建多个完成队列，dmar_init的第二个参数可以指定队列数量，默认是 1，高并发场景下建议设为工作线程数。
4.4 卸载模块时卡死
现象：rmmod dmar_core命令挂起，终端无响应。原因是还有映射没有解除，IOMMU 域无法释放，模块引用计数不为零。排查方法是先lsmod | grep dmar看引用计数，如果大于 0，用lsof /dev/dmar0找到还持有设备文件的进程，杀掉之后再rmmod。如果lsof也卡住，说明有线程阻塞在dmar_wait_completion里，需要先让那个线程超时退出。预防措施是在应用退出逻辑里保证dmar_unmap_buffer和dmar_destroy一定被执行，用atexit注册清理函数比手动调用可靠。
4.5 不同内核版本下编译报错 implicit declaration
现象：在 5.15 内核上编译通过，换到 6.1 内核上报一堆implicit declaration of function。原因是 IOMMU 相关 API 在 6.x 里改了头文件包含路径和函数签名。dmar_compat.h里虽然有版本宏，但可能没覆盖到你用的具体小版本。解决方法是根据报错的函数名，去/usr/src/linux-headers-$(uname -r)/include下 grep 正确的头文件，然后手动在dmar_compat.h里加一个版本分支。这个活比较琐碎，但比改核心逻辑安全。
5. 进阶：用 dmar.rar 做零拷贝日志落盘的验证与调优
把直接存储用到日志落盘场景，核心思路是预分配一组固定大小的对齐缓冲区，组成环形池，每个缓冲区映射一次后反复复用，避免频繁 map/unmap 的开销。dmar.rar的examples/里有一个log_writer.c骨架，但只做了单次写，要改成持续写入需要自己加循环和缓冲区管理。我一般会这样做：初始化时分配 16 个 64KB 的对齐缓冲区，每个都调一次dmar_map_buffer建立长期映射，然后工作线程从池里取空闲缓冲区、填充日志、提交写请求、在完成回调里把缓冲区标记为空闲。这样映射只建立一次，后续所有写请求都是零拷贝提交。
验证是否真正绕过了内核拷贝，可以看两个指标。一是perf stat -e cpu-clock,task-clock对比直接存储写和普通write()写的 CPU 时间，前者应该明显低一截，因为少了copy_from_user的开销。二是看/proc/interrupts里 IOMMU 相关中断的数量，如果映射复用做得好，中断频率应该和请求提交频率成正比，而不是和缓冲区分配频率成正比。调优时先把sq_depth和cq_depth按并发线程数的两倍设置，然后逐步加压，观察dmar_wait_completion的超时率，超过 0.1% 就继续加深度或者减少单次提交的数据量。
还有一个容易忽略的点是完成队列的中断合并。dmar_core.ko加载时可以传cq_irq_coalesce=1，让多个完成事件合并成一次中断，降低 CPU 中断负载。但在延迟敏感场景下要关掉，因为合并会引入额外等待。我通常先用合并模式跑吞吐，测出上限后再关掉合并测延迟，两个数据都拿到再决定线上用哪个。
从那以后我每次拿到类似dmar.rar这种直接存储的包，都强制先跑一遍sg_test看 SG 段数，再跑simple_write确认基本链路，最后才改业务代码。这个顺序能省掉大量“映射失败但不知道哪一步错了”的排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
