bhyve Enabled the nVidia GPU passthrough inside a Linux virtual machine via QEMU accelerated with BHYVE.

ZioMario

ZioMario

Hello.

here we are again. I continued the developing of the initial project of Abhinav Chavali, VMM Accelerator support for QEMU :

summerofcode.withgoogle.com

Google Summer of Code

Google Summer of Code is a global program focused on bringing more developers into open source software development.
summerofcode.withgoogle.com summerofcode.withgoogle.com

this time I've enabled the passthru of my nVidia GPU to a Linux VM. And finally we got it :


qemu-bhyve-gpu-pass.jpg


That's cool. Isn't it ? The internal logic of the passthru has been heavily copied from Corvin's code,so it is well written,since Corvin is a very good coder. The remaining code, the one used to adapt BHYVE Corvin's code to the logic used by QEMU, was written from scratch by Claude. So,that's it. Soon I will update the old code,the one I wrote to improve acceleration for QEMU that I put in my github repository,with the new code. Anyway,this is the official repos of the project :

github.com

GitHub - Marietto2008/qemu: @abhichavali fork of qemu for accelerating Linux and FreeBSD with qemu and bhyve/vmm

@abhichavali fork of qemu for accelerating Linux and FreeBSD with qemu and bhyve/vmm - Marietto2008/qemu
github.com github.com

Many thanks to the veterans of this forum for helping and supporting me since the beginning of my arrival here.
 
Last edited:
Added # FreeBSD VMM Extensions: Userspace PCI Passthrough (uppt) and ivshmem-plain Support

Feedback, review, and collaboration welcome. This is work in progress — the goal is to upstream both the FreeBSD kernel changes and the QEMU vmm backend to their respective projects.
 
ZioMario said:
the goal is to upstream both the FreeBSD kernel changes
Click to expand...

Has this been vibe coded, e.g. the LLM has produced most of the code?
What is the number of LOC added by the LLM? Who is going to review this code?

I think this should be a good guideline for somebody to write out the solution. You cannot ensure the code that LLM gave you is not license-tainted. Especially if it was using Linux kernel in the context.
 
Zare said:
Has this been vibe coded, e.g. the LLM has produced most of the code?
What is the number of LOC added by the LLM?
Click to expand...

yeah,Claude wrote everything. Anyway,Claude taken the code used for the passthru of the GPU heavily from the Corvin's repo. So,we can say that it is almost correct,since Corvin is great.

Who is going to review this code ?
Click to expand...

Oh. I think no one. For a lot of reasons.

I think this should be a good guideline for somebody to write out the solution. You cannot ensure the code that LLM gave you is not license-tainted. Especially if it was using Linux kernel in the context.
Click to expand...

What's the problem ? FreeBSD used a BSD license,very permissive. And if there is some Linux code,it is covered by a GPL3 license,it is allowed to use the code of someone if you share it and give credit to who wrote it. And I wanna do it. Do you want to do the same ?
 
Anyway,now we can try to virtualize macOS on FreeBSD 16 with QEMU / Bhyve. Not sure if it is legal or not.
Click to expand...

I wouldnt bother,
i have run mac osx with qemu on nixos

Its a absolute pain to set up and basically unusable

github.com

GitHub - kholia/OSX-KVM: Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required.

Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required. - kholia/OSX-KVM
github.com github.com

When you run the installer the mouse doesnt work properly it moves really slowly and stutters
which makes it almost impossible to click items in the installer

When you actually get it mac osx installed
opening applications is just awful everything grinds to a halt

You cant drag windows around and you just get the spinning beach ball of death

i only used it to log in with ssh to build some rust scripts

github.com

GitHub - NapoleonWils0n/ffmpeg-rust-scripts: Statically compiled FFmpeg Rust scripts for automated video and audio processing

Statically compiled FFmpeg Rust scripts for automated video and audio processing - NapoleonWils0n/ffmpeg-rust-scripts
github.com github.com

Its the most painful vm i have ever set up
i wouldnt wish the experience on anyone

