Re: QEMU accepting AI code - viable alternatives for NVMM (bhyve/vmm)?

---> Is there any serious momentum behind getting OpenBSD's vmm or FreeBSD's bhyve working seamlessly as the frontend for NVMM? I'd much rather migrate to a clean, human-maintained codebase than deal with the fallout of whatever QEMU is about to merge into their tree.

We (me,a friend of mine and Claude) have recently improved the job of Abhinav Chavali :

https://summerofcode.withgoogle.com/archive/2025/projects/lRkVElCJ

that added VMM acceleration support to QEMU on FreeBSD. Now it is fully working on my github.

At the moment we are working to enable the GPU passthrough,using my GPU [RTX 2080 ti].

I've got so many improvements in 1 week that a full programming team would not be able to achieve in years. Maybe not because they have no competence,but because *BSDs are OS used by 1% of the people. Programmers are few, underpaid and overworked. Times have changed. Today with AI we can carry on a lot of long complicated projects in a fraction of time and money. No one,nothing can stop this. What can be done,maybe,is the code correction by humans. But I don't think it's easy, for the same reasons explained above. AI creates a lot of code (and Claude's is of good quality) in a short time. Humans can't keep up with it.

Mario.

On Mon, Jun 1, 2026 at 4:56 PM Aryabhata <bsdhexa%gmail.com@localhost> wrote:

Hey everyone,

I'm sure some of you caught the recent news that QEMU is revising its policy to start accepting AI/LLM-generated code. Frankly, the idea of running VMs on a hypervisor padded with unreviewable AI slop is extremely off-putting.

Since QEMU is the main userspace consumer for NVMM right now, it feels like we're tethered to an upstream project that's actively lowering its standards. What is everyone else planning to use as a daily driver to avoid this?

Is there any serious momentum behind getting OpenBSD's vmm or FreeBSD's bhyve working seamlessly as the frontend for NVMM? I'd much rather migrate to a clean, human-maintained codebase than deal with the fallout of whatever QEMU is about to merge into their tree.

Would love to hear what alternatives you guys are looking at.

Thanks,

Arya