0

推荐

Linux 内存管理系统：初始化
作者：Joe Knapka
臭翻：colyli
内存管理系统的初始化处理流程分为三个基本阶段：
激活页内存管理
 在swapper_pg_dir中初始化内核的页表
 初始化一系列和内存管理相关的内核数据
 Turning On Paging (i386)
启动分页机制(i386)
Kernel 代码被加载到物理地址0x100000(1MB)，在分页机制打开后被重新映射到
PAGE_OFFSET + 0x100000的位置（PAGE_OFFSET在IA32上为3GB，即进程虚拟地址中用户
空间与内核空间的分界处）。这是通过将物理地址映射到编译进来的页表 (在
arch/i386/kernel/head.S中)的0－8MB以及PAGE_OFFSET－PAGE_OFFSET+8MB实现的。然后
我们跳转到init/main.c中的start_kernel，这个函数被定位到PAGE_OFFSET+某一个地址。
这看起来有些狡猾。要注意到在head.S中启动分页机制的代码是通过让它自己所执行的地
址空间不再有效的方式来实现这一点的；因此0－4MB被映射（不明白：hence the 0-4MB
identity mapping.）。在分页机制没有启动之前，start_kernel是不会被调用的，我们假
定他运行在PAGE_OFFSET+某一个地方的位置。因此head.S中的页表必须同样映射内核代码
所使用的地址，这样后继才能跳转到staert_kernel处；因此PAGE_OFFSET被映射（不明
白：hence the PAGE_OFFSET mapping.）。
下面在head.S中分页机制启动时的一些神奇的代码：
/*
* Enable paging
*/
3:
movl $swapper_pg_dir-__PAGE_OFFSET,%eax
movl %eax,%cr3 /* set the page table pointer.. */
movl %cr0,%eax
orl $0x80000000,%eax
movl %eax,%cr0 /* ..and set paging (PG) bit */
jmp 1f /* flush the prefetch-queue */
1:
movl $1f,%eax
jmp *%eax /* make sure eip is relocated */
1:
在两个1的label之间的代码将第二个label 1的地址加载到EAX中，然后跳转到那里。这
时，指令指针寄存器EIP指向1MB＋某个数值的物理地址。而label都在内核的虚拟地址空
间(PAGE_OFFSET+某个位置)，所以这段代码将EIP有效的从物理地址空间重新定位到了虚
拟地址空间。
Start_kernel函数初始化了所有的内核数据，然后启动了init内核线程。Start_kernel中
最初的几件事情之一就是调用setup_arch函数，这是一个和具体的体系结构相关的设置函
数， 调用了更底层的初始化细节。对于x86 平台而言， 这些函数在
arch/i386/kernel/setup.c中。
在setup_arch 中和内存相关的第一件事就是计算低端内存(low-memory) 和高端内存
(high-memory)的有效页的数目；每种内存类型(each memory type)最高端的页的数目分别
保存在全局变量highstart_pfn和highend_pfn中。高端内存并不是直接映射到内核的虚拟
内存(VM)中；这是后面要讨论的。
接下来，setup_arch 调用init_bootmem 函数以初始化启动时的内存分配器(boot-time
memory allocator)。Bootmem内存分配器仅仅在系统boot的过程中使用，为永久的内核数
据分配页。因此我们不会对它涉及太多。需要记住的就是bootmem 分配器(bootmem
allocator)在内核初始化时提供页，这些页为内核专门预留，就好像他们是从内核景象文
件中载入的一样，他们在系统启动以后不参与任何的内存管理活动。
初始化内核页表
之后，setup_arch调用在arch/i386/mm/init.c中的paging_init函数。这个函数做了一些
事情。首先它调用pagetable_init函数去映射整个的物理内存，或者在PAGE_OFFSET到4GB
之间的尽可能多的物理内存，这是从PAGE_OFFSET处开始。
在pagetable_init函数中，我们在swapper_pg_dir中精确的建立了内核的页表，映射到
截至PAGE_OFFSET的整个物理内存。
这是一个将正确的数值填充到页目录和页表中去的简单的算术活。映射建立在
swapper_pg_dir中，即kernel页目录；这也是初始化页机制时所使用的页目录。（当使用
4MB的页表的时候，直到下一个4MB边界的虚拟地址才会被映射在这里，但这没有什么，
因为我们不会使用这个内存所以没有什么问题）。如果有这里有剩下物理内存没有被映射，
那就是大于4GB－PAGE_OFFSET范围的内存，这些内存只有CONFIG_HIGHMEM选项被设置后
才能使用（即使用大于4GB的内存）。
在接近pagetable_init函数的尾部，我们调用了fixrange_init为编译时固定的虚拟内存
映射预留页表。这些表将硬编码到Kernel中的虚拟地址进行映射，但是他们并不是已经加
载的内核数据的一部分。Fixmap表在运行时调用set_fixmap函数被映射到物理内存。
在初始化了fixmap之后，如果CONFIG_HIGHMEM被设置了，我们还要分配一些页表给kmap
分配器。Kmap允许kernel将物理地址的任何页映射到kernel的虚拟地址空间，以临时使用。
这很有用，例如对在pagetable_init中不能直接映射的物理内存进行映射。
Fixmap 和kmap 页表们占据了kernel 虚拟空间顶部的一部分——因此这些地址不能在
PAGE_OFFSET映射中被永久的映射到物理页上。由于这个原因，Kernel虚拟内存的顶部的
128MB就被预留了（vmalloc分配器仍然是用这个范围内的地址）。（下面这句实在是不知
道怎么翻译） Any physical pages that would otherwise be mapped into the
PAGE_OFFSET mapping in the 4GB-128MB range are instead (if CONFIG_HIGHMEM is
specified) included in the high memory zone, accessible to the kernel only via
kmap()。如果没有设置CONFIG_HIGMEM，这些页就完全是不可用的。这仅针对配置有大量内
存的机器（900多MB或者更多）。例如，如果PAGE_OFFSET=3GB，并且机器有2GB的RAM，
那么只有开始的1GB-128MB的物理内存可以被映射到PAGE_OFFSET和fixmap/kmap地址范
围之间。剩余的页是不可用的——实际上对于用户进程映射来说，他们是可以直接映射的页
——但是内核不能够直接访问它们。
回到paging_init，我们可以通过调用kmap_init函数来初始化kmap系统，kmap_init简
单的缓存了最先的kmap_pagetable[在TLB？]。然后，我们通过计算zone的大小并调用
free_area_init 去建立mem_map 和初始化freelist，初始化了zone 分配器。所有的
freelist被初始化为空，并且所有的页都被标志为reserved（不可被VM系统访问）；这
种情况之后会被纠正。
当paging_init完成后，物理内存的分布如下[注意在2.4的内核中这不全对]：
0x00000000: 0-page
0x00100000: kernel-text
0x????????: kernel_data
0x???????? =_end: whole-mem pagetables
0x????????: fixmap pagetables
0x????????: zone data (mem_map, zone_structs, freelists &c)
0x???????? =start_mem: free pages
这块内存被swapper_pg_dir和whole-mem-pagetables映射以寻址PAGE_OFFSET。
进一步的VM子系统初始化
现在我们回到start_kernel。在paging_init完成后，我们为内核的其他子系统进行一些
额外的配置工作，它们中的一些使用bootmem分配器分配额外的内核内存。从内存管理的观
点来看，这其中最重要的是kmem_cache_init，他初始化了slab分配器的数据。
在kmem_cache_init 调用之后不久，我们调用了mem_init。这个通过清除空闲物理页的
zone数据中的PG_RESERVED位在free_area_init的开始完成了初始化freelist的工作；
为不能被用为DMA的页清除PG_DMA位；然后释放所有可用的页到他们各自的zone中。最后
一步，在bootmem.c 中的free_all_bootmem函数中完成，很有趣。他建立了伙伴位图和
freelist描述了所有存在的没有预留的页，这是通过简单的释放他们并让free_page_ok
做正确的事情。一旦mem_init被调用了，bootmem分配器就不再使用了，所以它的所有的
页也会被释放到zone分配器的世界中。
段
段用来将线性地址空间划分为专用的块。线性空间是被VM子系统管理的。X86体系结构从硬
件上支持段机制；你可以按照段+段内偏移量的方式指定一个地址，这里地址被描述为一定
范围的线性（虚拟地址）并带有特定的属性（如保护属性）。实际上，在x86体系结构中你
必须使用段机制。所以我们要设置4个段：
一个kernel text段：从0 到4GB
一个kernel data段：从0 到4GB
一个user text段：从0 到4GB
一个user data段：从0 到4GB
因此我们可以使用任何一个有效的段选择器(segment selector)访问整个虚拟地址空间。
问题：
段是在哪里被设置的？
答案：
全局描述符表（GDT）定义在head.s的450行。 GDT寄存器在250行被加载。
问题：
为什么将内核段和用户端分离开。是否他们都有权限访问整个4GB的范围？
答案：
这是因为内核和用户段的保护机制有区别：
.quad 0x00cf9a000000ffff /* 0x10 kernel 4GB code at 0x00000000 */
.quad 0x00cf92000000ffff /* 0x18 kernel 4GB data at 0x00000000 */
.quad 0x00cffa000000ffff /* 0x23 user 4GB code at 0x00000000 */
.quad 0x00cff2000000ffff /* 0x2B user 4GB data at 0x00000000 */
段寄存器(CS，DS等)包含有一个13位的描述符表的索引，索引指向的描述符告诉CPU所选
择的段的属性。段选择器的低3位没有被用来索引描述符表，而是用来保存描述符类型（全
局或局部）以及需要的特权级。因此内核段选择器0x10和0x18使用特权级0（RPL0），用
户选择器0x23和0x2B使用最特权级RPL 3。
要注意到第三个高序字节的高位组对应内核和用户也是不同的：对内核，描述符特权级
（DPL）为0；对用户DPL为3。如果你阅读了Intel的文档，你将看到确切的含义，但是由
于Linux内核的x86段保护没有涉及太多，所以我就不再讨论太多了。

