一、原文摘要
Phoronix 於 2026 年 5 月報導，ARM 正在為 Linux kernel 提交一組 RFC patch，準備支援 FEAT_D128——也就是 128-bit page table descriptor 的新翻譯系統 VMSAv9-128，這是 ARMv9.3 之後的選用特性。
目前 patch 還在 RFC 階段，KVM、KASAN 等子系統尚未支援。但這代表 Linux 已經為 ARM 下一個世代的虛擬記憶體架構鋪路，預計會在 ARMv9.3 silicon 上市前準備好 enablement。
二、為什麼要做 D128？兩個動機
ARM 之所以要把 page table descriptor 從 64 bits 加到 128 bits，不是「順便升級」，而是兩個實際撞牆問題：
動機 1：實體位址 (PA) 撞到 52-bit 上限
現有 ARMv8/v9 的 VMSAv8-64 翻譯系統，descriptor 是 64 bits，扣掉屬性位元，能拿來放 PA 的最多 52 bits，也就是 4 PB。
聽起來很多，但對於 CXL pooled memory、AI/HPC 大模型訓練、雲端超大記憶體機台這條路線，4 PB 是可預見的天花板。要再往上走，架構上必須換成 128-bit descriptor。
動機 2：Descriptor 的屬性 bits 已經塞滿
64-bit descriptor 裡的 AttrIdx、AP、SH、AF、nG、PXN/UXN、MTE、BTI、GP……幾乎沒有空位。每次要加新功能（更細的權限、虛擬化 metadata、安全/機密運算欄位）都要從別的欄位擠空間。
128 bits 一次把容器翻倍，把累積的「想加但沒地方加」的需求解決，也替未來十年的擴展留路。
關鍵釐清：FEAT_D128 是 descriptor 變成 128 bits，不是位址空間變成 128 bits。新規格實際支援的 PA 是 56 bits（架構可再擴展），不是 2¹²⁸ bytes 那種天文數字。
三、技術代價：page walk 從 4 層變 5 層
代價不是零：
| 項目 | 64-bit descriptor | 128-bit descriptor (D128) |
|---|---|---|
| Descriptor 大小 | 8 bytes | 16 bytes |
| 4KB page 內 entry 數 | 512 個 | 256 個 |
| 每層解析 bits | 9 bits | 8 bits |
| Page walk 層數 | 4 levels | 5 levels |
| 一次 cache line (64B) 帶回 entry 數 | 8 個 | 4 個 |
為了避免 page table 體積爆炸，ARM 把每層解析的 bits 從 9 砍到 8，所以總層數從 4 變 5。代價就是 TLB miss 時的 page walk 要多走一次記憶體存取。
四、效能影響：拿 x86 LA57 類比
ARM D128 silicon 還沒出，沒有實機數字。但可以參考 x86 從 4-level paging 走到 5-level paging（LA57，Ice Lake-SP 2019 開始）的實測：
| 量測項目 | 4-level | 5-level | 變化 |
|---|---|---|---|
| Page walk per level | 20–60 cycles | 20–60 cycles | — |
| Worst-case full walk | ~4×60 = 240 cycles | ~5×60 = 300 cycles | +25% |
| 實測 page fault latency 分布 (JabPerf) | 256–511 ns | 512–1023 ns | ~2× |
| 一般 server workload (SPEC / 雲端) | baseline | < 1% 平均退化 | 幾乎沒感覺 |
| Pointer-chasing 重型 workload（圖計算、稀疏 GEMM） | baseline | 3–5% 退化 | 有感 |
為什麼平均退化這麼小？ 因為 page walker 自己也有 cache：
– x86 叫 paging structure cache
– ARM 叫 intermediate translation cache
上層的 PGD/PUD entry 幾乎都會 hit，所以實際只多 0–1 次記憶體存取。
ARM D128 的情況可能比 x86 LA57 略糟，原因有兩個：
- Descriptor 從 8 bytes → 16 bytes，walker 一次 cache line 帶回的 entries 數量減半（8→4），prefetch 效率變差。
- 每層只解析 8 bits 而不是 9 bits，translation cache 的 locality 稍有不同。
但 ARM 通常 TLB / walker cache 設計比 x86 還積極，會抵銷一些。整體推估：平均退化 < 1%，最壞 case workload 3–5%。
五、ARM 位址擴展演進史
D128 不是憑空出現，是一條延續路線：
| 特性 | 架構版本 | PA 上限 | 主要改動 |
|---|---|---|---|
| 原始 VMSAv8-64 | Armv8.0 | 48 bits (256 TB) | 4-level page walk |
| FEAT_LPA | Armv8.2 | 52 bits (4 PB) | 僅限 64KB granule |
| FEAT_LPA2 | Armv8.7 | 52 bits (4 PB) | 擴展到 4KB / 16KB granule |
| FEAT_D128 | Armv9.3 | 56 bits (64 PB), 可擴展 | 128-bit descriptor, 5-level walk |
六、為什麼 ARM 不直接學 x86 做 5-level paging 就好？
這是和 x86 路線最關鍵的差別。
x86 LA57 的做法很單純：descriptor 還是 64 bits 不變，只是再多疊一層 PML5，把 VA/PA 從 48 bits 推到 57 bits。
ARM 不能這樣做，因為瓶頸不是「層數不夠」：
– ARM 用 FEAT_LPA2 已經把 PA 推到 52 bits（在 4-level 架構內就達到了）
– 真正的瓶頸是 64-bit descriptor 的 attribute bits 已經用完
所以 ARM 必須換大的容器（descriptor 64→128 bits），不是只加層級。多出來的 64 bits 不只用來放更長的 PA，更重要的是放新功能的 metadata：擴展權限、虛擬化欄位、機密運算識別碼等等。
換句話說：
– x86 LA57 ＝ 把瓶子疊更高
– ARM D128 ＝ 換更大的瓶子
兩條路線解決的是不同的問題。
七、為什麼 KVM 還沒支援？
RFC patch 明確標註 KVM 暫不支援。原因不是難度高，而是工作量大。
ARM 虛擬化是 two-stage translation：
– Stage 1：Guest VA → Guest PA（Guest 控制）
– Stage 2：Guest PA → Host PA（Hypervisor 控制）
D128 上線後，Stage 2 的 page table 也要跟著走 D128 格式，KVM 的 page table 操作、shadow page table、IPA fault handler 全部都要改。這是另一個 patch series 的規模，所以 RFC 先把 Stage 1 (host kernel) 做出來，KVM 之後另案處理。
八、結論
FEAT_D128 不是「ARM 突發奇想做大記憶體」，而是兩個工程現實的回應：
1. 4 PB 的 PA 上限在十年內可見
2. 64-bit descriptor 的 metadata 空間用完了
代僸昢 page walk 多一層，從 x86 LA57 的實測經驗推估，平均效能退化 < 1%，最壞 case 3–5%，業界普遍可接受。
Linux 提早動作的原因，是 ARM 一貫的節奏：kernel patch 要在 silicon 出貨前準備好，等晶片到位時 distro 已能跑。所以現在看到的是「鋪路」，不是「迫切」。
ARMv9.3 silicon 預計 2027 之後上市，到時就會有實機數字驗證這些推估。
參考資料
原始新聞
ARM 官方文件
- The Armv9.3 architecture extension — Arm Developer
- Feature names in A-profile architecture — Arm Developer
- TTBR0_EL1, Translation Table Base Register 0 (EL1) — Arm Developer
效能對比與背景延伸閱讀
- 5-level vs 4-level Page Tables: Does It Matter? — JabPerf
- Intel 5-level paging — Wikipedia
- 5-level paging — LWN.net
- TLB and Pagewalk Performance in Multicore Architectures (arXiv 2002.01073)
- Victima: Drastically Increasing Address Translation Reach (arXiv 2310.04158)
- AArch64 memory and paging — Mike’s homepage
- ARM Paging — OSDev Wiki
發佈留言