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しかないので、困ったものです。
引き続き、原因が分かったらまた記事を書くと思います。