Date: Tue, 28 Jul 2026 14:01:43 +0200 From: Mario Marietto <marietto2008@gmail.com> To: yi zishun <zishun.yi.dev@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-virtualization@freebsd.org Subject: Re: Worth adding another graphics option to bhyve? Message-ID: <CA%2B1FSii8khkT9wOootnddVjAoK0Td%2BCF3kVeeuUAERF7ko_QEg@mail.gmail.com> In-Reply-To: <CABjVtiZc-y9H0ob8Fxk94zpsSpsp5qZcPSSg0q4geLq3S0S7rw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] ---> Worth adding another graphics option to bhyve? This is a well-framed proposal, and the answer is yes — but the version described has one process too many, and the actual cost center isn't the GPU part at all. A few things 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 spends its argument on the GPU. That's backwards. bhyve has no vhost-user infrastructure today, and the GPU is just the first consumer. The real work is: - *Memory sharing model.* vhost-user's SET_MEM_TABLE assumes the VMM can hand the backend an fd per memory region that the backend mmaps at a given offset. bhyve's guest memory lives behind /dev/vmm/<name> and is set up by vm_setup_memory() in libvmmapi. You either pass the vmm device fd and teach the backend a FreeBSD-specific mapping path (breaking protocol compatibility, which defeats the point of using vhost-user), or you restructure guest memory allocation so it's backed by shm objects that can be shared conventionally. That second option is a non-trivial change to something quite load-bearing. - *Capsicum.* bhyve enters capability mode after device init. Connecting a unix socket by pathname won't work post-cap_enter, so the socket has to be pre-opened or inherited, and SCM_RIGHTS handling has to be sane in cap mode. Solvable, but it constrains the CLI design (you'll want an fd-passing or pre-connect scheme, not just -s N,virtio-gpu,sock=/var/run/foo.sock opened lazily). - *Eventfd/irqfd equivalents.* vhost-user's kick/call fds are eventfds. FreeBSD has eventfd(2) now, but the backend's expectations around semantics and the POLLIN behaviour need verifying rather than assuming. *Lead with the fact that this infrastructure isn't GPU-specific.* That's the argument that actually gets it merged. Once bhyve speaks vhost-user, you get virtio-fs (virtiofsd — which FreeBSD badly wants and which is a much easier sell than graphics), 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 "a generic out-of-process device backend mechanism, with GPU as the demonstrator" makes it infrastructure. Same code, very different reception on freebsd-virtualization@. *Drop bhyve from the scanout path entirely.* The proposal has the renderer send the framebuffer *back* to bhyve, and bhyve then dispatches it out again over D-Bus to a display program. That round trip exists in QEMU only because QEMU owns the UI — the window, the input, the multi-head config. If bhyve deliberately owns no UI (and it shouldn't), then bhyve has no business touching pixels. vhost-device-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 support + a new display backend + an out-of-tree D-Bus proxy" to "vhost-user support." No D-Bus in base, no awkward out-of-tree shim to justify, no second copy of the scanout, and the whole licensing conversation about the display backend evaporates. It's a strictly stronger proposal and it's the one I'd write. The one thing that genuinely does have to come back to bhyve is *input* — the external window owns the keyboard/mouse events and the guest's xhci,tablet/virtio-input lives in bhyve. But that's a thin, well-understood channel, not a reason to route the framebuffer 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 — 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: *virglrenderer, Mesa, libepoxy and the entire GL stack stay out of the base system binary and out of bhyve's address space.* The isolation benefit is bhyve-side, not guest-side. State it that way and it's defensible. *Scope limits worth stating up front, because they'll be discovered anyway:* - *Windows guests get nothing from this.* virtio-win 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 guests get nothing initially either.* virtio_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 say 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 — 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) — turning guest 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 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 — 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 — gets you guest-driven resize, 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* — the proposal assumes "no GPL in base" is the 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 PM yi zishun <zishun.yi.dev@gmail.com> 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 > > -- Mario. [-- Attachment #2 --] <div dir="ltr"><h2 class="gmail-hP" tabindex="-1" id="gmail-avWBGd-0">---> Worth adding another graphics option to bhyve?</h2><span class="gmail-J-J5-Ji edeTZ"></span><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"></p><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><br></p><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">This is a well-framed proposal, and the answer is yes — but the version described has one process too many, and the actual cost center isn't the GPU part at all. A few things I'd push on before it goes to the list.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>The hard part is vhost-user, not virtio-gpu.</strong></p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">The proposal treats vhost-user as a given and spends its argument on the GPU. That's backwards. bhyve has no vhost-user infrastructure today, and the GPU is just the first consumer. The real work is:</p> <ul dir="ltr" class="gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-[li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-child)_ol]:pb-1 gmail-list-disc gmail-flex gmail-flex-col gmail-gap-1 gmail-pl-8 gmail-mb-3 gmail-print:block gmail-print:space-y-1"><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>Memory sharing model.</strong> vhost-user's <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">SET_MEM_TABLE</code> assumes the VMM can hand the backend an fd per memory region that the backend mmaps at a given offset. bhyve's guest memory lives behind <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">/dev/vmm/<name></code> and is set up by <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">vm_setup_memory()</code> in libvmmapi. You either pass the vmm device fd and teach the backend a FreeBSD-specific mapping path (breaking protocol compatibility, which defeats the point of using vhost-user), or you restructure guest memory allocation so it's backed by shm objects that can be shared conventionally. That second option is a non-trivial change to something quite load-bearing.</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>Capsicum.</strong> bhyve enters capability mode after device init. Connecting a unix socket by pathname won't work post-<code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">cap_enter</code>, so the socket has to be pre-opened or inherited, and <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">SCM_RIGHTS</code> handling has to be sane in cap mode. Solvable, but it constrains the CLI design (you'll want an fd-passing or pre-connect scheme, not just <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">-s N,virtio-gpu,sock=/var/run/foo.sock</code> opened lazily).</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>Eventfd/irqfd equivalents.</strong> vhost-user's kick/call fds are eventfds. FreeBSD has <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">eventfd(2)</code> now, but the backend's expectations around semantics and the <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">POLLIN</code> behaviour need verifying rather than assuming.</li></ul> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Lead with the fact that this infrastructure isn't GPU-specific.</strong> That's the argument that actually gets it merged. Once bhyve speaks vhost-user, you get virtio-fs (virtiofsd — which FreeBSD badly wants and which is a much easier sell than graphics), 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 "a generic out-of-process device backend mechanism, with GPU as the demonstrator" makes it infrastructure. Same code, very different reception on freebsd-virtualization@.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Drop bhyve from the scanout path entirely.</strong></p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">The proposal has the renderer send the framebuffer <em>back</em> to bhyve, and bhyve then dispatches it out again over D-Bus to a display program. That round trip exists in QEMU only because QEMU owns the UI — the window, the input, the multi-head config. If bhyve deliberately owns no UI (and it shouldn't), then bhyve has no business touching pixels. <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">vhost-device-gpu</code> already has a D-Bus backend; let it talk to the compositor proxy directly. bhyve keeps only the vhost-user control plane.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">That collapses your design from "vhost-user support + a new display backend + an out-of-tree D-Bus proxy" to "vhost-user support." No D-Bus in base, no awkward out-of-tree shim to justify, no second copy of the scanout, and the whole licensing conversation about the display backend evaporates. It's a strictly stronger proposal and it's the one I'd write.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">The one thing that genuinely does have to come back to bhyve is <strong>input</strong> — the external window owns the keyboard/mouse events and the guest's <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">xhci,tablet</code>/virtio-input lives in bhyve. But that's a thin, well-understood channel, not a reason to route the framebuffer through bhyve. Say so explicitly in the proposal, because someone will ask.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Tighten the security claim.</strong></p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">"Secure" as stated will get pushback, and rightly. A vhost-user backend mmaps <em>all</em> of guest memory and holds host GPU contexts — 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: <em>virglrenderer, Mesa, libepoxy and the entire GL stack stay out of the base system binary and out of bhyve's address space.</em> The isolation benefit is bhyve-side, not guest-side. State it that way and it's defensible.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Scope limits worth stating up front, because they'll be discovered anyway:</strong></p> <ul dir="ltr" class="gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-[li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-child)_ol]:pb-1 gmail-list-disc gmail-flex gmail-flex-col gmail-gap-1 gmail-pl-8 gmail-mb-3 gmail-print:block gmail-print:space-y-1"><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>Windows guests get nothing from this.</strong> virtio-win 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.</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>FreeBSD guests get nothing initially either.</strong> <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">virtio_gpu(4)</code> 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 say on a FreeBSD list, so get ahead of it: the guest-side work is a separate, later, and independently useful project.</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>virglrenderer's GL passthrough is the legacy path.</strong> The direction of travel is Venus (Vulkan) and gfxstream via rutabaga. Since <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">vhost-device-gpu</code> is built on rutabaga anyway, you inherit that — but note that rutabaga/vhost-device-gpu is Linux-shaped (memfd, eventfd, <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">/dev/dri</code> assumptions, <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">vmm-sys-util</code> coverage) and budget real time for the FreeBSD port of the <em>backend</em>, separately from the bhyve work. That port may well be larger than the bhyve side.</li></ul> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>On udmabuf's role:</strong> be precise about where it actually buys you something. It's the right primitive for blob resources with guest-memory backing (<code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">VIRTGPU_BLOB_MEM_GUEST</code>) — turning guest pages into something the host GPU can texture from without a copy. It is <em>not</em> 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 <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">EGL_EXT_image_dma_buf_import</code> 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 — it's the load-bearing assumption under the whole proposal.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Stage it.</strong> Reviewers will ask "why not do the small thing first?", and you want an answer ready:</p> <ol dir="ltr" class="gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-[li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-child)_ol]:pb-1 gmail-list-decimal gmail-flex gmail-flex-col gmail-gap-1 gmail-pl-8 gmail-mb-3 gmail-print:block gmail-print:space-y-1"><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2">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 — gets you guest-driven resize, multi-head, and a real EDID, all of which fbuf lacks. Also proves the udmabuf import path in isolation.</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2">Generic vhost-user support in bhyve, demonstrated with something boring and valuable (virtiofsd, or vhost-user-blk).</li><li class="gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words gmail-pl-2">vhost-user-gpu as a consumer of (2), with the backend ported separately.</li></ol> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">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.</p> <p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"><strong>Two things to clear early, while they're cheap:</strong> the vhost-user protocol is documented in QEMU's <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">docs/interop/vhost-user.rst</code> (and the GPU sub-protocol in <code class="gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">vhost-user-gpu.rst</code>) 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 <em>port</em> in the tree versus a <em>dependency</em> — the proposal assumes "no GPL in base" is the 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.</p><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr">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</p><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir="ltr"></p><p class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal">Mario.</p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2026 at 1:48 PM yi zishun <<a href="mailto:zishun.yi.dev@gmail.com">zishun.yi.dev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, hackers<br> <br> As the title suggests, briefly speaking, the proposed option is a<br> combination of "vhost-user-gpu" and another display backend (for<br> example, a D-Bus backend).<br> <br> Currently, bhyve has two main approaches for graphics rendering and<br> display. One is fbuf+VNC for 2D graphics, and the other is GPU<br> passthrough mainly for 3D workloads. Both approaches have some<br> obvious drawbacks. For example, fbuf is non-accelerated and VNC does<br> not support zero-copy transfer, which makes fbuf+vnc have poor<br> performance. GPU pci passthrough has excellent performance. But due to<br> its exclusive use, the host cannot access the GPU anymore, not to<br> mention supporting multiple VMs.<br> <br> I understand why these two designs exist: because bhyve is part of the<br> base system, we cannot introduce GPL-licensed software or heavy<br> graphics dependencies. So it is better, if there is an option, with a<br> minimal implementation without any heavy dependence, but still can use<br> modern graphics stack render and display capabilities, and can support<br> multiple VM.<br> <br> My motivation for this proposal stems from my GSoC work on udmabuf.<br> With the underlying zero-copy buffer sharing mechanism now in place, I<br> wanted to explore how bhyve could natively utilize it to overcome the<br> current performance bottlenecks in graphics rendering and displaying.<br> <br> For rendering, we can implement a device which presents itself to the<br> guest kernel as a virtio-gpu device, but does not process any commands<br> internally, the main virtqueue is handled by a separate userspace<br> program, vhost-user-gpu. And the device communicates to vhost-user-gpu<br> using vhost-user protocol. One implementation of vhost-user-gpu is<br> rust-vmm's vhost-device-gpu, which processes the data and sends the<br> rendered image back to QEMU/bhyve for display, and currently supports<br> gtk and dbus backend as far as I know. We can then implement a new<br> display backend, dbus backend, to dispatch the display to another<br> program, too. But we can't introduce dbus into the base system, so<br> maybe we need another out-of-tree small proxy to do the conversion.<br> <br> In conclusion, this approach dispatches the actual rendering and<br> display tasks to two separate programs. bhyve only presents itself as<br> a virtio-gpu device from the guest's point of view, and communicates<br> to the two programs internally. This option is minimal, modular, and<br> secure, leveraging the modern graphics stack to support multiple VMs<br> without requiring dedicated hardware support, while providing the<br> benefits of virtio-gpu.<br> <br> I would appreciate any feedback and discussion on the feasibility of<br> this approach. If the idea is considered worthwhile, I am willing to<br> invest the time and effort required to implement it.<br> <br> Best,<br> Zishun Yi<br> <br> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Mario.<br></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSii8khkT9wOootnddVjAoK0Td%2BCF3kVeeuUAERF7ko_QEg>