Linux内核启动入口CR0的PE/PG标志已置位原因及入口点咨询

你的两个推测均部分成立，具体原因拆解如下：

• 首先GRUB 2.04作为符合Multiboot2规范的引导程序，在跳转执行x86-64架构Linux内核前，已经自主完成了CPU模式切换流程：不仅会置位CR0寄存器的PE位进入保护模式，还会完成长模式激活、置位CR0的PG位启用分页，这是规范明确要求的引导加载器责任。64位内核入口被调用时，CPU本身就已经运行在64位长模式、分页开启的状态下，不会处于实模式。
• 其次你设置断点的secondary_startup_64确实不是GRUB进入内核的首个执行点。GRUB跳转至64位Linux内核的真实入口是同文件arch/x86/kernel/head_64.S内的startup_64标号，代码位置远早于secondary_startup_64。

观测到CR0标志位与预期不符的直接原因 #

你断点命中的位置已经是内核早期初始化执行了一段逻辑后的位置：

1. 从startup_64入口开始，内核就运行在GRUB预先配置好的长模式分页环境中，CR0的PE、PG位本来就是置位状态
2. startup_64到secondary_startup_64之间的代码主要完成内核自有页表构建、早期栈初始化、CPU基础校验等工作，你断下的位置刚好是call verify_cpu的调用点，这段流程不会关闭保护模式和分页机制，自然读不到PE、PG为0的状态。

你当前断点位置的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 ]

注意：如果你的目标是观测实模式切换到保护模式、分页开启的底层流程，不要在64位内核代码段打断点——这部分操作全是GRUB在跳转内核前做完的，你需要调试GRUB本身的执行流才能看到。默认的64位Linux引导流程里，内核拿到CPU控制权的时候早就退出实模式了。

内容的提问来源于stack exchange，提问作者Some Name