From nobody Tue Jul 28 12:01:43 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4h8YxN1VL5z6mg1y for ; Tue, 28 Jul 2026 12:02:32 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4h8YxH3HgPz3xqv for ; Tue, 28 Jul 2026 12:02:27 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=Bdf11+kW; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::42c as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-84e0688b7e8so2632981b3a.1 for ; Tue, 28 Jul 2026 05:02:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785240141; cv=none; d=google.com; s=arc-20260327; b=AC3xsabyVUVcfB4hv0K2WCR5dccM71SYq2TjGiV93DUNCVOtaE6NhnYd9GXWg/l+DL bgJZJcCJHKadPgUJ2u4vgx4iaLP3bmayMQXvpy8dfabmuyEy01Uuk6u5+XKbKLgoJ9NX Kb5NTwqh7d0PiTDq3V0w4+CzOu/Ru3z0MuIjKHndj62s2EXN53hFLgQ9dNNJ2F2ZlH9i KX7WPgxj0xGiXUjkRZGY3KOTotS7NYVigawvDopjGzJljUfoGH8pCKOlTAFjA1poOGQo nFdphM8ErtWbwPQ5n70mdP5EpLPCnoIT0OJzumcijpBhZQQs6mYKCs0dpuXYrtPhm+Vz CFXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=V+OG9WelGTjmzLyFYrwcDXuigxkCiOV/qmApUDXrJ/E=; fh=cxdi6siQnGsjmQQoo1evhzdtBG/YTODjuF5i1hdiKwA=; b=Qys07y1YGd4fwn5IhKlkqceYMVoPAD2KqW4wPjwOJHGaYz0tQnF2A9G2hP1aVH6ygh Mkvbs7pWdtqaDR9mCBd2kjcU+/G1Xm8knwx5NXliK1QoqoURoBUNAky/4yXghYLvOIMu Um2NBUuff8yRCTFxaaQg77wLM5vSyeyag1PrIdZshBrY3QSgLwt97gOlfPaOFJmCbFwq 9O5jbFJqPg9igr0fjTT83XdifT/OeQ6DoigXgMJUqTdRotoN9I7Kug+1592UEQPsWMN1 90j+SY4V1vXC4xYHICs30j0R2xZRMhoZ50ddjv0yRdG3SvXYloz876t+cqaIC8mt/6HO 99xA==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785240141; x=1785844941; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=V+OG9WelGTjmzLyFYrwcDXuigxkCiOV/qmApUDXrJ/E=; b=Bdf11+kWLZa8yus98CAswBQ3ur2L0CK2hU+5GKg0lIJ8mpVyLK1bwbITAYLKwMc8BL grI3MQmGSKw2RxfkleHZRtv4DVFGmWoH7TLz98jDcD9GMMxE0EEYkytrJTjrFWsIApX9 CQEDmkupECl+C4j9VFc69usP9mb4oHhH0jNm+qOdHw0p/UlwZwMtYvQKHTcHxKOWO2a9 ntxsxOSjlJgD8uYMJ7GAQFqp7JvmGy6cxOIBv5YI9GjSwo/o7ts7pqY0QOHaNBhHYU+q Y2ikQjXDAXUMAPuYD+JpHd2siE5kAJ3KfYDtMocPH2QTMhKctmk27xsACRj+zKz/oIL9 Us9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785240141; x=1785844941; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=V+OG9WelGTjmzLyFYrwcDXuigxkCiOV/qmApUDXrJ/E=; b=Ftuy4IgXfJXxuLeDjmKxcjbq0BGvKPxH4kng1e3X6lU2PDUXp0k0713leEKbxMFLPM AiB56HmAAQjPZ3YqUulaHWzMZasVEHi0ZTYhTIkiep5RYhN5g6etkFm6BJesD5xcmU+d 36pNnZmpjlsHHu1Aws/mIm+oqjC6wo9ev3xV7W5WE4HvDbD2B1QTFz3kVW1uUeDwQgYM OufFSDiy29vM15VlQ5DoX9tGC71S27CJP7vlP2rCDDhmh12IWnPGnRpC/amJCKwPaj/s tUg7et+fw4T7HT0/bMDAls7KOBEZeOJe5dSLoFag5n9tPhVMGiwHs5d2dy2afl/QusAb Tn1Q== X-Gm-Message-State: AOJu0YylsLVWiIrNdm07tI+/pXrsAdwr/qBZnJGCEWFOH6RkgD7Za8kE eVA5q1geRfNKVk7SAhmY5YvxhkosWH3KR4BbEWbX3NMoqGo6iObj2aCPeWSGt3svqb6HOUvxf0P K34s077ucchylPILkMDlidJshhud3OQPhK9ff7lk= X-Gm-Gg: AR+sD13RkChw7MENMtGedVkfdgm4TmqZ8ViA8hI5TO6G0En3scGlaXwT/ebGaa/oLcf E1P9o+54B5LqIwRmOllmEL0Zm3UFV5jgkb7HYnSGgQephj0wTvGDdqtHFdbyH3YjvQPIJi7RbN/ HCjgDWp4L8DFJrpO3V9kX/qXUENNNUuhhUCT16zltPTATQJ/kktcWna6WJr7BMR0Pn0nifd6V7A ukzO/zUGNgb6UBKjX6dkIrkgKwRwoXvx6xioT38tg69zmAxIdsbUAENcwgRmjen01/gbH/j79+Z qYSPlGgD2OrpMzyWS5RCvy50W1j7QjKkhYjudDBpzaEB+reXGsZA6HWYU2kecx50o37kwMDSi0C qSp5j9U8zR19SBomizEw7XlJ/OKj7LVWDN6ob+Hgzj7JVpV5BXASBUZ/NXTvHT7U5/Uj8y9OxHE UUMMXBSYPlyx4IbliaKdhzzRp0Q6+NuWLIwjYZhsEqEhKF2T4uvKB31e/EzMdBuqJuCVK3lgWyw X3yWqUbKRks9dpTUm+vu8XpjGK9JhE1z4PZGHgiuhbCjrVSGB4LXLdLkB4dBLUzmyhFAu5ga58x g8xlpsr5B5w= X-Received: by 2002:a05:6a00:4485:b0:84a:29a7:f650 with SMTP id d2e1a72fcca58-84e930bb1f4mr2560721b3a.0.1785240140178; Tue, 28 Jul 2026 05:02:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Tue, 28 Jul 2026 14:01:43 +0200 X-Gm-Features: AUfX_mzc6Sp2xUYHdG_frIXyeeZwMNr3ZwNHq38f-tf3u027zIJ_nDivwAKd2ps Message-ID: Subject: Re: Worth adding another graphics option to bhyve? To: yi zishun Cc: FreeBSD Hackers , freebsd-virtualization@freebsd.org Content-Type: multipart/alternative; boundary="00000000000064e8190657aa9c5a" X-Spamd-Result: default: False [-4.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4864::/56]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42c:from] X-Rspamd-Queue-Id: 4h8YxH3HgPz3xqv X-Spamd-Bar: --- --00000000000064e8190657aa9c5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> Worth adding another graphics option to bhyve? This is a well-framed proposal, and the answer is yes =E2=80=94 but the ver= sion 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 giv= en offset. bhyve's guest memory lives behind /dev/vmm/ 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 c= an 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=3D/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 =E2=80=94 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 =E2=80=94 the windo= w, 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* =E2= =80=94 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 =E2=80=94 it's full= y 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 gue= st driver for Windows. Anyone hoping this replaces passthrough for a Window= s 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 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:

  • 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 se= t up by vm_setup_memo= ry() in libvmmapi. You either pass the vmm device fd and teach the b= ackend a FreeBSD-specific mapping path (breaking protocol compatibility, wh= ich defeats the point of using vhost-user), or you restructure guest memory= allocation so it's backed by shm objects that can be shared convention= ally. That second option is a non-trivial change to something quite load-be= aring.
  • 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 ha= s to be sane in cap mode. Solvable, but it constrains the CLI design (you&#= 39;ll want an fd-passing or pre-connect scheme, not just -s N,virtio-gpu,sock=3D/var/run/foo.soc= k 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 v= erifying rather than assuming.

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