I was a mac user for over 20 years
and the last good version of osx was snow leopard in 2009

All of the Apple software is dumbed down consumer rubbish
its like having ios on your computer

the only pro software that apple makes that is any good is final cut pro for video
and davinci resolve works just as well

and for audio logic and you can use things like ardour for that on freebsd

there is nothing on the mac that you would want to use
its the fisher price of operating systems

not to mention the nanny knows best security prompts
like do you want to allow the terminal access to the desktop

avoid it like the plague
 
NapoleonWils0n said:
I wouldnt bother,
i have run mac osx with qemu on nixos

Its a absolute pain to set up and basically unusable

github.com

GitHub - kholia/OSX-KVM: Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required.

Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required. - kholia/OSX-KVM
github.com github.com

When you run the installer the mouse doesnt work properly it moves really slowly and stutters
which makes it almost impossible to click items in the installer

When you actually get it mac osx installed
opening applications is just awful everything grinds to a halt

You cant drag windows around and you just get the spinning beach ball of death

i only used it to log in with ssh to build some rust scripts

github.com

GitHub - NapoleonWils0n/ffmpeg-rust-scripts: Statically compiled FFmpeg Rust scripts for automated video and audio processing

Statically compiled FFmpeg Rust scripts for automated video and audio processing - NapoleonWils0n/ffmpeg-rust-scripts
github.com github.com

Its the most painful vm i have ever set up
i wouldnt wish the experience on anyone

I was a mac user for over 20 years
and the last good version of osx was snow leopard in 2009

All of the Apple software is dumbed down consumer rubbish
its like having ios on your computer

the only pro software that apple makes that is any good is final cut pro for video
and davinci resolve works just as well

and for audio logic and you can use things like ardour for that on freebsd

there is nothing on the mac that you would want to use
its the fisher price of operating systems

not to mention the nanny knows best security prompts
like do you want to allow the terminal access to the desktop

avoid it like the plague
Click to expand...

I've virtualized macos on Linux with qemu + kvm some time ago and I didn't have so much troubles. And anyway,Claude will fix everything. What it can't fix is the law. If it is against the TOS,it will remains like this and no one can try. I never understood if it is legal or not.
 
The newer version of Mac os are really graphics heavy
and unusable in a vm

What mac os application do you want to use ?

You need a use case for mac os and there isnt one
All the apps are absolute dumbed down fisher price style garbage

You can use mac os in a vm or a hackintosh it is legal

There is just no point
Mac os is only designed to work on Apple hardware and not in vms

You better of just buying a Mac if you want a locked down proprietary operating system

Mac os is a truly awful operating system, terrible window management
Constant nanny knows best security features, when installing or using applications

Awful for installing open source software

There is no way i would ever use a mac again
 
It would be only a proof of concept or something like that,not for some kind of use. My GPU is nVidia,it is not supported by the MacOS. I could not use heavy and serious graphic applications. Once that the desktop manager had been reached, the experiment would stop. In any case, I don't think I'll do it.
 
Yes thats the other problem nvidia hasnt been supported by mac os for years

i only set up mac os in a vm to build some rust scripts

even the wallpaper slowed down the vm
and it was a pain to set a black screen instead of the wallpaper

the other thing is there is no audio unless you pass through and external audio device

and when you opened apps everything would slow down completely
and the mouse had a terrible lag when you tried to move it

so it was almost impossible to click anything

windows works really well in a qemu vm and you can play 1080p video with audio no problem

the mac on the other hand is painful beyond belief
 
ZioMario it is not a functional problem as much as code ownership problem. Some projects like QEMU and NetBSD have banned LLM output, explicitly because they consider it a tainted code. GPL3 or other non-permissive stuff cannot enter BSD-licensed kernel.
 
1. "AI-generated code is unverified and might violate someone else's rights"
Click to expand...

This concern is legitimate but needs to be put in context:

- Copyright protects **specific expression**, not ideas, algorithms, or architectural patterns. Claude does not verbatim copy-paste from its training data: it generates new code by applying technical knowledge.

