The recording of the March 12th, 2026 #bhyve Production User Call is up:

https://youtu.be/RILtMsciJfk

We discussed CPU ID progress and desired user experience, Nvidia PCI Pass-Through on OmniOS, EDK2 updates, the Sylve call for testing, importing a Debian VM, and more!

"Don't forget to slam those Like and Subscribe buttons."

You can support all Call For Testing efforts via BSD Fund: https://bsdfund.org

2026-03-12 bhyve Production User Call

YouTube
@dexter Is anyone out there working on virtualized performance counter support?
@bms48 Do you have a link to examples? I’ll add it to the doc either way.
@dexter It is definitely of bsdfund.org interest. vPMU is a Red Hat KVM thing. I migrated from Hyper-V to KVM for my FreeBSD development last weekend. Hyper-V is SUPPOSED to support performance counter virtualization but VBS got in the way. There was a litany of Microsoft garden rakes that compelled me to migrate. We do still have a need to do core-level profiling; DTrace SDT is intrusive code-wise and FBT adds a lot of overhead to hot paths.
@dexter Allegedly eBPF is faster on some things than DTrace, and I did see something about kernel leak detection. I should have mentioned that but I had to hit the deadline today. It's not something we can do with CLang/LLVM for example, it has to be live, or the leaks only get caught on shutdown when the malloc tags or UMA zones are torn down. https://people.freebsd.org/~bms/devsummit/bms-devsummit-2026.pdf

@bms48 DTrace integration may encourage interest from the #illumos given that we have exchanged many key technologies.

In its current form, @bsdfund is a proposal-generating strategy that, with formal goals and milestones in place, passes around the hat. This has suited a handful of small projects well but somehow my fundraising efforts go primarily to @bsdcan and @openzfs

How “large”* a project do you estimate this to be?

* Not the optimal software metric.

@dexter @bsdfund @bsdcan @openzfs Surely you are referring to eBPF? The eBPF VM itself is probably the smallest part. The sauce is in the hooks which invoke it, and the toolchain surrounding it. It is too early to give an ETA and I had hoped to hear more from hrs@ but he is pretty oversubcribed. What is most compelling for me is the ability to use p4 for packet proessing workloads which is something I was looking at FPGA for days earlier but that has great complexity and risk. OpenFlow dead now.
@bms48 @bsdfund @bsdcan @openzfs vPMC stood out for me.
@dexter @bsdfund @bsdcan @openzfs Sure, vPMU would help out a lot of people trying to do kernel development by profiling in VMs where kgmon is no longer a thing. In an ideal world everyone would be able to profile code on the bare metal when needed, but that is not always possible. Both eBPF and DTrace introduce bias. On PhD for example I couldn't use DTrace FBT on the network hot path, and for a protocol in dev, instrumenting everything with static SDT probes is too much dev overhead.
@dexter @bsdfund @bsdcan @openzfs If we can get everyone to pitch in towards #ebpf so much the better, @allanjude at Klara should be in the loop, but I'd need to page in the eBPF devnotes I have to my core, and it is a context shift, before nailing jelly to the wall again. Our tcpstats contributor from GitHub expressed private interest on LinkedIn today.