Apple Silicon上でWindowsゲームを動作させる際、最大の性能ボトルネックはもはやCPU命令のバイナリ変換ではありません。真の技術的障壁となっていたのは、Linuxカーネルがシステム全体でメモリページサイズを一律に固定している設計でした。2026年11月7日、Asahi LinuxチームはLinux 7.3の進捗レポートを公開。開発陣はAndroid向けに開発された「P3S」パッチを活用し、x86ゲームを仮想マシンの介在なしに直接動作させることに成功しました。
3層のオーバーヘッドが性能を20%損耗、4Kメモリページの制約
これまでAsahi Linux上でPCゲームをプレイするには、3つの異なる実行レイヤーを重ねる必要がありました。最下層のFEXがx86命令をarm64命令へ動的に変換し、中間層のWINEがWindows APIの呼び出しを肩代わりします。そして最上層のmuvmが軽量な仮想マシン（VM）を立ち上げ、レガシーなプログラムに対して4 KiBメモリページ環境を模擬していました。
muvmを設計した当初の狙いは、DRM Native Contextを活用してネイティブに近いGPUスループットを引き出すことでした。しかし実測テストはその目論見を裏切り、仮想化レイヤーによって約20%もの性能低下が生じることが判明したのです。多層エミュレーションに仮想マシンのオーバーヘッドが重なった結果、ハードウェアが本来持つグラフィック性能の5分の1が食い潰されていました。
フレームレートの低下だけにとどまらず、VMアーキテクチャは周辺環境にも多くの問題を引き起こしました。muvmはWaylandデスクトッププロトコルと円滑に連携できず、ウィンドウ管理やクリップボードの同期が頻繁に応答停止に陥りました。さらに仮想化ファイルシステムのI/Oスループットが大幅に低下し、ゲームパッドなど外部デバイスの入力マッピングも不安定になりがちでした。
macOSは柔軟にプロセス単位で対応、全システム一律ページに縛られるLinux
古いゲームが4 KiBメモリページに依存している背景には、x86アーキテクチャの長い歴史があります。過去のWindowsゲームや32ビットアプリケーションは、OSのページサイズが4 KiB固定であることを前提に設計されていました。多くのメモリアロケータが「4096バイト」をバイナリ内に直接ハードコードしており、より大きなページサイズの環境で起動すると、メモリのアドレス境界違反を起こしてクラッシュしてしまいます。
Apple Siliconはハードウェア標準で16 KiBページを採用しています。macOSはXNUカーネルの柔軟な仮想メモリ設計のおかげで、ユーザー空間のプロセスごとに任意のマッピング粒度を許可しています。Rosettaがx86ゲームを立ち上げる際、カーネルはその子プロセス専用に4 KiBアドレス空間を割り当てるため、システム全体を巻き込む妥協は一切不要です。
一方のLinuxカーネルは、ここで根本的なアーキテクチャの制約に直面しました。従来のLinuxは、システム内のすべてのプロセスが同一のメモリページサイズを共有することを要求します。Asahiチームは昨年FEX内部で4 KiB環境を擬似的に再現する試みも行いましたが、コードの保守性と変換の正確性を担保するため、これらの一時的なハックは最終的に削除されていました。
ARM64のレジスタ操作だけで完結：プロセスごとにページサイズを切り替え
この膠着状態を打破する契機は、モバイルエコシステムからもたらされました。現在Androidでは、4 KiBページから16 KiBページへの移行が進められています。Google Playは新規アプリに対して16 KiB対応を義務付け始めており、メンテナンスが放置された大量のレガシーアプリが起動不能に陥るリスクに直面していました。そこでGoogleのエンジニアたちは、16 KiBカーネル上で4 KiBプロセスを互換動作させるための汎用的な解決策を模索していたのです。
Linux Plumbers Conferenceにおいて、Googleのエンジニア陣は「P3S（Per Process Page Size）」と呼ばれる機構を発表しました。ARM64アーキテクチャにおけるページテーブルの粒度は、変換制御レジスタ（TCR_EL1）内の特定ビットによって制御されています。つまりハードウェア自体は、アドレス変換の粒度を動的に切り替える機能を最初から備えていたのです。
P3Sパッチは、カーネル内でプロセスごとのページテーブル粒度を追跡します。スケジューラがコンテキストスイッチを実行する際、システムは該当する設定をTCRレジスタへ書き込みます。この単一レジスタ書き込みはネイティブプロセスにとってはほぼノーオペレーション（no-op）に等しく、CPUオーバーヘッドは実質ゼロです。 このハードウェアレベルの高速切り替えにより、仮想マシンを維持する必要性そのものが消滅しました。
4つのレガシーゲームがVM脱却、フレームレートは144 FPS超を記録
AsahiチームはこのP3Sパッチを自身のLinux 7.3カーネルブランチに移植。象徴的なレガシーゲーム数本を用いて、仮想マシンを通さないネイティブ動作の実測を行いました。2004年発売の『Star Wars: Battlefront』はWineD3D経由で安定して起動し、過去に見られたメモリアドレッシングのエラーを起こすことなく、正常なグラフィックを描画しました。
図：『Star Wars: Battlefront』（2004）をmuvm外、WineD3D経由で実行した様子。出典：Asahi Linux公式進捗レポート
より描画負荷の高い2014年作『Wolfenstein: The New Order』では、さらに驚異的なパフォーマンス改善が確認されました。M2 Maxを搭載したMac Studioにおいて、フレームレートは難なく144 FPSを突破。仮想マシンを外すだけで20%の描画損失を取り戻し、ARM64のトランスレーション層が高リフレッシュレートのゲーミングに十分耐えうることが証明されました。
図：『Wolfenstein: The New Order』（2014）をmuvm外で実行、M2 Max Mac Studioで144+ FPSを達成。出典：Asahi Linux公式進捗レポート
さらにチームは、互換性が極めて壊れやすいことで知られる2008年の『Grand Theft Auto IV』も検証しました。この32ビット作品は本物のWindows実機ですらコミュニティパッチなしには起動が難しいタイトルですが、DXVK経由でVulkanに変換することで、muvm脱却後に驚くほどの動作改善を見せました。同様にテストされた『Fallout: New Vegas』も、仮想マシン特有のカクつきから解放されました。
図：『Grand Theft Auto IV』（2008）をmuvm外、DXVK経由で実行。最難関ケースとして意図的に選ばれた32ビットのレガシータイトル。出典：Asahi Linux公式進捗レポート
仮想マシンの撤廃は、フレームレート向上だけでなくグラフィックドライバのデバッグ負担も劇的に軽減しました。これまでは描画不良の調査にあたってホスト側とゲスト側の二重のドライバスタックを跨ぐ必要がありましたが、描画命令がネイティブドライバへ直接流れるようになったことで、GPU障害の切り分け工数は大幅に短縮されました。
カーネルへの一時的ハードコード：アップストリーム統合には不透明感も
著しい成果を上げたP3Sですが、現段階では実験的なエンジニアリングの域を出ていません。現在のパッチは「16 KiBホストと4 KiBプロセスの組み合わせ」に特化してハードコードされており、Google独自の要件を満たす一方で、Linuxカーネル全体の汎用的な設計思想からは乖離しています。特定サイズを固定前提としたコードをカーネルのメモリ管理中核へマージすることは、アップストリームのメンテナ陣から極めて厳しい精査を受けることになります。
ユーザー空間側にも課題が残っています。P3Sはバイナリヘッダのセクション配置に基づいて動作を判定しますが、最新のarm64バイナリは幅広い互換性のために64 KiB境界でアライメントされています。そのため子プロセスに4 KiBページを継承させるには、P3Sを強制的に有効化するシム（shim）ツールの併用が不可欠です。
アップストリームでの合流見通しが不確定な現状を踏まえ、Asahiチームは慎重な姿勢を崩していません。Googleがアップストリームへの統合方針を明確にするまでは、下流のディストリビューションにおいてこの機能をデフォルト有効化しない方針を明言しています。基盤となる設計がメインラインカーネルに受け入れられるのを確認してから、本格的な展開を検討する構えです。
なお今回の進捗レポートでは、他のハードウェア対応も多数報告されています。M3シリーズチップの対応が正式に一般提供（GA）へ移行し、DCPディスプレイエンジンによるスリープ復帰やMacBookのノッチ領域活用が実現しました。Thunderbolt向けの初期パッチによってUSB3やネットワーク接続がサポートされ、Fedora Asahi Remixも上流のFedora Linux 45と同日のリリースを達成しています。
ARM64上でWindowsゲームを動かすための技術的挑戦は、ユーザー空間でのエミュレーションからカーネル基盤の改修へとフェーズを移しました。FEXがバイナリトランスレーションの高効率を実証した今、残る障壁はOSのメモリ管理という根本的な土台にあります。P3Sがわずかなレジスタ操作で仮想マシンを置き換え、2割の性能損失を取り払ったように、カーネルレベルのページサイズ制約が解消されたとき、アーキテクチャの境界を越えたゲーム体験は真の解放を迎えることになるでしょう。
参考リンク：
- Asahi Linux公式進捗レポート（James Calligeros）
- Linux Plumbers Conference 2026 発表（Kalesh Singh, Frederick Mayle）
