Linux 核心新補丁：在 s390 主機上以硬體加速執行 Arm64 虛擬機
LWN.net · 2026-05-05
IBM 與 Arm 工程師聯合向 Linux 核心郵件清單提交一組 27 個補丁，在 s390 架構上引入 KVM 加速的 Arm64 虛擬機支援。這組補丁於 2026 年 4 月解除禁運後公開，使 IBM Z 大型主機能夠在接近原生速度下執行 Arm 客體作業系統。
架構原理
實作的核心是 s390 的新指令 Start-Arm-Execution（SAE），讓 s390 的 KVM 主機扮演 Arm64 架構中的 EL2（hypervisor 層），同時讓 Arm64 客體在 EL1/EL0（OS/應用程式層）執行。這意味著 s390 硬體必須能直譯 Arm64 的特權指令，而非模擬整個 ISA。
虛擬化層的對映如下：
- s390 KVM host → Arm EL2（Hypervisor）
- Arm64 guest OS → Arm EL1（Kernel）
- Arm64 guest userspace → Arm EL0（Application）
核心改動
補丁引入了 virt/kvm/arm64/ 目錄作為跨架構共用程式碼的新家，包含客體暫存器處理、退出（exit）處理、通用暫存器重置邏輯，以及 IPA（Intermediate Physical Address）大小計算。
另一個關鍵變更是將 arm64 KVM 的 UAPI 標頭從 arch/arm64/ 遷移至 include/uapi/arch/arm64/，讓非 arm64 主機（如 s390）也能引用 Arm64 KVM 的用戶空間 API，而不需要在 include path 上做特殊處理。
影響範圍
對於同時擁有 s390 大型主機與 Arm 工作負載的企業，這項功能從根本上消除了跨架構轉換的虛擬化損耗。IBM Z 伺服器擁有大量硬體虛擬化資源（PR/SM、z/VM），若能在同一硬體上原生執行 Arm64 客體，將大幅簡化混合架構的部署拓撲。Arm 維護者對補丁反應正面，目前仍待架構合作細節確認後才會合入主線。
原始來源：LWN.net — Hardware-assisted Arm VMs for s390、Phoronix — IBM Lays Out Patches For ARM Virtualization Acceleration On IBM Z Servers
TCMalloc 違反 Restartable Sequences API 文件，核心面對 Hyrum 定律難題
LWN.net · 2026-04-30
Linux 核心社群正面對一個典型的相容性困境：Google 的 TCMalloc 記憶體配置器依賴於 restartable sequences（rseq）API 的一個未記錄行為，而核心 6.19 的變更雖然符合官方文件規格，卻意外破壞了 TCMalloc 在生產環境中的運作。
Restartable Sequences 機制
Rseq 是 Linux 核心提供的一個低延遲原語，允許使用者空間程式定義一段「可重新啟動的臨界區」（restartable critical section）。若核心在這段程式碼執行期間產生中斷（如排程切換或信號），它會自動將程式計數器重設到指定的「中止處理程序」，讓應用程式感知到中斷並重試，而不是讓臨界區在部分完成的狀態下恢復。這讓無鎖（lock-free）的每 CPU 資料結構得以實作，TCMalloc 正是利用此機制加速記憶體配置的 fast path。
違規行為
TCMalloc 對 rseq 的某個未記錄的行為模式產生了隱性依賴。核心 6.19 在技術上維持了 API 的文件規格，但改變了一個文件中未明確定義的邊界條件，足以讓 TCMalloc 的部分假設失效。
這是 Hyrum 定律（Hyrum's Law）的教科書案例：「只要 API 有足夠多的使用者，所有可觀察到的行為，無論是否在設計意圖之內，都將被某人依賴。」
核心的困境
Linux 核心有一條嚴格的不破壞回歸原則（no regressions policy），即便被破壞的行為從未被文件化，只要它在生產環境中被廣泛依賴，核心社群通常仍會視其為需要修正的回歸。目前討論的方向包括：在核心中保留舊行為的相容模式、或更新 rseq 文件明確規範這個邊界條件，並推動 TCMalloc 修改其依賴。兩種方向各有取捨，討論仍在進行中。
原始來源：LWN.net — Restartable sequences, TCMalloc, and Hyrum's Law
C++ 原子操作的記憶體順序：從 sequential consistency 到 acquire/release 的效能增益
isocpp.org · 2026-05-05
Christopher Fretz 在 CppCon 2025 以環形緩衝區（ring buffer）作為實例，系統性地展示了弱記憶體順序（weaker memory orderings）在 C++ 原子操作中的效能潛力，並說明 C++ 記憶體模型如何映射到 x86 與 Arm 兩種不同的硬體一致性模型。
記憶體順序的層次
C++ 的 std::atomic 提供六個記憶體順序選項，由強至弱：
memory_order_seq_cst：完全序列一致性，是預設值，代價最高memory_order_acq_rel/memory_order_acquire/memory_order_release：acquire-release 語意，建立局部同步關係memory_order_consume：資料依賴順序（實作困難，多數編譯器升為 acquire）memory_order_relaxed：僅保證操作的原子性，不提供順序保證
x86 對比 Arm 的硬體差異
x86 是強序模型（TSO，Total Store Order）架構。在 x86 上，普通的 load/store 指令天然具備 acquire/release 語意，因此 seq_cst 與 acq_rel 的實際指令差距僅在 store fence（MFENCE）是否插入。這意味著在 x86 上從 seq_cst 降到 acq_rel 的收益相對有限。
Arm 是弱序模型，硬體允許大量記憶體操作重排。即使是 acquire load，Arm 也需要對應的 LDAR（Load-Acquire Register）指令；release store 需要 STLR（Store-Release Register）。seq_cst 則需要額外的 full barrier，成本更高。因此在 Arm 上，正確選用弱序往往帶來更顯著的效能增益。
環形緩衝區實例
在一個 SPSC（Single-Producer Single-Consumer）環形緩衝區中，生產者只需要對 head 執行 release store，消費者只需要對 head 執行 acquire load，兩者之間不需要 seq_cst。實際量測顯示，在 Arm 架構的高頻路徑上，這項調整可帶來可量化的延遲降低。
原始來源：isocpp.org — CppCon 2025: Beyond Sequential Consistency