Linux

KVM ARM64新機能ゼロ。AIパッチの代償

情報の灯台

2026年6月25日 06:3200

Linux 7.2のマージウィンドウに投入されたKVMの変更一覧には、奇妙な空白がある。Intel向けもAMD向けもs390もRISC-Vも新機能を載せているのに、ARM64だけが「新機能なし」で終わった。

2026年6月18日、KVMメンテナーのパオロ・ボンジーニ（Paolo Bonzini）氏がリーナス・トーバルズ氏へプルリクエストを送った。そこにはKVM/arm64メンテナーのマルク・ザンジエ（Marc Zyngier）氏のコメントが引用されている。今回は純粋に修正だけだと前置きし、AI生成の修正パッチが大量に流れ込んだせいで新機能のレビューに手が回らなかったと説明している。

修正に埋もれたマージウィンドウ

KVMに限った話ではない。ARM64アーキテクチャ全体のメンテナーであるウィル・ディーコン（Will Deacon）氏は自身のプルリクエストの冒頭で、AIツールの台頭が機能開発のペースを落としたと認め、Sashiko（LLMベースのコードレビューシステム）による追加のレビューラウンドもあって、いくつかの機能が次のサイクルに先送りになったと書いている。

KVM ARM64でザンジエ氏が挙げた今回の内容は、すべて修正とクリーンアップだ。7.1で導入されたvGIC-v5のPPIサポートのコード整理、ネスト仮想化環境でのMMU処理の修正、pKVM（保護型ハイパーバイザ）のページ寄贈処理に潜んでいたエッジケースの修正、そしてレイジーvGIC初期化がプリエンプション禁止区間でスリープを引き起こしていた問題の修正。最後の問題は当初の想定よりはるかに広範に波及し、大規模な書き直しになったという。

新しい機能は、一つもない。

これは偶然の凪ではない。7.0のリリース時にトーバルズ氏自身がAIツールの使用によるコーナーケースの発見が増えていることに触れ、しばらくはこれが「ニューノーマル」かもしれないと述べていた。7.2では、その予測がKVM ARM64でもっとも鮮明な形で現実になった。

Sashikoという両刃の存在

レビュー負荷を押し上げている要因のひとつが、SashikoというLLMベースのパッチレビューツールだ。Googleのカーネルエンジニアであるロマン・グシュチン（Roman Gushchin）氏が2026年3月に公開し、Gemini Pro 3.1を使ってメーリングリストのパッチを自動レビューする。直近1000件のバグのうち53%を検出でき、そのすべてが人のレビュアーには見逃されていたものだと報告されている。

だがSashikoのレビュー精度が高ければ高いほど、メンテナーが対応すべき指摘も増える。2026年のLinux Storage, Filesystem, Memory Management, and BPF Summitで行われた議論では、Sashikoの出力の冗長さや既知の問題への繰り返し指摘が現場の負担になっていることが率直に語られた。

修正パッチの増加とレビューツールの高精度化は、どちらも品質向上に寄与する。だがその二つが同時にメンテナーに降り注いだとき、新機能の開発を押しのけるだけのレビュー負荷が生まれる。KVM ARM64の「新機能ゼロ」は、その構造的な帰結だ。

x86側は前進を止めていない

対照的に、x86のKVMは7.2でも大きく動いた。

今回の目玉はMBEC（Mode-Based Execute Control）とGMET（Guest Mode Execution Trap）のサポートだ。どちらもEPT/NPTのページテーブルにカーネルモードとユーザーモードで異なる実行権限を設定する機能で、WindowsのHVCI（Hypervisor-Protected Code Integrity）を高速化する。ハードウェアとしてはIntelがKaby Lake、AMDがZen 2から搭載していた。だがLinux KVMでのネスト仮想化を含めた完全なサポートは、7.2が初めてになる。HVCIを有効にしたWindowsゲストではVM Exitが 最大24分の1 に減ると報告されており、Linux上でWindowsを仮想化するシナリオで体感できるレベルの改善になる。

もうひとつの大きな動きが、APX（Advanced Performance Extensions）への準備だ。Intelが提唱し、2026年5月にAMDとの共同標準化が発表されたAPXは、x86の汎用レジスタを16本から32本に倍増させる拡張命令セット。KVMでは仮想マシンのレジスタの保存・復元やVM Entry/Exit時の処理を32レジスタに対応させる必要があり、7.2ではIntelとAMDのベンダー固有コードに共通のアセンブリマクロを導入する準備作業が入った。SPEC_CTRL（投機実行制御）のハンドリングがIntel側でもアセンブリに統一され、レジスタ保存処理にはstructのオフセットをマクロで自動計算する仕組みが導入されている。

そのほか、SEV（Secure Encrypted Virtualization）関連ではデバッグ用の暗号化/復号ioctl（入出力制御インターフェース）がバグだらけだったため全面書き直しとなり、包括的なテストが追加された。TDX（Trust Domain Extensions）ではTDP MMUからS-EPTへのコードが大幅にリファクタリングされ、S-EPT固有のロジックをTDXコードに移す作業が進んでいる。

ARM以外のアーキテクチャの動き

RISC-Vでは、ダーティログのライトフォールトをMMU rwlockとアトミックなPTE更新で高速化する変更が入った。s390では2GBヒュージページのサポートとKVM_PRE_FAULT_MEMORYのサポートが追加されている。LoongArchではFPUの遅延ロード時に、要求された部分だけでなくVMがサポートするすべてのFPU状態をロードするよう変更された。

Linux 7.2 KVM アーキテクチャ別変更サマリー

Arch	Linux 7.2 KVMの主な変更
ARM64	修正のみ（新機能なし）
x86	MBEC/GMET、APX準備、SEV全面改修
RISC-V	ダーティログ高速化
s390	2GBヒュージページ、PRE_FAULT_MEMORY
LoongArch	FPU遅延ロード改善

※ ARM64 KVMはAI生成パッチのレビュー負荷により新機能が次サイクルへ先送り

どのアーキテクチャも、修正を抱えながら新機能を載せている。ARM64だけが修正のみで終わった事実は、AIパッチ問題が特定のサブシステムに不均等に集中していることを示す。

「品質のための減速」か、構造的な停滞か

ARM64のKVMが一周期分の機能開発をまるごと失ったことは、今のカーネル開発が抱えるジレンマを凝縮している。

AIが生成するパッチの品質は、改善の余地が大きい。だがパッチの品質が上がるまで待つ間にも、レビューの負荷は毎日のメーリングリストに積み上がる。Sashikoのようなレビュー補助ツールが精度を上げれば、それ自体がさらなる作業を生む。7.0でのファーストタイムコントリビューターの約50%増加というデータは、この流入が一過性でないことを示唆している。

改善か停滞かは、次の7.3サイクルでARM64 KVMに新機能が戻るかどうかで判断するしかない。今回先送りになった機能がきちんと着地するなら、7.2は品質のための戦略的な減速だった。もし7.3でも同じ光景が繰り返されるなら、それは減速ではなく、レビューリソースの構造的な不足だ。

参照元：KVM changes for Linux 7.2 — lore.kernel.org