最后的思考题：因为不管是实模式还是保护模式或者长模式，物理内存 0～0x400000000的实体空间是被系统的启动类型文件占用，这里不止包括内核相关的，还有BIOS中断表等等前面课程讲过的硬软件系统必须要的文件，开机就占用，关机谁也占用不了，首先给这段物理地址就固定下来。这是必要的。 而操作系统运行在非实模式下虚拟地址空间之后，如果不建立线性映射表，那对这块物理地址时不安全的，就如同实模式切换到保护模式为什么增加了各种检查和权限一个道理，也需要虚拟地址与物理地址有一个线性和固定的映射表，保护此段物理内存上的的文件，告知操作系统在分配内存的时候避开雷区。就如同隔着墙货架上抓东西，你可以抓货架上的任何东西，但要是抓到货架的框子，使劲一抓，可以想象到什么后果。 另外0xFFFF800000000000～0xFFFF800400000000的地址数值时可以变的，比如改成0xFFFF800400000000～0xFFFF800800000000,还可以改成其他，只要按照这里的规则和做好映射关系就可以，当然选择0xFFFF800000000000～0xFFFF800400000000对应0x0~0x400000000更符合人的阅读习惯。

老师好，请问我下面的理解对吗？ 1. 在 init_kvirmemadrs 函数中，初始化完 initmmadrsdsc 及相应的 userspace 虚拟内存地址区间后；调用了 hal_mmu_init 方法 2. 在 hal_mmu_init 方法中复制了在内核初始化时设置的顶级页目录到 mmu->mud_tdirearr，并把顶级页目录的第 0 项清空（我理解此处是为了清除原来该处映射到内核空间的项，改为未映射，这样访问用户空间的虚拟地址时候会触发 page fault，再分配实际的物理页并映射） 3. 在 hal_mmu_init 执行完后，紧接着执行了 hal_mmu_load 函数，该函数会把 mmu->mud_tdirearr 转换为物理地址设置到 cr3；该步骤执行完后，访问 0～0x400000000 的地址会触发 pagefault 4. 在执行完 init_kvirmemadrs 后，cosmos 代码还有许多访问内核全局变量（如 osdevtable 等）代码，这些变化是定义在内核文件的 .data 段中的，是不是因为内核文件链接脚本用了如下定义 .data ALIGN(4) : AT(ADDR(.data)-VIRTUAL_ADDRESS) { *(.data) *(.bss) }，所以可以让这些内核全局变量的加载到物理地址 0～0x400000000 中，但是代码中直接访问这些内核全局变量实际上用的是 0xffff800000000000～0xffff800400000000 中的虚拟地址，这样才会在顶级页目录的第 0 项被清空后访问内核全局变量不会造成 page fault