进入保护模式

可以在 arch/x86/boot/video.c 找到这个函数的定义。 这个函数首先从 boot_params.hdr 结构 获取 显示模式设置 ：

u16 mode = boot_params.hdr.vid_mode;

至于 boot_params.hdr 数据结构中的内容，是通过 copy_boot_params 函数实现的

关于这个函数的实现细节请查看上一节的内容

boot_params.hdr 中的 vid_mode 是 引导程序 必须填入的字段。可以在 kernel boot protocol 文档中找到关于 vid_mode 的详细信息：

Offset	Proto	Name		Meaning
/Size
01FA/2	ALL	    vid_mode	Video mode control

而在 linux kernel boot protocol 文档中定义了如何通过命令行参数的方式为 vid_mode 字段传入相应的值：

**** SPECIAL COMMAND LINE OPTIONS
vga=<mode>
	<mode> here is either an integer (in C notation, either
	decimal, octal, or hexadecimal) or one of the strings
	"normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
	(meaning 0xFFFD).  This value should be entered into the
	vid_mode field, as it is used by the kernel before the command
	line is parsed.

根据上面的描述，可以通过将 vga 选项写入 grub 或者写到引导程序的配置文件，从而让内核命令行得到相应的显示模式设置信息：

这个选项可以接受不同类型的值来表示相同的意思

比如可以传入 0XFFFD 或者 ask，这2个值都表示需要显示一个菜单让用户选择想要的显示模式

通过这个菜单，用户可以选择想要进入的显示模式

不过进一步了解显示模式的设置过程之前，先回头了解一些重要的概念

在进入保护模式之前的最后一个函数调用发生在 main.c 中的 go_to_protected_mode 函数，就像这个函数的注释说的，这个函数将进行最后的准备工作然后进入保护模式

下面就来具体看看最后的准备工作是什么，以及系统是如何切换到保护模式的

go_to_protected_mode 函数的实现在 arch/x86/boot/pm.c

现在内核将调用 setup_idt 方法来设置 中断描述符表 IDT ：

static void setup_idt(void)
{
  static const struct gdt_ptr null_idt = {0, 0};
  asm volatile("lidtl %0" : : "m" (null_idt));
}

使用 lidtl 指令将 null_idt 所指向的 中断描述符表 引入 寄存器 IDT

由于 null_idt 没有设定中断描述符表的长度（长度为 0 ），所以这段指令执行之后，实际上没有任何中断调用被设置成功（所有中断调用都是空的）

在后面的章节中将看到正确的设置

null_idt 是一个 gdt_ptr 结构 的数据，这个结构的定义如下所示：

struct gdt_ptr {
  u16 len; // 16 bit 的长度字段 
  u32 ptr; // 32 bit 的指针字段 
} __attribute__((packed));

__attribute__((packed)) 意味着这个结构就只包含 48 bit 信息 （ 没有字节对齐优化 ）

在下面一节中，将看到相同的结构将被导入 GDTR 寄存器（GDTR 寄存器是 48 bit 长度的）

在设置完中断描述符表之后，将使用 setup_gdt 函数来设置全局描述符表。在 setup_gdt 函数中，使用 boot_gdt 数组 定义了需要引入 GDTR 寄存器 的 段描述符 信息：

//GDT_ENTRY_BOOT_CS 定义在https://github.com/torvalds/linux/blob/v3.18/arch/x86/include/asm/segment.h#L19 
static const u64 boot_gdt[] __attribute__((aligned(16))) = {
  [GDT_ENTRY_BOOT_CS] = GDT_ENTRY(0xc09b, 0, 0xfffff),
  [GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, 0xfffff),
  [GDT_ENTRY_BOOT_TSS] = GDT_ENTRY(0x0089, 4096, 103),
};

在上面的 boot_gdt 数组中，定义了 代码 ， 数据 和 TSS 段 ( Task State Segment , 任务状态段)的 段描述符

因为并没有设置任何的中断调用（记得上面说的 null_idt吗？），所以 TSS 段并不会被使用到

TSS 段存在的唯一目的就是让 Intel 处理器能够正确进入保护模式

下面详细了解一下 boot_gdt 这个数组，首先，这个数组被 __attribute__((aligned(16))) 修饰，这就意味着这个数组将以 16 字节 为单位 对齐 。通过下面的例子来了解一下什么叫 16 字节对齐：

#include <stdio.h>

struct aligned {
  int a;
}__attribute__((aligned(16)));

struct nonaligned {
  int b;
};

int main(void)
{
  struct aligned    a;
  struct nonaligned na;

  printf("Not aligned - %zu \n", sizeof(na));
  printf("Aligned - %zu \n", sizeof(a));

  return 0;
}

上面的代码可以看出，一旦指定了 16 字节对齐，即使结构中只有一个 int 类型的字段，整个结构也将占用 16 个字节：

$ gcc test.c -o test && test
Not aligned - 4
Aligned - 16

因为在 boot_gdt 的定义中， GDT_ENTRY_BOOT_CS = 2 ，所以在数组中有2个空项：

