CR0在Linux内核启动上包含PE/PG标志

Question

我正在使用gnu grub版本2.04 bootloader和linux内核5.19-rc2

我正在调试Linux内核初始化，并期望CPU在内核启动时应在实际模式。实际上如Intel系统编程手册中指定的，第2章：

所有Intel 64和IA-32处理器都输入实时地址模式。 加电或重置（请参阅第9章，“处理器管理和 初始化”）。然后，软件从实地启动开关 到受保护模式的模式。

因此，我在第一个Linux内核函数grub调用中设置了GDB中的断点（我相信的是 secondary_startup_64 在x86-64上），以在qemu中调试ubuntu 20.04。我期望pe pg cr0的标志将被禁用，因为在实际地址模式下没有分页，也没有受保护的模式。但这是我在gdb中得到的：

Thread 2 hit Breakpoint 1, secondary_startup_64 () at arch/x86/kernel/head_64.S:147
147             call verify_cpu
(gdb) p $cr0
$1 = [ PG AM WP NE ET MP PE ]

可以看到pg和pe flags设置的标志，这不清楚为什么。我看到2种可能性：

1. grub本身将CPU转移到受保护的模式中，并启用了分页
2. secondary_startup_64 不是grub调用的Linux内核的第一个函数，并且之前执行了内核代码。 如果是这样，从grub到Linux内核的真实切入点是什么？

Answer 1

“ 所有Intel 64和IA-32处理器都在加电或重置后输入实地模式 ”，然后固件启动（使用一个CPU），然后IT启动所有其他CPU，所有CPU都将切换到受保护的模式或较长模式（以及初始化许多内容 - 内存，MTRR，ACPI表，...）;除一个CPU外，所有CPU都重新入睡。

最终;如果固件是BIOS，则将CPU切换回真实模式并启动引导加载程序。如果固件是UEFI，它将以较长的模式离开CPU并启动启动加载程序。无论哪种方式，grub启动。

如果固件是BIOS，则grub将CPU切换为受保护的模式（然后将其从保护模式转换为实际模式，然后每次使用BIOS功能时将其切换为实际模式）；做一堆东西；算出它正在加载64位Linux内核，然后切换到长模式。如果固件是UEFI，它将一直保持长期。请注意，Grub的代码主要是32位代码；并且受保护模式和延长模式都使您可以运行32位代码；因此，GRUB的大多数代码都适用于受保护模式和长模式。

甚至后来；在固件和grub完成了大量工作之后，可能在CPU模式发生了数千次之后； grub将控制权传递到Linux。

现在... Linux有几个不同的入口点，启动加载程序使用的任何条目最适合它。偶尔会发生这种变化 - 例如，Linux的非常古老的版本内置了一个软盘启动加载器（它们稍后放弃了），而Linux的现代版本可以在其中内置一个UEFI引导加载程序。还有一个实际模式入口点和一个受保护的模式入口点（较旧）和一个64位的入口点（更新）。如果固件为BIOS，则可能只使用32位入口点，如果固件为UEFI，则使用64位入口点。

这些入口点中的大多数（不包括UEFI引导加载器入口点）用作链条 - 如果使用了32位入口点，它将设置分页和较长模式，并跳到64位入口点。

您的断点位于/附近的64位入口点；因此，无论启动加载器使用的启动加载器（32位ONE或64位）无论哪个入口点，您都开始查看64位代码。 64位代码需要较长的模式，并且长度模式需要分页；因此必须设置PG和PE。

当然，（对于64位入口点）可能会配置分页，以便所有物理地址都映射到相同的虚拟地址，因此，即使启用了分页，它实际上也没有做任何事情。内核的64位启动代码将更改配置分页的方式（将内核映射到内核空间等）。