下面的命令是我自己增加的命令，不使用uImage，直接引导zImage文件。

具体方法是使用tftp命令从网络下载zImage文件到内存中或者直接读取flash数据，拷贝到内存中，假设拷贝到了A地址处，接下来就可以调用：
 # bootzimage A
来引导linux内核了，具体分析见下面说明。

 Uboot在设置启动命令的时候使用的是Tag方式，也就是内核现在期望使用的参数传递方式。还有一种引导设置方式，就是采用2.2以及以前版本使用的参数设置方式，2.4和2.6内核为了兼容之前版本参数设置，对老版本参数数据进行了解析，转换成了内部tag方式。这样我们完全可以使用老版本的参数传递方式。
 Setup.h文件中定义了老版本参数传递结构：
#define COMMAND_LINE_SIZE 1024  // 命令行最多1024字节

/* This is the old deprecated way to pass parameters to the kernel */
struct param_struct {
    union {
 struct {
     unsigned long page_size;  // 内存的页面大小
     unsigned long nr_pages;   // 内存页面数量
     unsigned long ramdisk_size;  // RAM disk配置, 可以不用
     unsigned long flags;  /* 12 */
#define FLAG_READONLY 1
#define FLAG_RDLOAD 4
#define FLAG_RDPROMPT 8
     unsigned long rootdev;  /* 16 */
     unsigned long video_num_cols; /* 20 */
     unsigned long video_num_rows; /* 24 */
     unsigned long video_x;  /* 28 */
     unsigned long video_y;  /* 32 */
     unsigned long memc_control_reg; /* 36 */
     unsigned char sounddefault;  /* 40 */
     unsigned char adfsdrives;  /* 41 */
     unsigned char bytes_per_char_h; /* 42 */
     unsigned char bytes_per_char_v; /* 43 */
     unsigned long pages_in_bank[4]; /* 44 */
     unsigned long pages_in_vram; /* 60 */
     unsigned long initrd_start;  /* 64 */
     unsigned long initrd_size;  /* 68 */
     unsigned long rd_start;  /* 72 */
     unsigned long system_rev;  /* 76 */
     unsigned long system_serial_low; /* 80 */
     unsigned long system_serial_high; /* 84 */
     unsigned long mem_fclk_21285;       /* 88 */
 } s;
 char unused[256];
    } u1;
    union {
 char paths[8][128];
 struct {
     unsigned long magic;
     char n[1024 - sizeof(unsigned long)];
 } s;
    } u2;
    char commandline[COMMAND_LINE_SIZE];  // 命令行启动参数
};
在整个结构中，最关键的部分是u1.s.page_size，u1.s.nr_pages和commandline域。这三个域也是必须设置的域！
代码如下：
#define LINUX_MACHINE_ID 406  // 见后面说明
#define LINUX_PAGE_SHIFT 12  // 页面大小4K
#define LINUX_PAGE_SIZE  (1<<LINUX_PAGE_SHIFT)