• 第一项是一个空的描述符
• 第二项在代码中没有使用

在没有 align 16 之前，整个结构占用了（8*5=40）个字节，加了 align 16 之后，结构就占用了 48 字节 

上面代码中出现的 GDT_ENTRY 是一个 宏 定义，这个宏接受 3 个参数（ 标志 ， 基地址 ， 段长度 ）来产生段描述符结构。具体分析上面数组中的代码段描述符 GDT_ENTRY_BOOT_CS 来看看这个宏是如何工作的，对于这个段，GDT_ENTRY 接受了下面 3 个参数：

• 基地址: 0
• 段长度: 0xfffff
• 标志: 0xc09b

上面这些数字表明，这个段的基地址是 0， 段长度是 0xfffff (1 MB)，而标志字段展开之后是下面的二进制数据：

1100 0000 1001 1011

这些二进制数据的具体含义如下:

• 1: (G) 这里为 1，表示段的实际长度是 0xfffff * 4kb = 4GB
• 1: (D) 表示这个段是一个32位段
• 0: (L) 这个代码段没有运行在 long mode
• 0: (AVL) Linux 没有使用
• 0000: 段长度的4个位
• 1: (P) 段已经位于内存中
• 00: (DPL) 段优先级为0
• 1: (S) 说明这个段是一个代码或者数据段
• 101: 段类型为可执行/可读
• 1: 段可访问

关于段描述符的更详细的信息你可以从上一节中获得

也可以阅读 http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html 获取全部信息

在定义了数组之后，代码将获取 GDT 的长度：

gdt.len = sizeof(boot_gdt)-1;

接下来是将 GDT 的地址放入 gdt.ptr 中：

gdt.ptr = (u32)&boot_gdt + (ds() << 4);

这里的地址计算很简单，因为还在实模式，所以就是 ds << 4 + 数组起始地址 

最后通过执行 lgdtl 指令 将 GDT 信息 写入 GDTR 寄存器 ：

asm volatile("lgdtl %0" : : "m" (gdt));

go_to_protected_mode 函数在完成 IDT, GDT 初始化，并禁止了 NMI 中断之后，将调用 protected_mode_jump 函数完成从实模式到保护模式的跳转：

protected_mode_jump(boot_params.hdr.code32_start, (u32)&boot_params + (ds() << 4));

protected_mode_jump 函数实现在 arch/x86/boot/pmjump.S，它接受下面2个参数:

1. 保护模式代码的入口， 保存在 eax 寄存器
2. boot_params 结构的地址，保存在 edx 寄存器

首先把 boot_params 地址 放入 esi 寄存器 ，然后 将 cs 寄存器 内容放入 bx 寄存器 ，接着执行 bx << 4 + 标号为2的代码的地址 ，这样一来 bx 寄存器就包含了标号为2的代码的地址。接下来代码将把 数据段索引 放入 cx 寄存器 ，将 TSS 段索引 放入 di 寄存器 ：

movw    $__BOOT_DS, %cx
movw    $__BOOT_TSS, %di

就像前面看到的 GDT_ENTRY_BOOT_CS 的值为2，每个段描述符都是 8 字节

所以 cx 寄存器的值将是 2*8 = 16，di 寄存器的值将是 4*8 =32

接下来，通过设置 CR0 寄存器 相应的位使 CPU 进入保护模式：

movl    %cr0, %edx
orb     $X86_CR0_PE, %dl
movl    %edx, %cr0

在进入保护模式之后，通过一个长跳转进入 32 位代码：

        .byte   0x66, 0xea
2:      .long   in_pm32
        .word   __BOOT_CS ;(GDT_ENTRY_BOOT_CS*8) = 16，段描述符表索引

这段代码中

• 0x66 操作符前缀允许混合执行 16 位和 32 位代码
• 0xea : 跳转指令的操作符
• in_pm32 跳转地址偏移
• __BOOT_CS 代码段描述符索引

在执行了这个跳转命令之后，就在保护模式下执行代码了：

.code32
.section ".text32","ax"

保护模式代码的第一步就是重置所有的段寄存器（除了 CS 寄存器）:

GLOBAL(in_pm32)
movl    %ecx, %ds
movl    %ecx, %es
movl    %ecx, %fs
movl    %ecx, %gs
movl    %ecx, %ss

因为在实模式代码中将 $__BOOT_DS （数据段描述符索引）放入了 cx 寄存器，所以上面的代码设置所有段寄存器（除了 CS 寄存器）指向数据段

接下来代码将所有的通用寄存器清 0 ：

xorl    %ecx, %ecx
xorl    %edx, %edx
xorl    %ebx, %ebx
xorl    %ebp, %ebp
xorl    %edi, %edi

最后使用 长跳转 跳入正在的 32 位代码（通过参数传入的地址）

jmpl    *%eax ;?jmpl cs:eax?

到这里，我们就进入了保护模式开始执行代码了，下一节将分析这段 32 位代码到底做了些什么