世界を動かす技術を、日本語で。

OpenBSD-currentがApple Hypervisorの下でゲストとして動作するようになりました

概要

OpenBSD/arm64がApple Hypervisor上でゲストOSとして動作可能に 主要な修正はHelg BredowとStefan Fritschによるコミット viogpuとvirtioネットワーク関連のバグ修正と機能追加 Apple Silicon Macユーザーにとって大きな進展 最新スナップショットでのテストとフィードバックの呼びかけ

OpenBSD/arm64、Apple Hypervisor対応の進展

  • OpenBSD/arm64Apple Hypervisor 上でゲストOSとして動作可能となった進展
  • Helg Bredow(helg@)とStefan Fritsch(sf@)による 重要なコミット の実施
    • viogpuとvirtioネットワーク関連の バグ修正新機能追加
  • Apple Silicon Mac(M1/M2/M3等)上での 仮想化環境拡充
  • 最新スナップショットでの 動作確認推奨フィードバック要請

viogpu関連の修正内容

  • viogpu_wsmmap()の返り値を kva(仮想アドレス)から物理アドレス に修正
  • bus_dmamem_mmap(9)経由で 正しい物理アドレス取得 を実現
  • QEMUではX11起動時に ブラックスクリーン問題 が発生していたが修正
  • Apple Hypervisor上で カーネルパニック回避
  • フレームバッファ転送前に bus_dmamap_sync(9) を追加
    • 複数CPU環境での フレームバッファ更新の即時反映 を保証
  • kettenis@による コードレビューとフィードバック
  • sf@による 承認(ok)

virtioネットワーク機能の改善

  • if_vio.cで VIRTIO_NET_F_MTU 機能をサポート
    • ハイパーバイザーから ハードMTU値取得 が可能
    • 現在のMTUも同じ値に設定(Linuxと同様の挙動)
  • ETHER_MAX_HARDMTU_LEN を上限MTU値として採用
    • 以前のMAXMCLBYTESよりも 正確な基準
  • ハイパーバイザーが ETHER_MAX_HARDMTU_LEN超のMTU を要求した場合
    • VIRTIO_NET_F_MTUを除外して 再ネゴシエーション を実施
  • これらの対応により Apple Virtualizationでの安定動作 を実現
  • helg@の 入力とテスト、jan@による 承認(ok)

Apple Silicon Macユーザーへの呼びかけ

  • Apple Silicon Mac を所有し、仮想環境構築可能なユーザーへの テスト推奨
  • 最新スナップショットでの 動作検証とレポート提出 を依頼
  • OpenBSD/arm64の 今後の仮想化対応強化 への貢献呼びかけ

Hackerたちの意見

これはVirtualization.framework(Appleの純正VMM)についての話だよ。OpenBSDはずっと前からHypervisor.frameworkとqemuに取り組んでるんだ。

確かにいい指摘だね。そのフレームワークの名前は本当に混乱する。個人的には、混同しないのはほぼ不可能だと思うよ。

ちょっとついていけてないな。あれってTahoeが紹介してたやつ?それって以前は不可能だったことを解決したの?

これをやるためのガイドってあるの?生のハイパーバイザーは使ったことないんだよね。

カーネルを作って、必要ならLinuxと同じようにブートできるRAMディスクを用意するだけのはずだよ。

ちょっとKagiで検索したら、これが見つかったよ: https://briancallahan.net/blog/20250222.html、もしかしたら君にも合うかも?

もっと大きなニュースは、これがQEMUの互換性バグも修正するってこと。これのおかげで、OpenBSDはarm64でXを起動するときにハングしちゃうんだ。これは7.3からフレームバッファの変更で始まって、唯一の対処法はカーネルドライバーを無効にすることだった。これで、もっと多くの人がOpenBSDをうまく試せるようになるかもね。

いいアップデートだね。VIRTIO_NET_F_MTUの交渉は、Appleの仮想化スタックで多くのゲストOSの実装にとって障害になってた。仕様が曖昧すぎて、Linuxはそのままやっちゃうけど、OpenBSDはハイパーバイザーのhardmtu制限に対応するために明示的にパッチを当てなきゃいけなかった。これはローカル開発にとって大きな意味があると思う。M4/M5チップの生のシングルスレッド性能を考えると、OpenBSDゲストはpf設定のテストや隔離されたメールサーバーを運用するのに最適な環境だと言えるよね。viogpuに頼れるようになったおかげで、急いでVMを立ち上げるためにシリアルコンソールだけのインストールから少しずつ離れられるようになる。HelgとStefanに大きな感謝を!

Xもネットワークもないじゃん。じゃあ、何の意味があるの?無駄だと思う。

なんか見落としてるかもしれないけど、最近VMをテストした時、RAMのサイズが一度増えたら縮まらない感じだったんだよね。これって本当に問題なの?もしそうなら、改善の予定とかあるのかな?

よくやった!FreeBSD 15は今のところutmでは完全に無理だね。rdp/vncが唯一の方法だよ。誰かがここでフレームバッファを動かす方法を見つけてくれるといいな。

それって、少なくともこのフォークのredoxは、完全にRustベースでMakefileなしってこと?