io_gpu(4) in the guest is a simple 2D/scanout driver with no virgl support. Day one, the only guest that benefits is Linux. That is a slightly awkward thing to s= ay on a FreeBSD list, so get ahead of it: the guest-side work is a separate= , later, and independently useful project. - *virglrenderer's GL passthrough is the legacy path.* The direction of travel is Venus (Vulkan) and gfxstream via rutabaga. Since vhost-device-gpu is built on rutabaga anyway, you inherit that =E2=80=94= but note that rutabaga/vhost-device-gpu is Linux-shaped (memfd, eventfd, /dev/dri assumptions, vmm-sys-util coverage) and budget real time for the FreeBSD port of the *backend*, separately from the bhyve work. That port may well be larger than the bhyve side. *On udmabuf's role:* be precise about where it actually buys you something. It's the right primitive for blob resources with guest-memory backing ( VIRTGPU_BLOB_MEM_GUEST) =E2=80=94 turning guest pages into something the ho= st GPU can texture from without a copy. It is *not* the mechanism for the 3D path, where resources are already GPU-side. And on FreeBSD there's the extra question of whether the fd your GSoC work produces is accepted by Mesa's EGL_EXT_image_dma_buf_import through LinuxKPI'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 highest-value next step =E2=80=94 it's the load-bearing assumption under the whole proposal. *Stage it.* Reviewers will ask "why not do the small thing first?", and you want an answer ready: 1. Native 2D virtio-gpu in bhyve (no vhost-user), rendering into the existing fbuf/VNC path, using udmabuf to avoid the copy. Small, self-contained, immediately useful =E2=80=94 gets you guest-driven resiz= e, multi-head, and a real EDID, all of which fbuf lacks. Also proves the udmabuf import path in isolation. 2. Generic vhost-user support in bhyve, demonstrated with something boring and valuable (virtiofsd, or vhost-user-blk). 3. vhost-user-gpu as a consumer of (2), with the backend ported separately. Each stage is independently mergeable and independently useful. A single 3000-line "graphics rework" patch series against base has a much worse survival rate than three of those. *Two things to clear early, while they're cheap:* the vhost-user protocol is documented in QEMU's docs/interop/vhost-user.rst (and the GPU sub-protocol in vhost-user-gpu.rst) under QEMU's licensing. A clean-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, not after. And confirm what licensing constraint actually applies to a *port* in the tree versus a *dependency* =E2=80=94 the proposal assumes "no GPL in base" is th= e binding constraint, and it is, but the D-Bus objection specifically evaporates under the architecture change above, so don't design around a constraint you've already engineered away. Short version: worth doing, the idea is sound, and you're targeting a real gap. Reframe it as generic out-of-process 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 positive reception Mario. On Tue, Jul 28, 2026 at 1:48=E2=80=AFPM yi zishun = wrote: > Hi, hackers > > As the title suggests, briefly speaking, the proposed option is a > combination of "vhost-user-gpu" and another display backend (for > 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. 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 > > --=20 Mario. --00000000000064e8190657aa9c5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---> Worth adding another graphics option to bhyve?


This is a well-framed proposal, an= d the answer is yes =E2=80=94 but the version described has one process too= many, and the actual cost center isn't the GPU part at all. A few thin= gs I'd push on before it goes to the list.

The hard part is vhost-user, not virtio-gpu= .

The proposal treats vhost-user as a given and spend= s its argument on the GPU. That's backwards. bhyve has no vhost-user in= frastructure today, and the GPU is just the first consumer. The real work i= s:

Lead with the fact that this infrastructure= isn't GPU-specific. That's the argument that actually get= s it merged. Once bhyve speaks vhost-user, you get virtio-fs (virtiofsd =E2= =80=94 which FreeBSD badly wants and which is a much easier sell than graph= ics), vhost-user-blk, vhost-user-net, and a general escape hatch for "= we want this feature but not its dependencies in base." Pitching it as= "graphics" makes it a niche desktop feature. Pitching it as &quo= t;a generic out-of-process device backend mechanism, with GPU as the demons= trator" makes it infrastructure. Same code, very different reception o= n freebsd-virtualization@.

Drop bhyve from the scanout path entirely.<= /strong>

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.

Tighten the security claim.

"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:

  • Windows guests get nothing from this. virtio-wi= n ships a display-only virtio-gpu driver; there is no production 3D virtio-= gpu guest driver for Windows. Anyone hoping this replaces passthrough for a= Windows gaming or CUDA VM will be disappointed. Say so, or the thread will= spend forty messages on it.
  • FreeBSD gu= ests get nothing initially either. virtio_gpu(4) in the guest is a simple 2D/sca= nout driver with no virgl support. Day one, the only guest that benefits is= Linux. That is a slightly awkward thing to say on a FreeBSD list, so get a= head of it: the guest-side work is a separate, later, and independently use= ful project.
  • virglrenderer's GL pas= sthrough is the legacy path. The direction of travel is Venus (Vul= kan) and gfxstream via rutabaga. Since vhost-device-gpu is built on rutabaga anyway, you = inherit that =E2=80=94 but note that rutabaga/vhost-device-gpu is Linux-sha= ped (memfd, eventfd, = /dev/dri assumptions, vmm-sys-util coverage) and budget real time for the FreeBSD = port of the backend, separately from the bhyve work. That port may= well be larger than the bhyve side.

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:

  1. Native 2D virtio-gpu in bhyve (no vhost-user), rendering int= o the existing fbuf/VNC path, using udmabuf to avoid the copy. Small, self-= contained, immediately useful =E2=80=94 gets you guest-driven resize, multi= -head, and a real EDID, all of which fbuf lacks. Also proves the udmabuf im= port path in isolation.
  2. Generic vhost-user supp= ort in bhyve, demonstrated with something boring and valuable (virtiofsd, o= r vhost-user-blk).
  3. vhost-user-gpu as a consumer= of (2), with the backend ported separately.

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

Mario.


=
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



--
Ma= rio.
--00000000000064e8190657aa9c5a--