Asahi Linux 進捗レポート: Linux 7.3

進捗レポート: Linux 7.3

さて、またこの時期がやってきました。Linux 7.3がリリースされ、ここ数ヶ月は非常に多くの出来事がありましたので、Asahi Linuxの進捗レポートを始めましょう！

アップストリーム化の継続

いつものように、アップストリーム化の作業は順調に進んでいます。低レベルのSoCブロックに対する通常のパッチに加え、今サイクルではmacaudioとavdという2つの主要なドライバーがリストに載りました。macaudioの提出準備は困難を極めました。Apple Siliconデバイスのオーディオサブシステムは非常に特殊であり、適切にサポートするためにはコアALSAの変更が数多く必要でした。Appleは、すでにアップストリームでサポートされているスピーカーおよびヘッドセットアンプの特殊なバリアントも使用しており、これらのドライバーにもかなり大幅な変更が必要でした。私たちは以前からこの作業の多くを詳細に議論してきましたが、ついにメインドライバーのレビュー提出が可能になりました。ドライバーとDevicetreeの変更は、パッチセット全体の約3100行を占めています。

AVDは全く異なる種類のものです。AVDドライバーは、私たちのダウンストリームツリーでわずか3ヶ月しか使用されていませんが、すでにリストに載っています。これは、主要なSoCコンポーネントとしては過去最短のターンアラウンドタイムであり、将来的にアップストリームファースト開発への移行がうまくいくことを示唆しています。これは素晴らしいニュースです。なぜなら、AVDドライバーと関連するDevicetreeの変更は、約13000行のコードに及ぶからです。

また、Yurekaの絶え間ない努力のおかげで、M4 ProおよびMaxデバイスだけでなく、M5デバイス用の初期Devicetreeも今サイクルに登場しました。いつものように、これらの初期Devicetreeは最小限のものであり、SoCをTTYにブートさせるのに十分なだけですが、さらなる有効化に向けた作業が進んでいます。このスペースにご注目ください！

実用的な範囲で、アップストリームファーストアプローチへの移行も開始しました。新しいデバイスに必要なTI USB-PDおよびSPMIドライバーの変更、およびThunderboltの初期サポートは、すべてアップストリームファーストで開発されました。アップストリーミングへの注力が成果を上げ始めているのを見て、私たちは非常に興奮しています！

M3が一般提供開始 (GA)

前回、AsahiインストーラーのEXPERTフラグを介してM3シリーズのマシンに対する初期サポートを発表しました。早期導入者からほとんど問題の報告がなかったことを嬉しく思います。そのため、M3サポートは現在、EXPERTフラグなしで一般提供されています！

M3サポートの改善も数多く行いました。特にDCPの有効化が挙げられます。パフォーマンスとバッテリー寿命の向上に加え、これによりM3シリーズデバイスでのスリープを有効にできるだけでなく、MacBookのノッチ周辺エリアも使用可能になります！数日中にm1n1とカーネルのアップデートにご注目ください。

混み合ったハウス (Crowded House)

前回、m1n1でのSPTM対応macOS仮想化のサポートをからかいましたが、これによりM4シリーズのマシンでのリバースエンジニアリングが可能になります。M5は新たな課題を提示します。なぜなら、M5をサポートするmacOSのバージョンはすべてExclavesの使用を要求するからです。

Exclavesは、Secure Kernelによって制御される隔離された環境で実行される小さなアプリケーションです。M5シリーズSoC以降では、macOSは画面への「カメラ使用中」インジケーターの描画などの機密性の高いタスクにこれらを使用します。XNUはSPTMを介してSecure KernelとそのExclavesと通信し、Tightbeamと呼ばれる別のIPCプロトコルを使用します。SPTMと同様に、XNUは実行中のExclavesを見つけられない場合、パニックを起こします。これらすべては、Arm自身のTrustZone機能と概念的に非常に似てきています。

一部のExclavesはコマンドラインの設定を変更することで回避できますが、常にそうとは限らないと予測しています。そのため、Svenはこのすべてをm1n1にどう組み込めるか調査を開始しました。最初の調査ラインは、SPTMとmacOSの隣にある別のVMにSecure KernelとExclaveユーザー空間を配置することです。

