The proposal has the renderer send the framebuffer = back to bhyve, and bhyve then dispatches it out again over D-Bus t= o a display program. That round trip exists in QEMU only because QEMU owns = the UI =E2=80=94 the window, the input, the multi-head config. If bhyve del= iberately owns no UI (and it shouldn't), then bhyve has no business tou= ching pixels.

vhost-d=
evice-gpu

already has a D-Bus backend; let it talk to the compositor= proxy directly. bhyve keeps only the vhost-user control plane.

That collapses your design from "vhost-user su= pport + a new display backend + an out-of-tree D-Bus proxy" to "v= host-user support." No D-Bus in base, no awkward out-of-tree shim to j= ustify, no second copy of the scanout, and the whole licensing conversation= about the display backend evaporates. It's a strictly stronger proposa= l and it's the one I'd write.

The one thing that genuinely does have to come back= to bhyve is input =E2=80=94 the external window owns the = keyboard/mouse events and the guest's xhci,tablet/virtio-input lives in bhyve. But th= at's a thin, well-understood channel, not a reason to route the framebu= ffer through bhyve. Say so explicitly in the proposal, because someone will= ask.

"Secure" as stated will get pushback, and= rightly. A vhost-user backend mmaps all of guest memory and holds= host GPU contexts =E2=80=94 it's fully inside the guest's TCB and = has a large privileged surface. That's not more secure than passthrough= in the abstract. The honest and still very strong framing is: virglren= derer, Mesa, libepoxy and the entire GL stack stay out of the base system b= inary and out of bhyve's address space. The isolation benefit is b= hyve-side, not guest-side. State it that way and it's defensible.

Scope limits worth stating up front, becaus= e they'll be discovered anyway:

On udmabuf's role: be precise = about where it actually buys you something. It's the right primitive fo= r blob resources with guest-memory backing (VIRTGPU_BLOB_MEM_GUEST) =E2=80=94 turning gue= st pages into something the host GPU can texture from without a copy. It is= not the mechanism for the 3D path, where resources are already GP= U-side. And on FreeBSD there's the extra question of whether the fd you= r GSoC work produces is accepted by Mesa's EGL_EXT_image_dma_buf_import through Linux= KPI's dma-buf, or only importable by drm-kmod internals. If that end-to= -end import isn't demonstrated yet, demonstrating it is the single high= est-value next step =E2=80=94 it's the load-bearing assumption under th= e whole proposal.

Stage it. Reviewers will ask "= ;why not do the small thing first?", and you want an answer ready:

Each stage is independently mergeable and independe= ntly useful. A single 3000-line "graphics rework" patch series ag= ainst base has a much worse survival rate than three of those.

Two things to clear early, while they'r= e cheap: the vhost-user protocol is documented in QEMU's docs/interop/vhost-user.rs= t (and the GPU sub-protocol in vhost-user-gpu.rst) under QEMU's licensing. A c= lean-room BSD implementation from a spec document is normally fine, but get= a read from core@ or the Foundation before you've written the code, no= t after. And confirm what licensing constraint actually applies to a po= rt in the tree versus a dependency =E2=80=94 the proposal ass= umes "no GPL in base" is the binding constraint, and it is, but t= he D-Bus objection specifically evaporates under the architecture change ab= ove, so don't design around a constraint you've already engineered = away.

Short version: worth doing, the idea is so= und, and you're targeting a real gap. Reframe it as generic out-of-proc= ess device backends with GPU as the first user, take bhyve out of the pixel= path, and stage it. That version I'd expect to get a genuinely positiv= e reception

On Tue, Jul 28, 2026 at 1:48=E2=80=AFPM yi zishun <zishun.yi.dev@gmail.com> wrote:<= br>

Hi, hackers

As the title suggests, briefly speaking, the proposed option is a
combination of "vhost-user-gpu" and another display backend (for<= br> example, a D-Bus backend).

Currently, bhyve has two main approaches for graphics rendering and
display. One is fbuf+VNC for 2D graphics, and the other is GPU
passthrough mainly for 3D workloads.=C2=A0 Both approaches have some
obvious drawbacks. For example, fbuf is non-accelerated and VNC does
not support zero-copy transfer, which makes fbuf+vnc have poor
performance. GPU pci passthrough has excellent performance. But due to
its exclusive use, the host cannot access the GPU anymore, not to
mention supporting multiple VMs.

I understand why these two designs exist: because bhyve is part of the
base system, we cannot introduce GPL-licensed software or heavy
graphics dependencies. So it is better, if there is an option, with a
minimal implementation without any heavy dependence, but still can use
modern graphics stack render and display capabilities, and can support
multiple VM.

My motivation for this proposal stems from my GSoC work on udmabuf.
With the underlying zero-copy buffer sharing mechanism now in place, I
wanted to explore how bhyve could natively utilize it to overcome the
current performance bottlenecks in graphics rendering and displaying.

For rendering, we can implement a device which presents itself to the
guest kernel as a virtio-gpu device, but does not process any commands
internally, the main virtqueue is handled by a separate userspace
program, vhost-user-gpu. And the device communicates to vhost-user-gpu
using vhost-user protocol. One implementation of vhost-user-gpu is
rust-vmm's vhost-device-gpu, which processes the data and sends the
rendered image back to QEMU/bhyve for display, and currently supports
gtk and dbus backend as far as I know. We can then implement a new
display backend, dbus backend, to dispatch the display to another
program, too. But we can't introduce dbus into the base system, so
maybe we need another out-of-tree small proxy to do the conversion.

In conclusion, this approach dispatches the actual rendering and
display tasks to two separate programs. bhyve only presents itself as
a virtio-gpu device from the guest's point of view, and communicates to the two programs internally. This option is minimal, modular, and
secure, leveraging the modern graphics stack to support multiple VMs
without requiring dedicated hardware support, while providing the
benefits of virtio-gpu.

I would appreciate any feedback and discussion on the feasibility of
this approach. If the idea is considered worthwhile, I am willing to
invest the time and effort required to implement it.

Best,
Zishun Yi