int do_bootzimage(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
 int i;
 u32 addr;
 char *cmdline = getenv ("bootargs"); // 获得命令行参数
 void (*run)(int zero, int arch);   // 定义引导内核的函数原型
 
// 设置引导参数所处的位置
 struct param_struct *params = (struct param_struct *)0xa0000100;
 
 // 设置内核加载地址
 if (argc<2)
  addr = load_addr;  // 默认的加载地址
 else
// 调用命令时参数传递了地址, 那么就使用指定的地址
  addr = simple_strtoul(argv[1], NULL, 16); 

  // 接下来将结构的数据清零, 不用的全部清零, 防止出错
 for(i=0; i<(sizeof(struct param_struct)>>2); i++)
  ((u32 *)params)[i] = 0;
 
 // 设置u1.s.page_size和u1.s.nr_pages参数, 这两个参数由内核自动解析.
 params->u1.s.page_size = LINUX_PAGE_SIZE;
 params->u1.s.nr_pages = (0x04000000 >> LINUX_PAGE_SHIFT);

 // 拷贝命令行参数到命令位置
 memcpy(params->commandline, cmdline, strlen(cmdline));
 
 run = (void (*)(int, int))addr;
// 执行内核程序, 传递两个参数进去, 第2个参数指定了ARCH值, 必须与
// 内核配置的相同, 否则会出现”Error: a”错误!!
run(0, LINUX_MACHINE_ID);
}
// 最后定义bootzImage命令，实现函数是do_bootzimage。
U_BOOT_CMD(
 bootzimage, 2, 1, do_bootzimage,
 "bootzimage - boot zImage from ram.n",
 " [addr] boot zImage directoly. "
);

 这里我们在引导的时候使用了老版本的参数传递方式，下面时Linux内核在进行参数解析时的代码，可以看到，内核将这些参数自动转换成能够识别的类型：
 内核（2.6.9）的init/main.c文件中的start_kernel()函数中调用了setup_arch()函数：