それがうまくいきました。そして、m1n1の下でEL1で最大3つのVMを起動できるようになりました！もしかしたら、VMwareから逃れてきた企業にm1n1を販売できるかもしれません… これにより、M4およびM5シリーズのマシンでmacOSを仮想化し、リバースエンジニアリングできるようになりました。

こんにちは、三角形！

M3サポートは現在、M1およびM2との機能パリティでほぼ完了していますが、明白な例外はGPUです。AppleのGPUチームはtick-tockモデルに従っているようで、M3のGPUはM1およびM2 SoCで見られるモデルから非常に大きく逸脱しました。M3 GPUは新しい貢献者グループによってリバースエンジニアリングされていることをかなり前に言及しましたが、それ以降あまり語られていませんでした。

今年のXDCで、Alyssa Millburn、Anna Maniscalco、およびTellowKrinkleは、M3 GPUのリバースエンジニアリングの進捗について講演を行いました。作業は進み、m1n1がGPUを正常に初期化し、チームが三角形を描画できるようになりました！これらの進捗レポートの「Think Different」セクションのファンは、この講演を興味深く感じるでしょう。Appleは再び、アップストリームMesaに統合するためにかなりのエンジニアリング作業を必要とする、いくつかの…興味深い選択をしました。詳細に興味がある場合は、ぜひご覧ください。

この作業を可能にしてくれたすべての人に心から感謝します。さらなる進歩が近づいていますので、ご期待ください。

お待たせしました、ね？

2024年1月の初めに、私たちは間違いを犯し、年内にThunderboltサポートを約束しました。それはすぐに繰り返すことのない間違いです。私たちは2年間、Thunderboltについてほとんど何も言っていませんでしたが、それはどこにあるのかという疑問を投げかけます。

メーリングリストにあります！

Thunderboltは元々AppleとIntelによって開発され、Intelが必要なハードウェアの設計と製造を担当していました。Intelがこれらのコントローラーを比較的安価で誰でも入手できるようにしていたため、他の誰も独自の設計をしませんでした。標準がUSB-IFに移管された時期とほぼ同時期に、AMDのような企業が独自のコントローラーを開発することを決定したのはごく最近のことです。Appleも例外ではありません。

ほとんどのシリコンIPのインソーシングを推進する一環として、Appleは他のほとんどの企業よりも先に独自のThunderboltコントローラーを設計することを選択しました。誰も驚かせませんでしたが、そのコントローラーは当然ながらRTKitを実行するCortex-M3と、カスタムのThunderbolt/USB4ルーターが組み合わされたものです。すべてのApple Silicon MacのThunderbolt対応USB-Cポートごとに、これらのうちの1つがあります。

Intelは市場に出回っている他のすべてのThunderboltコントローラーを供給しているため、LinuxカーネルのThunderboltサブシステムは、事実上、実行中のマシンのハードウェアトポロジー、ハードウェア機能、および特定のレジスタや共有メモリ領域へのアクセスパターンに関する多くの仮定に基づいて設計されています。Appleのコントローラーは、これらの仮定の多くを破っています。素晴らしいことです。

Thunderboltコントローラーは、PMGRとも奇妙に結合されています。各コントローラーのリセットラインは、PMGRのMMIO範囲の中央にあるビットセットを設定およびクリアすることによってアサートまたはデアサートされます。他のハードウェアブロックはこのようには機能せず、PMGRへのこれらのランダムに見える書き込みが単なるノイズではないことを理解するのに時間がかかりました。

幸いなことに、Svenはこのナンセンスに対処する任務を遂行しました。予想より少し時間がかかっただけです！Thunderboltを有効にするためのパッチセットは最初にアップストリームに送信されました（私たちにとってまたしても大きな勝利です！）。しかし、私たちはそれをダウンストリームカーネルにも取り込み、現在ユーザーに提供しています！

ただし、注意点があります。現在、USB3、XDomain、およびThunderboltネットワーキングのみがサポートされています。USBデバイスを接続したり、2台のThunderboltコンピューターを接続してpingし合ったりすることはできますが、それだけです。ほとんどのThunderboltドックに必要なPCIeおよびDisplayPortトンネリングはサポートされていません。まだです。このスペースにご注目ください。

他のすべての信じられないほどの仕事の合間に、ほぼ5年間この報われない仕事に粘り強く取り組んでくれたSvenに、計り知れないほどの感謝を捧げます。

