OpenBSD-current、Apple Hypervisorでゲストとして実行可能に

 (undeadly.org)
2 ポイント 投稿者 GN⁺ 2026-01-17 | 1件のコメント | WhatsAppで共有
  • OpenBSD/arm64 が Apple Hypervisor 環境でゲストOSとして動作可能に
  • 一連のコミットにより グラフィックス処理とネットワーク機能 が修正・改善され、カーネルパニックと X11 のブラックスクリーン問題を解決
  • これで Apple Virtualization 環境で完全に動作し、最新の Apple Silicon Mac で利用可能

Apple HypervisorでのOpenBSD/arm64サポート

  • 最近のコミットにより OpenBSD/arm64 が Apple Hypervisor 上でゲストOSとして実行可能に
    • 関連コミットは Helg Bredow(helg@) と Stefan Fritsch(sf@) が実施

Helg Bredowによるviogpu修正

  • sys/dev/pv/viogpu.c ファイルで viogpu_wsmmap() 関数が修正
    • 従来はカーネル仮想アドレス(kva)を返していたが、現在は bus_dmamem_mmap(9) を通じて物理アドレスを返す
    • この修正により、QEMUでX11を実行した際に発生していた ブラックスクリーン問題 と Apple Hypervisor 上での カーネルパニック が解消
  • フレームバッファをホストメモリへ転送する前に bus_dmamap_sync(9) の呼び出しを追加
    • これにより、別のCPUで動作中のホストがフレームバッファ更新を認識可能に
    • 修正レビューとフィードバックは kettenis@ が担当し、承認(ok)は sf@ が付与

Stefan Fritschによるvirtioネットワーク修正

  • sys/dev/pv/if_vio.c ファイルで VIRTIO_NET_F_MTU 機能 のサポートを追加
    • ハイパーバイザーから hardmtu 値を取得し、現在の MTU を同じ値に設定
    • virtio 標準は明確ではないが、Linuxと同じ方式 を採用
  • ETHER_MAX_HARDMTU_LEN を上限として使用し、従来の MAXMCLBYTES より正確に処理
    • ハイパーバイザーがこれより大きい MTU を要求した場合、VIRTIO_NET_F_MTU 機能なしで再ネゴシエーション を実施
  • このコミットにより OpenBSDがApple Virtualization環境で完全に動作
    • 入力とテストは helg@ が担当し、承認(ok)は jan@ が付与

ユーザー案内とテスト推奨

  • この変更は 最新のApple Silicon Macモデルのユーザー に特に有用
  • 現在 スナップショット版 でテスト可能で、ユーザーフィードバックを募集

関連記事

1件のコメント

 
GN⁺ 2026-01-17
Hacker News のコメント
  • 良いアップデートだ。VIRTIO_NET_F_MTU ネゴシエーションが Apple の仮想化スタックにおける複数のゲスト OS 実装の障害になっていた。
    仕様が曖昧なため Linux はそのまま動くが、OpenBSD ではハード MTU 制限を扱うために別パッチを入れる必要があった。
    M4/M5 チップのシングルスレッド性能のおかげで、OpenBSD ゲストは pf 設定のテストや隔離されたメールサーバーの運用に最適な環境だ。
    これで viogpu を安定して使えるようになり、高速な VM インストール時にシリアルコンソールだけを使っていたやり方から脱却できる。
    Helg と Stefan に大きな拍手を送りたい。
    • ユニカーネル(unikernel)ならさらに良いかもしれない。ただ、その場合は OS なしで動作できるメールサーバー向けユニカーネルが必要になる。
    • 私はそういうグラフィカル環境は不要だ。私の IaC(インフラのコード化) は VM を起動する際にいかなる対話も求めない。
  • より大きなニュースは、このアップデートが QEMU 互換性バグを解決した点だ。
    このバグのせいで arm64 では OpenBSD が X を起動するとフリーズしていたが、7.3 バージョンのフレームバッファ変更以降に生じた問題だった。
    唯一の回避策はカーネルドライバを無効化することだったが、これでもっと多くの人が問題なく OpenBSD を試せるようになると思う。
    • 私もその一人だ。しばらく使ってみたかったが、手元の唯一のマシンが MacBook Pro なのでできなかった。
    • なぜ QEMU が X を起動する必要があるのか気になる。それは OpenBSD の役目ではないのだろうか。
  • これは Virtualization.framework(Apple の純正 VMM) に関する話だ。
    OpenBSD はかなり前から Hypervisor.framework + QEMU の組み合わせでも動作していた。
    • 名前がややこしすぎる。2 つのフレームワークを区別するのがほとんど不可能だ。
    • よく分からないが、それは Tahoe で導入されたものだったのだろうか。以前は不可能だったことが可能になった理由が気になる。
    • 私も混同していた。UTM は内部的に QEMU を使っているが、今では OpenBSD スナップショットが QEMU でスムーズに起動する。依然として仮想化された状態ではある。
  • 何か見落としているのかもしれないが、VM をテストしていると、一度増えたメモリが決して 減らない問題があった。
    これが実際の問題なら改善があるのか気になる。
    • ゲストがホストに「このメモリは完全に解放したので回収してよい」と知らせるのはかなり複雑なことだ。
      逆に、ゲストは 4GiB RAM があると信じているが、実際にはアクセス時にだけホストが割り当てるという仕組みのほうがずっと単純だ。
      VM はコンテナとはまったく別物だ。
    • どこで VM をテストしたのか気になる。世界中で毎日何億台もの VM が動いている。
  • これを実際に試すためのガイドはあるだろうか? 私は raw hypervisor を使ったことがない。
    • 軽く Kagi で検索したら このブログ記事 を見つけた。たぶん役に立つかもしれない。
    • 基本的にはカーネルと、必要なら RAM ディスクを作って、Linux のようにブートすればよい。
  • 少し関連する話だが、UTM Remote は本当に優れた VM リモートクライアントだ。
    他のハイパーバイザープロトコル(libvirtd、bhyve など)にも対応してほしい。
  • OpenBSD をゲストとして動かす場合、セキュリティが十分かどうか気になる。
    ホストが数学的に侵入不可能なほど隔離されるのか知りたい。鍵管理用途には理想的かもしれない。
    • 2025 年時点で OpenBSD は AMD SEV/SEV-ES をサポートしており、SEV-SNP は開発中だ。
      適切なハードウェアがあれば十分に隔離できる。
      関連内容は BSDCan 2025 の発表 でも扱われている。
    • ただし、ホストカーネルと VMM は依然としてゲストメモリを見ることができる。そういう用途には勧めない。
  • 参考までに、この Redox fork は完全に Rust ベースで、Makefile が一切ない。
  • よくやった! 現在 FreeBSD 15 は UTM で X がまったく動作しない。
    RDP/VNC しか使えない状況なので、今回の改善でフレームバッファが動くようになることを期待している。