Linux IO内存静态映射？

在将Linux移植到目标电路板的过程中，有得会建立外设IO内存物理地址到虚拟地址的静态映射，这个映射通过在与电路板对应的map_desc结构体数组中添加新的成员来完成。iotable_init()是最终建立页映射的函数，它通过ACHINE_START、MACHINE_END宏赋值给电路板的map_io()）函数。将Linux *** 作系统移植到特定平台上，MACHINE_START(或者DT_MACHINE_START)、MACHINE_END宏之间的定义针对特定电路板而设计，其中的map_io ()成员函数完成IO内存的静态映射。在一个已经移植好 *** 作系统的内核中，驱动工程师可以对非常规内存区域的IO内存（外设控制器寄存器、MCU内部集成的外设控制器寄存器等）依照电路板的资源使用情况添加到map_desc数组中，但是目前该方法已经不值得推荐。

Cache和DMA本身似乎是两个毫不相关的事物。Cache被用作CPU针对内存的缓存，利用程序的空间局部性和时间局部性原理，达到较高的命中率，从而避免CPU每次都必须要与相对慢速的内存交互数据来提高数据的访问速率。DMA可以作为内存与外设之间传输数据的方式，在这种传输方式之下，数据并不需要经过CPU中转。

假设DMA针对内存的目的地址与Cache缓存的对象没有重叠区域，DMA和Cache之间将相安无事。但是，如果DMA的目的地址与Cache所缓存的内存地址访问有重叠，经过DMA *** 作，与Cache缓存对应的内存中的数据已经被修改，而CPU本身并不知道，它仍然认为Cache中的数据就是内存中的数据，那在以后访问Cache映射的内存时，它仍然使用陈旧的Cache数据。这样就会发生Cache与内存之间数据“不一致性”的错误。

Linux的内存模型，一般为：

地址

作用

说明

>=0xc000 0000

内核虚拟存储器

用户代码不可见区域

<0xc000 0000

Stack（用户栈）

ESP指向栈顶

↓

↑

空闲内存

>=0x4000 0000

文件映射区

<0x4000 0000

↑

空闲内存

Heap(运行时堆)

通过brk/sbrk系统调用扩大堆，向上增长。

.data、.bss(读写段)

从可执行文件中加载

>=0x0804 8000（0x00008000 for arm linux）

.init、.text、.rodata(只读段)

从可执行文件中加载

<0x0804 8000（0x00008000 for arm linux）

保留区域

运行一个测试程序，观察其结果：

#include <stdio.h>

int main(int argc, char* argv[])

{

int first = 0

int* p0 = malloc(1024)

int* p1 = malloc(1024 * 1024)

int* p2 = malloc(512 * 1024 * 1024 )

int* p3 = malloc(1024 * 1024 * 1024 )

printf("main=%p print=%p\n", main, printf)

printf("first=%p\n", &first)

printf("p0=%p p1=%p p2=%p p3=%p\n", p0, p1, p2, p3)

getchar()

return 0

}

运行后，输出结果为：

main=0x8048404 print=0x8048324

first=0xbfcd1264

p0=0x9253008 p1=0xb7ec0008 p2=0x97ebf008 p3=0x57ebe008

my pc （fc5）输出结果如下：

main=0x80483f4 print=0x8048324

first=0xbf848660

p0=0x9ab2008 p1=0xb7e38008 p2=0x97e37008 p3=(nil)

arm-linux输出如下结果：

main=0x8528 print=0x8404

first=0xbec9fe10

p0=0x11008 p1=0x4005a008 p2=(nil) p3=(nil)

main和print两个函数是代码段(.text)的，其地址符合表一的描述。

first是第一个临时变量，由于在first之前还有一些环境变量，它的值并非0xbfffffff，而是0xbfcd1264，这是正常的。

p0是在堆中分配的，其地址小于0x4000 0000，这也是正常的。

但p1和p2也是在堆中分配的，而其地址竟大于0x4000 0000，与表一描述不符。

原因在于：运行时堆的位置与内存管理算法相关，也就是与malloc的实现相关。关于内存管理算法的问题，我们在后继文章中有详细描述，这里只作简要说明。在glibc实现的内存管理算法中，Malloc小块内存是在小于0x4000 0000的内存中分配的，通过brk/sbrk不断向上扩展，而分配大块内存，malloc直接通过系统调用mmap实现，分配得到的地址在文件映射区，所以其地址大于0x4000 0000。

*** 作系统的内存管理，主要分为三个方面。

第一，物理内存的管理，相当于会议室管理员管理会议室。

第二，虚拟地址的管理，也即在项目组的视角，会议室的虚拟地址应该如何组织。

第三，虚拟地址和物理地址如何映射，也即会议室管理员如果管理映射表。

那么虚拟地址和物理地址如何映射呢？

每一个进程都有一个列表vm_area_struct，指向虚拟地址空间的不同的内存块，这个变量的名字叫mmap。

其实内存映射不仅仅是物理内存和虚拟内存之间的映射，还包括将文件中的内容映射到虚拟内存空间。这个时候，访问内存空间就能够访问到文件里面的数据。而仅有物理内存和虚拟内存的映射，是一种特殊情况。

如果我们要申请小块内存，就用brk。brk函数之前已经解析过了，这里就不多说了。如果申请一大块内存，就要用mmap。对于堆的申请来讲，mmap是映射内存空间到物理内存。

另外，如果一个进程想映射一个文件到自己的虚拟内存空间，也要通过mmap系统调用。这个时候mmap是映射内存空间到物理内存再到文件。可见mmap这个系统调用是核心，我们现在来看mmap这个系统调用。

用户态的内存映射机制包含以下几个部分。

物理内存根据NUMA架构分节点。每个节点里面再分区域。每个区域里面再分页。

物理页面通过伙伴系统进行分配。分配的物理页面要变成虚拟地址让上层可以访问，kswapd可以根据物理页面的使用情况对页面进行换入换出。

对于内存的分配需求，可能来自内核态，也可能来自用户态。

对于内核态，kmalloc在分配大内存的时候，以及vmalloc分配不连续物理页的时候，直接使用伙伴系统，分配后转换为虚拟地址，访问的时候需要通过内核页表进行映射。

对于kmem_cache以及kmalloc分配小内存，则使用slub分配器，将伙伴系统分配出来的大块内存切成一小块一小块进行分配。

kmem_cache和kmalloc的部分不会被换出，因为用这两个函数分配的内存多用于保持内核关键的数据结构。内核态中vmalloc分配的部分会被换出，因而当访问的时候，发现不在，就会调用do_page_fault。

对于用户态的内存分配，或者直接调用mmap系统调用分配，或者调用malloc。调用malloc的时候，如果分配小的内存，就用sys_brk系统调用；如果分配大的内存，还是用sys_mmap系统调用。正常情况下，用户态的内存都是可以换出的，因而一旦发现内存中不存在，就会调用do_page_fault。

---