asmlinkage void __init start_kernel(void)
{
 char * command_line;
 extern struct kernel_param __start___param[], __stop___param[];
/*
 * Interrupts are still disabled. Do necessary setups, then
 * enable them
 */
 lock_kernel();
 page_address_init();
 printk(linux_banner);
 setup_arch(&command_line); // 这个函数中将对传递的参数进行解析
 setup_per_cpu_areas();
…
 setup_arch()函数位于体系结构相关的代码中，本例中存在于arch/arm/kernel/setup.c文件中。
 以下是该函数的部分内容
…
 struct tag *tags = (struct tag *)&init_tags;
…
 // 判断是不是tag的ATAG_CORE, 老式的参数是不能满足要求的, 如果是老式的
 // 参数那么将会执行convert_to_tag_list(tags)将老式参数转换成新的参数类型.
 if (tags->hdr.tag != ATAG_CORE)
  convert_to_tag_list(tags);

 convert_to_tag_list()函数实现在arch/arm/kernel/compat.c文件中，该函数随后调用build_tag_list()函数进行参数重组，具体可以参考内核的源代码。

vivi与Linux kernel的参数传递情景分析（下） - Vivi - CalmArrow

文章说明：calmarrow（lqm）原创 文章引自：http://piaoxiang.cublog.cn

linux2.6内核中的MACHINE_START宏