「聖杯だ、ジョーンズ博士」

Asahi Linuxで市販のPCゲームをプレイするのは、控えめに言っても骨が折れます。これを有効にするために必要なソフトウェアスタックは非常に複雑です。x86/amd64バイナリをarm64に翻訳し、低遅延ゲームプレイに十分な速度で実行する必要があります。ほとんどの場合、Windows APIも処理する必要があります。さらに、ほとんどすべてのゲームは、4 KiBのメモリページサイズを前提として、特定のパフォーマンス最適化を有効にしています。過去数年間で、これらの問題のほとんどは解決されました。

• FEXは飛躍的に改善しました。バイナリ翻訳のパフォーマンスと信頼性は、ほとんどの場合、もはや考慮事項ではありません。
• WINEも現在では素晴らしいです。ARM64ECのサポートは成熟しており信頼性が高いため、FEXはゲームバイナリ全体ではなく、WINEのWindows API実装全体を翻訳するだけで済みます。
• muvmにより、x86/amd64アプリケーションに4 KiBのメモリページサイズを提示するために、DRM Native Contextを持つ薄いVMを起動できます。

muvmが最初に開発されたとき、DRM Native ContextがVM内からほぼネイティブなGPUパフォーマンスを可能にするという仮定がありました。残念ながら、この仮定は当てはまりませんでした。muvmのパフォーマンスペナルティは、ワークロードによって約20%と、いくつかの理由でかなり大きいです。VMの使用に伴う固有の制限に対処するためのエンジニアリングも問題を引き起こします。muvmはWaylandを使用できず、I/Oパフォーマンスが遅く、特定の種類の入力デバイスで苦労します。

これはmacOSが私たちを完全に凌駕している分野の1つです。FEXとRosettaのパフォーマンスギャップは縮まりましたが、XNUはユーザー空間プロセスが任意のページ粒度で自身をマップすることを許可するため、Rosettaが行う必要があるのは、子プロセスに4 KiBページをマップするようにXNUに指示することだけです。Linuxにはこの柔軟性がありません。すべてのページは、カーネルと同じ粒度でマップされなければなりません。昨年、muvmの外でWindowsゲームが動作することをからかいましたが、これは保守性と翻訳の正確性のために削除されたFEX内の厄介なハックに依存していました。残念。それでも、互換性はまちまちで、多くの（主に古い）ソフトウェアはまだ動作を拒否していました。さらに残念。

Androidは現在、さまざまな理由で4 KiBページから16 KiBページへの移行を進めています。Google Playは現在、アプリが16 KiBシステム用にビルドされることを要求しており、そのようなシステムで正常にテストされないアプリケーションの更新は、Playストアでの公開が承認されません。しかし、もはや更新されないアプリケーションについてはどうでしょうか？サイドロードされたエンタープライズのスロップアプリについてはどうでしょうか？

GoogleのエンジニアであるKalesh SinghとFrederick Mayleは、今年Linux Plumbers Conferenceでまさにこのことについて非常に興味深い講演を行いました。彼らの解決策はシンプルです。ユーザー空間が4 KiBページをマップできるようにLinuxを修正するだけです。

彼らのAndroidカーネルへの追加はP3S、つまりPer Process Page Sizeと呼ばれます。ARM64システムでは、ページテーブルの粒度はTranslation Control Registers（TCR）の設定ビットによって制御されます。P3Sは、各プロセスのページテーブルの粒度を追跡し、異なるページテーブルサイズを持つプロセスに切り替えるたびに、適切なビットをTCRに書き込むことで機能します。これは単一のレジスタ書き込みであり、「ネイティブ」ページサイズプロセスにとってはノープであるため、パフォーマンスペナルティは実質的にゼロです！

この取り組みは主にAndroidを対象としていますが、パッチセットはメインラインLinuxの上にきれいにリベースされます。これをAsahiツリーにリベースし（そしていくつかのバグを修正）たらどうなるでしょうか？結果は次のとおりです。

［画像: muvmの外で、WineD3Dを使用して実行されているStar Wars Battlefront (2004)］

Star Wars Battlefront (2004) がmuvmの外で、WineD3Dを使用して実行されています。

よしよし、Battlefrontは22年前の非常にシンプルなDirect3D 9.0ゲームです。それほど印象的なデモではありませんよね？では、これについてはどうでしょうか。