- The real risk exists if I ask it to "reimplement function X identical to the one in Y" — in that case the output might get too close to the original. For my patches (small functional units, bhyve→QEMU bridging logic), the risk is minimal.

- The concern is **methodologically correct** as a general principle. On critical kernel code, reviewing AI-generated code against the original sources is always good practice. Tools like fossid, or even manual grep, are sufficient for patches of this size.

2. "GPL3 code cannot enter a BSD license"
Click to expand...

You are right on the principle, but is probably shooting at the wrong target:

| Project | License | Implication |
|---------|---------|-------------|
| FreeBSD kernel | BSD 2-Clause | kernel patches must be BSD |
| QEMU | **GPL2** (not GPL3) | QEMU patches must be GPL2-compatible |
| Corvin's bhyve patches | BSD 2-Clause | BSD → GPL2 is legal (I can add restrictions) |

The critical flow is:
- **BSD → GPL2**: ✅ legal, BSD is permissive
- **GPL2 → BSD**: ❌ illegal, GPL is copyleft
- **GPL3 → GPL2**: ❌ illegal, they are mutually incompatible
- **GPL3 → BSD**: ❌ doubly illegal
Click to expand...

**The issue is not Claude's code.** The issue would be if something from GPL3 sources (not from Corvin, whose code is BSD) had been incorporated. My QEMU patches derive from Corvin's code (BSD) adapted to QEMU's logic (GPL2), I'm in the legal flow.

I can use the code written by Claude freely. Anthropic explicitly transfers output rights to the user in its Terms of Use. The code produced during my sessions belongs to me.

How to license it:

- FreeBSD kernel patches → **BSD 2-Clause**, consistent with the FreeBSD kernel
- QEMU patches → **GPL2**, consistent with the QEMU codebase

No need to invent anything: the project I integrate the code into determines the license. My contribution follows the license of the project I'm extending.

The code written by Claude is **functional and original** — not a transcription of copyrighted sources. The kernel patches are BSD-compatible; the QEMU patches are GPL2-compatible because QEMU itself is GPL2. The GPL3 concern does not apply here.
 
The problem is probably more to do with the fact because the code is written by AI and not a human being
it makes it impossible for the project to talk to the person who submitted the code to review it

Because they dont know how everything works
and so wont be able verify there are no bugs or explain how all the bits of code work

Thats the problem with subcontracting you brain to a machine

So projects wont accept AI code and just trust it works

As opposed to someone who has knowledge of the subject
and has logically thought through how to solve a problem and submitted code to a project
 
I am not a C kernel programmer. I did not write the implementation line by line — Claude did. My role was different: I defined the architectural goal, directed the process, identified when the output was wrong, and validated the result on real hardware. That is a new model of software development, and I will not pretend otherwise.

But I think there is a distinction worth making. "Subcontracting your brain" implies you stop thinking. That is not what happened here. Deciding that bhyve's VMM should be the CPU virtualization backend while QEMU handles device emulation, deciding that ivshmem was the next goal to accomplish in the development — those were not Claude's decisions. I directed every architectural choice and rejected multiple implementations that did not match what I was trying to build. I just did not write the C.

Now, the open source community's concern is legitimate: if bugs arise, can I fix them? Honestly, not at the C level on my own. But that is also true of many contributors who submit code they partially understand. The difference is that I am transparent about it.

The code is public. Anyone who wants to review it can do so independently of me. I welcome that — not as a formality, but because review by someone with deep C kernel expertise is exactly what this code needs. If reviewers find problems, I can work with Claude to address them, or hand the code off entirely to someone more qualified. The goal is a working GPU passthrough on FreeBSD.

I think the real question the open source world needs to answer is: what is the right standard for AI-directed, human-validated contributions? Banning the tool entirely throws away real value. Accepting it without scrutiny is also wrong. Code review — applied to the code itself, not to the author's credentials — seems like the right answer.
 
You must log in or register to reply here.
Back
Top