为何ARM的LPAE模式不支持完整的48位物理地址空间？

首先明确核心结论：AArch32 LPAE限制40位地址而非支持48位，本质是架构兼容性优先、硬件设计约束与场景需求匹配共同作用的结果，并非单纯的页表格式限制。

1. 32位生态的兼容性约束 #

AArch32的核心定位是兼容原有32位软硬件生态，LPAE作为2011年左右推出的扩展，目标是在不打破既有32位代码语义的前提下，扩展物理地址空间到40位（支持最大1TB内存）。若放开48位地址：

• 大量32位软件（包括内核驱动、用户态程序）依赖32位地址的语义，比如直接通过位操作处理地址、假设地址高位为0，开启48位后会出现指针溢出、地址计算错误等未定义行为。
• 早期32位固件（如Bootloader、SMMU配置程序）完全基于32位地址设计，无法处理48位地址的初始化与映射，会导致系统启动失败。

ARM架构的向后兼容性承诺是其核心竞争力之一，因此不会为了扩展地址空间而破坏既有生态的稳定性。

2. 硬件设计的固有约束 #

虽然LPAE的64位表项物理上能容纳48位地址，但AArch32模式下的硬件模块并非为48位地址设计：

• 地址生成单元（AGU）：32位模式下的AGU原生是32位位宽，要支持48位地址需要重新设计位扩展逻辑，涉及指令译码、地址计算的全链路修改。
• MMU与TLB：AArch32的MMU地址通路、TLB条目位宽都是针对32位+扩展40位优化的，要支持48位需要升级TLB的存储位宽、地址比较器的位宽，这会直接增加硅片面积。
• 总线与外设交互：32位系统的总线协议（如AXI3）通常只支持到40位地址，若要支持48位，还需要同步升级总线控制器、外设的地址接口，这对于已有硬件设计的改动成本极高。

而AArch64是全新的64位架构，从设计之初就将48位地址作为标准配置，所有硬件模块都是围绕64位地址通路构建的，不存在兼容32位硬件的包袱。

3. 场景需求的合理性匹配 #

LPAE推出时，主流32位设备（嵌入式系统、入门级服务器）的内存需求普遍在几十GB到几百GB级别，40位地址对应的1TB内存完全能满足当时的需求。没有必要为了超前的48位地址（对应256TB内存）付出额外的硬件成本，这不符合商业设计的成本-收益原则。

关于硅片用量的问题 #

如果要在AArch32 LPAE中支持48位地址，确实会显著增加硅片用量：

• 需要扩展MMU的地址翻译通路位宽，包括页表 walker的地址寄存器、TLB的条目存储位宽。
• 地址生成单元、总线接口都需要升级位宽，增加额外的逻辑门和存储单元。
• 还要添加地址合法性检查的额外逻辑，避免32位代码误操作48位地址空间。

这些改动不是简单的“启用页表的高位”，而是涉及整个内存访问链路的硬件升级，对于以低成本、低功耗为目标的32位设备来说，这种投入完全没有必要。

补充：手册中提到的Address size fault是ARM为了严格限制地址空间范围设计的保护机制，确保32位代码不会意外访问超出40位的地址空间，避免出现不可预知的行为。

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