［画像: muvmの外で実行されているWolfenstein: The New Order (2014)］

Wolfenstein: The New Order (2014) がmuvmの外で実行されています。

Wolfenstein: The New Orderは、これまでリリースされた中で最も最適化されたネイティブVulkanタイトルの一つであり、64ビットであるためWINEのARM64ECパスを利用してFEXが行う作業量を大幅に削減します。これもまた、技術的な難易度で判断するなら、それほど印象的なデモではありません。

何か別のものを見つけましょう。何か…もっと悪いもの。FEXとWINEがより一生懸命働くように、32ビットの何か。DXVKも活用する何か。あまりにもコミカルにバグがあり、最適化が悪く、実際のWindowsマシンでもまともに動作せず、コミュニティパッチとコマンドラインスイッチに依存して、最新のコンピューターでようやく起動するようなもの。

［画像: muvmの外で、DXVKを使用して実行されているGrand Theft Auto IV (2008)］

Grand Theft Auto IV (2008) がmuvmの外で、DXVKを使用して実行されています。

それはより良いものになりました！しかし、さらに悪くすることもできます。Bethesdaのゲームさえ実行できます！

［画像: muvmの外で、DXVKを使用して実行されているFallout: New Vegas (2010)］

Fallout: New Vegas (2010) がmuvmの外で、DXVKを使用して実行されています。

パフォーマンスは当然ながらまだまちまちです。BattlefrontとWolfensteinはどちらも実質的に問題なく動作し、後者はM2 Max Mac Studioで144 FPS以上を記録します。一方、GTA IVは…それほど素晴らしいものではありません。パフォーマンスはmuvmを使用するよりも大幅に向上しており、一般的にVMの使用を排除することで、いくつかのクラスのバグが解消されるはずです。このアプローチにより、GPUドライバーのデバッグもはるかに容易になるはずです。

いつものように、注意点があり、残念ながらそれは大きなものです。現在のソリューションは、16 KiBホストとそれらのホスト上の4 KiBプロセス用にハードコードされています。これは明らかにGoogleの商用要件を満たしていますが、カーネルのコアメモリ管理コードにページサイズ固有の応急処置を追加することは、アップストリームには適切ではありません。Googleがこのアプローチを一般化してアップストリームすることを意図しているのか、それともこれがAndroid専用のパッチセットのままであるのかは不明です。そのため、このレベルの不確実性がある場合に人々がそれに依存するようになるため、これをダウンストリームツリーに出荷したくありません。

また、ユーザー空間の統合も必要です。P3Sは、セクションのページアラインメントのバイナリメタデータをチェックすることで機能します。これはGoogleのユースケースには適しています。P3Sは4 KiBページにアラインされたアプリケーションのフォールバックメカニズムを意図しているためです。しかし、現代のarm64バイナリは64 KiBにアラインされています。これは、すべてのネイティブページサイズのシステムとの互換性を保証するためです。したがって、P3Sを強制するためのシムが必要です。シムはP3Sをトリガーし、子プロセスは4 KiBページサイズを継承します。Googleがこのパッチセットで何をしたいのか確実性が得られるまで、これを実装する労力を費やす価値はありません。

Googleにいくつかの質問を問い合わせており、まもなくさらに詳しい情報をお伝えできることを願っています。

マイク、しかしより速く

MacBookに搭載されているマイクアレイ用のカスタムビームフォーマーはRustで書かれています。Rustの科学計算エコシステムはC++ほど成熟していませんが、これは問題です。ビームフォーミングはリアルタイムFFTと、オーディオサンプルで満たされたバッファに対して非常に重い行列演算を必要とするからです。成熟した科学計算ライブラリには、ターゲットISAに紐付けられたイントリンジクスをしばしば使用する、手作業で最適化されたコードがあります。しかし、私たちはこれを行っておらず、パフォーマンス目標を達成するために、コンパイラがコードを可能な限り自動ベクトル化することに依存していました。

FFTベースの解析変換を排除し、無限インパルス応答（IIR）フィルターに基づく実装に置き換えたときに、これはうまくいかなくなりました。これはより高速になるはずですが、コンパイラは新しい実装を自動ベクトル化することに失敗していました。Linkmauveが親切に手を差し伸べ、arm64とamd64の両方にSIMD最適化コードを追加しました。Frédéric Bourによるその他のパフォーマンス最適化と相まって、これによりTriforceはCPU時間をより少なく使用しながら、ほぼ2倍高速になりました！

