近期在调试PCIe的行情加速卡的驱动。当中使用DMA在CPU和FPGA间数据传输。
最開始使用的是低16M的DMA ZONE的内存，用slab分配器的kmalloc分配获取。但因为最新的需求，须要使用的内存远远超过16M，这样再使用DMA ZONE区域的内存就不够了，那就仅仅能使用DMA32区域的内存来进行DMA传输了。
在我使用的调试机器上。DMA32区域的内存情况例如以下：
由上图可知DMA32 ZONE为16M~4G，高于4G的内存为Normal ZONE。
假设使用DMA32 ZONE的内存，不可以使用slab分配器，否则会panic。
__cache_allocàcache_alloc_refillàcache_grow函数：
|
BUG_ON(flags & GFP_SLAB_BUG_MASK); |
假设设置了GFP_SLAB_BUG_MASK标志，那么就会直接bug_on。GFP_SLAB_BUG_MASK标志的定义例如以下：
|
/* Do not use these with a slab allocator */ #define GFP_SLAB_BUG_MASK |
由于我们须要设置__GFP_DMA32标志，因此在使用DMA32ZONE的内存时候，不能使用slab分配器来分配内存。
因此使用buddy分配器来分配DMA32ZONE的内存供DMA传输使用。这个时候须要注意一个问题：我们的设置是否可以在DMA32 ZONE分配的内存上运行DMA？
之前使用的低16M的DMA ZONE的内存，设置的设备的寻址能力为24bit，如今使用的是16M~4G的DMA32 ZONE，设备须要能在32位地址上运行DMA，调用dma_set_mask设置32bit的寻址能力。
假设不设置32bit的寻址能力，那么在流式DMA映射的时候就会报错。报错是swiotlb_full函数打印出来的。
|
printk(KERN_ERR "DMA: Out of SW-IOMMU space for %zu bytes at " "device %s\n", dev_name(dev) |
以下分析下DMA映射的相关代码swiotlb_map_page函数实现：
|
/* * If the address happens to be in the device‘s DMA window, * we can safely return the device addr and not worry about bounce * buffering it. */ if return |
此函数中首先调用dma_capable函数检查映射的地址范围是否在设备同意的寻址能力范围内。
|
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) { if return return } |
此函数首先检查有没有设置设备的寻址掩码。调用dma_set_mask函数底层实现就是设置*dev->dma_mask = mask。假设设置DMA_BIT_MASK(32)，那么mask就是0xffffffff。不论什么4G范围内的地址在此检查条件下都能通过。
假设设置的寻址能力为24bit，那么mask就是0xffffff。那么假设从DMA32分配的地址大于此掩码范围，检查就不通过，那么swiotlb_map_page函数就会接着往下运行map_singleàswiotlb_tbl_map_single，并极有可能返回SWIOTLB_MAP_ERROR，进而swiotlb_full中报错。