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 層

代價不是零：

為了避免 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 開始）的實測：

為什麼平均退化這麼小？ 因為 page walker 自己也有 cache：
– x86 叫 paging structure cache
– ARM 叫 intermediate translation cache

上層的 PGD/PUD entry 幾乎都會 hit，所以實際只多 0–1 次記憶體存取。

ARM D128 的情況可能比 x86 LA57 略糟，原因有兩個：

1. Descriptor 從 8 bytes → 16 bytes，walker 一次 cache line 帶回的 entries 數量減半（8→4），prefetch 效率變差。
2. 每層只解析 8 bits 而不是 9 bits，translation cache 的 locality 稍有不同。

但 ARM 通常 TLB / walker cache 設計比 x86 還積極，會抵銷一些。整體推估：平均退化 < 1%，最壞 case workload 3–5%。

五、ARM 位址擴展演進史

D128 不是憑空出現，是一條延續路線：

六、為什麼 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 Preparing The Linux Kernel For 128-bit Page Table Entries “FEAT_D128” — Phoronix

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

The post ARM 為 Linux 準備 128-bit Page Table Entries：FEAT_D128 解讀 appeared first on richliu's blog.