最新の状態を維持

Fedora Linux 45は11月3日にリリースされ、私たちはFedora Asahi Remixを同日にリリースしました。これは、アップストリームと同じ日にFedora Asahi Remixの新バージョンをリリースできた初めての機会です！

歴史から学ぶ

私たちは自分たちの仕事に大きな誇りを持っており、常にすべての開発をオープンに行ってきました。私たちはユーザー、フォロワー、そして財政的スポンサーと、人間的に可能な限り透明性を持ってコミュニケーションをとっています。私たちの財政は公開されており、開発ブランチは公開されており、進捗状況は定期的に率直に公開されています。私たちのIRCチャンネルとMatrixルームは、Asahi LinuxやApple Siliconでのハッキングに少しでも関心のある人なら誰でも参加できる安全な空間です。

私たちは、自由およびオープンソースソフトウェアを、単なる手段としてではなく、それ自体を目的として、固く信じているため、これらすべてを行っています。現代のデジタル世界は、フリーソフトウェア運動のおかげで可能になっており、フリーソフトウェアエコシステムを保護し、その基盤となる理想を維持するために、私たちができる限りのことをすることが、これまで以上に重要になっています。

WINEが元々MITライセンスで提供されていたことを知って驚く人もいるかもしれません。90年代と2000年代は、フリーソフトウェアエコシステムにおいて非常に異なる時代であり、許可ライセンスのプロジェクトは、技術企業によって略奪および悪用される無料の不動産と見なされていました。WINEも例外ではありませんでした。多くの収益化されたプロプライエタリなWINEのフォークが、さまざまな悪意のあるアクターによってマーケティングされ、販売されました。WINE開発チームは、これらのプロプライエタリなフォークは、存在する権利は完全にあったものの、最終的にはエコシステムにあまりにも多くの断片化を引き起こし、WINE自体が実行不可能になるのではないかとますます懸念するようになりました。2002年、WINEは、さらなるプロプライエタリなフォークの作成を防ぎ、直接のアップストリーム貢献を奨励するために、LGPLの下でライセンスが変更されました。

Asahi Linuxが最初に開始されたとき、それはApple Siliconプラットフォームのための自由なソフトウェアエコシステムを開発することを意図していました。BSDやその他の自由なソフトウェアオペレーティングシステムで私たちの友人たちの参加を促進し奨励するために、私たちは可能な限り多くのコードを許可ライセンスであるMITライセンスの下でライセンス供与するよう努めました。

残念ながら、これはもはや実行可能ではありません。90年代と2000年代の悪意のある慣行が、今回は主にフロンティアAIラボの高品質なトレーニングデータへの飽くなき食欲と、フリーソフトウェアコミュニティに対する過激な敵意によって推進され、再びその醜い頭をもたげてきました。

しばらく前に、私たちは、私たちの許可ライセンスを悪用して私たちの仕事を乗っ取り、Apple Silicon上のLinuxを積極的に収益化することを直接の目的とした、複数の試みについて知らされました。いくつかの極端なケースでは、開発中の機能コードが私たちの個人的なフォークから直接引き出され、帰属表示なしで公開されたり、LLM支援で怠惰に書き直されてその起源が隠蔽されたりしていました。MITライセンスはこれを明示的に許可しており、悪意のあるアクターから保護するための除外規定はありません。

そのため、私たちはすべてのリポジトリをGNU General Public Licenseバージョン2以降に移行するプロセスを開始するという難しい決断を下しました。今後、すべてのAsahi Linuxコードは、強力なコピーレフトライセンスのみの下でライセンスされます。歴史から学ばない者は、それを繰り返す運命にあります。

次回まで！

いつものように、OpenCollectiveおよびGitHub Sponsorsのサポーターの皆様に心から感謝いたします。皆様の寛大な支援があってこそ、私たちはプラットフォームのリバースエンジニアリングに時間とリソースを費やし、世界クラスの、洗練された、そして戦術的にテストされたLinuxデスクトップエクスペリエンスをもたらすことができます。皆様は私たちにとってすべてです。

James Calligeros · 2026-11-07