1. BhyveとPCI passthroughの問題

そもそも、PCI passthroughとはなんぞやというおさらいから。

PCI passthroughとは、仮想マシンゲスト上でホスト側のPCIデバイスをそのまま見せるという仕組みです。
ホスト側ではそのデバイスをそのまま使うことは出来ず、ゲスト側のOSで認識して利用することが出来ます。これを利用すると、FreeBSD用のドライバがないデバイスも、ドライバがあるOSをゲストで使うとデバイスを利用出来るようになります。

例えばUSBホストコントローラをパススルーすると、ゲスト側でUSBデバイスが使えるようになります。多くのUSBデバイスはFreeBSD用のドライバが用意されていないないことも多いので、有効利用出来るというわけです。

そんなわけで、当時はWindows 10 をゲストにしており、USB ホストコントローラの
PCI passthrough も特に問題なく動作していました。
その時書いていた記事がこれ。

Windows 10では問題なく使えていたPCI passthroughですが、Windows 11になって、起動時にハングアップするようになっていました。その時の記事がこれ。

ゲストをWindows11へアップデートしたところ、使えなくなってしまったのです。
しかし、先日15-STABLEに修正パッチが入ったのを見ました。
早速Windows 11で使えるようになったのか確かめようと思います。

2. 実行環境

2.1 ハードウェア

昔こういう記事を書きました。この時のPCをまだ使っています。
メモリだけ128GBになっています。後は基本同じ。

2.2 FreeBSD 15-STABLE

パッチの詳細は後述しますが、とにかくパッチは15-STABLEに入っており、15.0-RELEASEには取り込まれませんでした。これまでは14.3-STABLEを使用していましたが、せっかく15.0-RELEASEも出たので、ここで15-STABLEにしようと思い立ち、アップデートしました。

3. bhyve改善パッチ

https://forums.freebsd.org/threads/bhyve-vm-stuck-when-passthru-enabled.92854/
こちらの記事から、パッチが紹介されていました。

https://reviews.freebsd.org/D37972
そのパッチがこれ。

そして、/usr/srcでgit logを確認するとこのように、修正が入っていることが確認出来ます。

# git log sys/amd64/vmm/vmm.c
commit 300a8977bcfd2f43bc6df81d9bdad6b79a740729
Author: Mark Johnston <markj@FreeBSD.org>
Date:   Fri Oct 17 13:09:38 2025 +0000

    vmm: Fix a deadlock between vm_smp_rendezvous() and vcpu_lock_all()

説明はかなり長いので詳細は省略しますが、要するに以下のような
vCPU 間のデッドロックを防ぐ修正です。

vCPU A: vm_smp_rendezvous() を開始
        → 他の全 vCPU のコールバック完了を待つ

vCPU B: vcpu_lock_all() に入る
        → vCPU A が idle になるのを待つ

15-STABLEに入っているので、難しい作業は必要ありません。
git pullでソースを15-STABLEの最新にした後、make buildworld && make buildkernelやって、make installkernel, make installworldをやればいいだけです。
実際はetcupdateなど必要ですが、この記事では省略します。詳しく知りたい人はFreeBSD handbookなどを参照してください。

# uname -rv
15.0-STABLE FreeBSD 15.0-STABLE stable/15-ffd47a4bc671 GENERIC

という感じで15-STABLEになったら、PCI passthroughを設定して早速確認してみます。

4. PCI passthroughデバイスをWindows 11で認識させる

現在もbhyveの制御にはvm-bhyveパッケージを利用しています。
現時点での最新は1.7.0_1ですね。
以降の説明はvm-bhyveを使っていることを前提に書くので、よく分からない場合は公式サイト (https://github.com/churchers/vm-bhyve) を見るか、検索で探してみてください。

4.1 ホスト側の設定

まずは、パススルーデバイスとしてホスト側から予約します。

# vm passthru
DEVICE     BHYVE ID     READY        DESCRIPTION
(中略)
ix0        1/0/0        No           Ethernet Controller X550
ix1        1/0/1        No           Ethernet Controller X550
nvme0      2/0/0        No           E18 PCIe4 NVMe Controller
ppt0       3/0/0        Yes          Killer E3000 2.5GbE Controller
xhci1      4/0/0        No           ASM3042 USB 3.2 Gen 1 xHCI Controller

私の設定では既に、Killer E3000 2.5GbE Controllerがパススルーデバイスとして設定されていますが、その後のASM3042 USB 3.2 Gen 1 xHCIの方もパススルーデバイスとして設定します。以前は再起動しなきゃダメかなと思いましたが、devctl コマンドで PCI デバイスのドライバを切り替えられることが分かりました。詳しくはman vmmを見てください。

# devctl set driver -f pci0:4:0:0 ppt
# vm passthru
DEVICE     BHYVE ID     READY        DESCRIPTION
(中略)
ppt0       3/0/0        Yes          Killer E3000 2.5GbE Controller
ppt1       4/0/0        Yes          ASM3042 USB 3.2 Gen 1 xHCI Controller

これで、ホスト側のドライバxhciが開放されて、パススルーデバイスppt1として認識されました。起動時からpptデバイスにするには/boot/loader.confに書きます。これについては以前の記事を見てください。

4.2 ゲスト側の設定

vm configコマンドで仮想マシンの設定を変更します。最後のwindowsは設定ファイルの名前なので、環境に応じて変わります。

# vm config windows
passthru0="3/0/0"
passthru1="4/0/0"

これでゲストからパススルーデバイスを使う設定ができました。
早速起動してみましょう。

# vm start windows
Starting windows
  * found guest in /data/vm/windows
  * booting...

以前はいきなりハングアップしてどうしようもなかったですが、無事に起動することが確認出来ました。

4.3 しかし問題が...

Windows側のデバイスマネージャーで見ると異変が...

ネットワークアダプターのKiller E3100G 2.5 Gigabit Ethernet Controllerの方は問題ありません。ただ、実際ケーブル接続してテストまではしてないのですが...
問題は、ASMedia USB 3.1 eXtensible Host Controllerの方。△に！マークがついており、動作していません。

無情にも「問題が発生したのでこのデバイスは停止しました。(コード43)」となっています。ゲストを何度か再起動もしてみましたが、改善せず。passthroughで見せているデバイスが、中途半端な情報をゲストに見せており、完璧な動作になっていないのかというところですが、現時点では原因は分からず、お手上げ...

ホストで使っているマザーボードはもう一つ

xhci0      0/20/0       No           Alder Lake-S PCH USB 3.2 Gen 2x2 XHCI Controller

というデバイスも載っているので、試しにこちらも使えないかと思い試しましたが、今度はこのコントローラ配下のUSB root hubに異常が発生して動作しないという現象となってしまい、結局USBのパススルーは使えないままです。

なお、これは Windows 11 側のドライバやセキュリティ強化の影響の可能性もあり、bhyve 側の修正だけでは解決しない問題の可能性もあります。

5. おわりに

bhyveゲストでWindows 11を動かし、PCI passthroughを使うとハングアップするという事象そのものは解消しました。しかし、USBのパススルーは現状では利用出来ませんでした。他のデバイスなら大丈夫かもしれませんが、今のところゲストで使いたいデバイスがUSBしかないので、困ったものです。

引き続き、原因が分かったらまた記事を書くと思います。