Linux内核虚拟地址空间布局：用户空间与内核空间的分界线
大家好，我是你们的Linux内核讲师。今天我们来聊聊虚拟地址空间布局这个话题。说实话，我刚开始学内核时，被各种地址空间的概念搞得晕头转向。后来亲手调试过几次内存问题，才真正理解了这些分界线背后的设计哲学。
咱们先想一个问题：一个32位的CPU，寻址范围是4GB。这4GB空间怎么分？谁用得多？谁用得少？这就是我们今天要讲的核心——用户空间与内核空间的分界线。
一、为什么要有分界线？
说白了，分界线是为了保护。内核不能随便让用户程序访问，用户程序也不能乱闯内核的地盘。否则你写个程序就能把系统搞崩，那还得了？
我曾在项目中遇到过一个问题：一个驱动模块在内核态访问了用户空间的指针，结果系统直接panic。嗯，从那以后我写驱动时，每次访问用户空间数据都会用copy_from_user和copy_to_user，再也不敢偷懒了。
二、经典的3:1分割
在32位系统上，最常见的布局是3:1分割。什么意思？
- 用户空间：0x00000000 ~ 0xBFFFFFFF（3GB）
- 内核空间：0xC0000000 ~ 0xFFFFFFFF（1GB）
这个分界线在0xC0000000。内核代码、内核数据、模块、页表等，全挤在这1GB里。你想想看，1GB要装下整个内核、驱动、还有各种映射，是不是有点紧？
关键点：3:1分割下，内核直接映射的物理内存只有896MB（ZONE_NORMAL），剩下的128MB留给vmalloc、固定映射等。超过896MB的物理内存属于ZONE_HIGHMEM，需要临时映射才能访问。
我个人习惯把ZONE_HIGHMEM叫做"高端的烦恼"。为什么？因为访问高端内存需要先建立临时映射，用完还得释放。多了一步操作，性能自然受影响。
三、2:2分割——另一种选择
有些场景下，1GB的内核空间不够用。比如你需要映射大量IO内存，或者内核本身很大。这时候可以改成2:2分割：
- 用户空间：0x00000000 ~ 0x7FFFFFFF（2GB）
- 内核空间：0x80000000 ~ 0xFFFFFFFF（2GB）
分界线在0x80000000。内核空间翻倍了，但用户空间缩水了。这就像跷跷板，一头高了另一头就低。
注意：2:2分割不是默认选项，需要重新编译内核。而且很多用户程序假设用户空间有3GB，改成2GB后可能会出问题。我曾经帮一个客户排查过这类问题，他们的数据库在2:2分割下频繁OOM，就是因为进程地址空间不够用。
四、x86_64的布局——彻底解放
到了64位时代，地址空间不再是问题了。x86_64使用48位虚拟地址，但实际只用了低47位。为什么？因为硬件设计如此，高17位是符号扩展位。
来看看x86_64的典型布局：
| 区域 | 地址范围 | 大小 |
|---|---|---|
| 用户空间 | 0x0000000000000000 ~ 0x00007FFFFFFFFFFF | 128TB |
| 内核空间 | 0xFFFF800000000000 ~ 0xFFFFFFFFFFFFFFFF | 128TB |
| 非规范区域 | 0x0000800000000000 ~ 0xFFFF7FFFFFFFFFFF | 不可用 |
看到了吗？用户空间和内核空间各128TB，中间夹着一块巨大的非规范区域。这个非规范区域就是高17位符号扩展导致的"空洞"，访问它会触发异常。
我刚开始接触x86_64时，看到0xFFFF800000000000这个地址总觉得别扭。后来写了一个小工具打印进程的地址空间，才直观感受到：用户空间的地址最高位是0，内核空间的地址最高位是1。硬件就是靠这个来区分用户态和内核态的。
五、ARM64的布局——灵活但复杂
ARM64的布局比x86_64灵活得多。它支持多种页表粒度（4K、16K、64K）和虚拟地址位数（39位、48位、52位）。不同的配置下，布局都不一样。
以最常见的4K页、48位虚拟地址为例：
| 区域 | 地址范围 | 大小 |
|---|---|---|
| 用户空间 | 0x0000000000000000 ~ 0x0000FFFFFFFFFFFF | 256TB |
| 内核空间 | 0xFFFF000000000000 ~ 0xFFFFFFFFFFFFFFFF | 256TB |
注意看，ARM64的用户空间和内核空间各256TB，比x86_64大一倍。而且ARM64没有非规范区域，地址空间是连续的。
个人经验：ARM64的布局有个坑——内核空间起始地址不是固定的。在4K页下是0xFFFF000000000000，但在64K页下就变成了0xFFFF000000000000？不对，64K页下是0xFFFF000000000000？嗯，这里容易记混。我建议你直接看内核源码里的Documentation/arm64/memory.rst，那才是最权威的。
六、x86_64 vs ARM64：核心差异
我把两者的关键差异整理成了一张表：
| 特性 | x86_64 | ARM64 |
|---|---|---|
| 虚拟地址位数 | 48位（固定） | 39/48/52位（可配置） |
| 用户空间大小 | 128TB | 256TB（48位下） |
| 内核空间大小 | 128TB | 256TB（48位下） |
| 非规范区域 | 有（巨大空洞） | 无 |
| 内核起始地址 | 固定（0xFFFF8000...） | 随页表粒度变化 |
| 模块映射区域 | 固定位置 | 动态分配 |
为什么会这样？说白了，x86_64的设计更"死板"，一切按规范来。ARM64则更灵活，给了开发者更多选择。但灵活也意味着复杂，你写ARM64的内核代码时，必须时刻注意当前配置。
七、SVG结构图：虚拟地址空间布局对比
下面这张图展示了32位3:1分割、x86_64和ARM64的布局差异。我建议你仔细看看，尤其是分界线的位置和地址范围。
八、避坑指南
最后，分享几个我踩过的坑：
- 不要假设用户空间大小：写跨架构代码时，永远不要硬编码用户空间边界。用
TASK_SIZE宏，它会根据架构自动适配。 - 注意内核地址的符号扩展：x86_64上，如果你不小心把内核地址的低32位传给用户空间，用户程序访问时会触发段错误。因为高32位没补全。
- ARM64的模块映射：x86_64的模块映射在固定位置，但ARM64是动态分配的。写驱动时不要假设模块地址范围。
- 32位兼容模式：64位系统运行32位程序时，地址空间布局又不一样。用户空间只有3GB或4GB，分界线在
0xC0000000或0x80000000。
我曾经在调试一个ARM64服务器时，发现内核模块加载失败。查了半天，原来是模块映射区域和固定映射区域重叠了。嗯，从那以后我每次改内核配置都会仔细检查memory.rst。
好了，今天的内容就到这里。记住一句话：分界线不是随便画的，它背后是硬件设计、内核架构和性能权衡的综合结果。理解了分界线，你就理解了虚拟地址空间的灵魂。