From nobody Tue Jul 28 12:01:43 2026 X-Original-To: freebsd-virtualization@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 4h8YxN6XmBz6mgRR 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 4h8YxN2P4lz3xr0 for ; Tue, 28 Jul 2026 12:02:32 +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-84867f07d63so4549754b3a.2 for ; Tue, 28 Jul 2026 05:02:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785240141; cv=none; d=google.com; s=arc-20260327; b=N1Fv3u+quIJhf6oSMO/22vxi1hOO6Ks0ytYPf1V0DfVwoxzv5Wh12xzEbVkonq4iEO YZPW0za8mxSLTPAF465YX7JL3UoF6LoMSJujEqD4isc+QHmr3XaHdyzqf0syy6Tffn1/ lcqMrNfGXUlhd0w/YLSIGZGPHlIZn55CrdoUb0RrjgTPProwLif+ZqnUC9F6AR/yPtgL cjyci/Z14GqZ58hb1vh2vnKk2EdAzXKhajeHDryJJMl2NoSK0seIM+dP3pU1VQvm0ogM sjPOsf3KR2MAFaDrcsHc16C1yR7F8Tq8VdMeAlaH9THUWapy5B9mFhr8h62ySTZ9VEFP 6krg== 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=9tZCvV1B6p+cvON8pkUR/RolElcdwS0tqkWceK1Q+CQ=; b=kX7vJzAOzElPegCnSnFZkzcTzFs5Uukqaz9KaOGNvCRNot6+oQ1nWx8sl8A5rjky/8 j4o9BwIbHSiu9GQ7LG8sClsQsWb9pSvRNkkOmC7qW09zO5UUESUYn3rwXlzXm7+KeBEC zCkEIQkNO3Tv6ASwsA81+jTpmTnjjikbYjA23a3DAuL3zuy5WegjvTsJB63fiB3CLzQE nbSGJ8kYE71lABywgYR41oo2Q6tcxyJDW9d68zj83a/xpEO6VdED5+o8A3saFILTRTB5 1ViCTA2T4pYdmBq4eWJjV6b6FelDRKuWR1T5DVP7aodh3DlxwkC6aI2DkpG0MbD22h+C eStQ==; 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=j1xQMxEXt7RWIIgczKMc/K5FmWNVlnGZDfHpTD4T5lTFbsR2RocwsQ/9f/x5542QDw h+HMnQzfr6aVLAaheyQ4RBb7voyTFgfWUgefYsKUgNB2SbjdBR2N/vxWWm2r6NGbXA0t ryx50fEbm4TTXx7ah5/3F2GIMbf2TAPvCa7vQcm9x7tdTHIcdoaUoxS9bbouNwN0oSQm dmH+eVMATkffal7VMmpsySsdBq+2Q6vt1c+b4Nl6NpvGyMjEFVPe3t6ITeUFJpGGXitx bOJoHAd9C52uvW8W9Pw35C3yscre2czrhayyeLwxEBYdzdmZEVngy91GxlTkLmcWKb3O x6lQ== X-Forwarded-Encrypted: i=1; AHgh+RpBIgeYuB0ZRKPHHGEzWKs+9GWxnfDCLo+w6rvhDbTcMzMhOC+Q2u8jfUVOqifuPsSU1P2OScyxkO6BT4M4Dt2SoYlqFsI9@freebsd.org X-Gm-Message-State: AOJu0YwpZntSO+KoktXsrm1OG7EpIU0Fc2brvSzdrfuHblubSoAZ2SXp 1iyMIW4RxUIlZkyW6bMa7x+MGbbsfmWHX2gBOkNmuqtuvYwSAe6WbT7ssS/kE2qhxMBPXGbMkgU XX3nnf1F+rzPwHi4svBeGAtmI4AXa2ec= X-Gm-Gg: AR+sD13i9qunXWQn/YHx2cMbYOXBCfsvzYcIyvTyhxbn5HYtV45lLd0+f5akmAQVc83 ZLCwg6fIkrYsW4xz1IHIKyhQb3wCUj8WXPY5lP0wHnUA/PTBY++YQApHKRE+Ei90ICYkvrw+Foj nOv5ROY6NL7QMgRvPgAAxoIN8IAY3Q7ZyL3TBT8dA65AY1pQSjqeQ/MZgfJ1VRH3z3cIOtMLmX/ WDmj6b5NQLiSAgT4JDBbjHEj0BxCAENIUKP6Ut8IOPOSBljmuCzD1h01bxjP19GLt7sH99Dx8ed jOlMRl9DUphCQw+gsdvT3JV20m/djBI5rX4BvEqibxFXjyiORyZsEMDqyJwvIKZO6XXLFl9vfG1 GJjqPuYwPeH1rtzmyA4MN4F0qJF9BOl+K4xkqZlThe3p5PRW52ismhjmSZ9UOyg/aXUZm2FaLfK 2AfoJatYxbi08QRLE2ktZTa2/YKMLjwH5Jqf7BuBusGAnyoihbRMdYWXK1T7i3vrnl39I5lvCeF 6F5jpgWd3UBQ8VO9Y0TEpEY+n46APVE2YnvGdOVFYdBhhzXDY3VITD7wSQ6Id1B/dBLz1WsqwBe wPkWKg1SzmY= 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: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@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:c]; 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:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; 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]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42c:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-virtualization@freebsd.org]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4h8YxN2P4lz3xr0 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-- From nobody Thu Jul 30 09:51:44 2026 X-Original-To: virtualization@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 4h9kxY3h98z6n9b2 for ; Thu, 30 Jul 2026 09:51:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4h9kxX6RkXz456m for ; Thu, 30 Jul 2026 09:51:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785405104; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Afe5F1ab3s1sAzBjEmf4YM8rSComdJ52OdzuhmDqJl4=; b=A+UDd+ydzwV9k1wqnavmRTN7ECkWwBHrZT/bSQfmVrWSOont19JCt1fmJgN9x5gfPnt5P/ Hi7PLsYCJt7snrwJnDWCGr262HrCWPNtAXm8nQS34WznjqIUhpWBQiWFvOty37jVQIH7+2 lLeIwgzWCIb8GgPBzHPdLGcJOli5N4QWgs1JzKyBL29TG1UqMx0D+mUYaZNBIeMo8MPa+9 zIrEMK2YAwX+nzLuelh2mVBbdvx6mKnzokZES1klVPC/f4xv5SkFBe4CYGJICqOKv5J3y2 TNGU7NrStOZhFSz+sAy62Dwe73JF9GuOjs7uiHI8Gpinjp5EnwzVVrM8xvNkrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785405104; a=rsa-sha256; cv=none; b=I2JH1V1Mlld8AL0RXmR3WIItk17f20V+LhyOU5el4fmcJn36RrwMz8vDNrUWkWgJtQ+3Zo rq0xxDaF4fQ3XJI8ry+sYzX7ViOIXSDLMMl/dC+W/wwp4Yl4DXTTjJVdp4FwcnGoDOdzWh qmXTrYcAXopeih4HAJCJNIjNTK0PlSs2pMEOZk+yVzALcLg+f45kEy26IJklFWFBr8Yygx HPnaL2nhvjtrp71pRuxq8+u8S765K3KorYGp8TlewNQDLsUBIaGXiEqaCDrAsJlVrsCrW1 TD2v4+kph2v81zSsMcJog4Y204ErhxxWJbhEo3yUaZ5Mg37eWbo/Ld7ifiF5Gw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785405104; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Afe5F1ab3s1sAzBjEmf4YM8rSComdJ52OdzuhmDqJl4=; b=derFRmKNVVLS1vCOdzS+HPQUuz18i61Yf0UFGEc0Cin2quiZlOlXmvHt0Nfi7XJSC2nWCh DWsZ9wCLXJhErvJ33cRR73MgkTrUbUe2kYB0pSidlAwTW6QODrJb66iyfWgRF/Nf7QsE4b FygR3i4OEk6jeN5hyIJYdB2FXBw9JUqjG5pVeS/jLjVkK+pgkwUeumoHoJs9uiUV7TZ8pM 3gCCx7I/R2vyPRU3NAjZpdJynC/ZBhOvrFZEHN3UtY2uRwShjstMmdiGGtXmr8UIE2Dc95 s2O94Eec2GVuFta8oI/kGTyvTb5z0UaJbCfRjZA44TuCHJzvy/CwY20fQuWPAQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4h9kxX5PdHz1783 for ; Thu, 30 Jul 2026 09:51:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 66U9pi8v016971 for ; Thu, 30 Jul 2026 09:51:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 66U9piv7016970 for virtualization@FreeBSD.org; Thu, 30 Jul 2026 09:51:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 297159] "libuvmem.so.1" not found after update to 15.1.2 Date: Thu, 30 Jul 2026 09:51:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: weberbug@gmx.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297159 Bug ID: 297159 Summary: "libuvmem.so.1" not found after update to 15.1.2 Product: Base System Version: 15.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bhyve Assignee: virtualization@FreeBSD.org Reporter: weberbug@gmx.de After the freebsd-update from 15.1.1 to 15.1.2 vm-bhyve vms don't start any more.=20 debug=3D"yes" # cat bhyve.log ld-elf.so.1: Shared object "libuvmem.so.1" not found, required by "bhyve" OS: FreeBSD 15.1-RELEASE-p2 amd64 CPU: Intel Celeron J4005 (2) @ 1.996GHz GPU: GeminiLake [UHD Graphics 600] --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jul 30 13:16:41 2026 X-Original-To: virtualization@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 4h9qV23xRmz6nVmp for ; Thu, 30 Jul 2026 13:16:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4h9qV20p8pz3TXH for ; Thu, 30 Jul 2026 13:16:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785417402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qRIjl8wda/HIqP0XyafN//BY/A5haIDB1u9yMUDj1IQ=; b=RnechaM4heSDxHUwcwGDsDGPRF3wsP+T1utfbN+cLVIblcqRGMphz2SWlMYKh9ExMOLAqa 1d25YktTuwqDi6TcgI4vlzQ6uf2kXnnzCHdrvcxk2rVHhSh+x5uQoCRHEs4nKjKxjRxNGr Czk8ffDl9OhvRwtTU7Ki6TqiZKguWxU09mEx+5uxbrzwMkp8sqdHKiXAzgFoB2l38Y6juP SGwO2l1EHcaieJ4SbpffM2os97PDs0QO4rwHSOaB6ZC0Zg39BwNvpFnJJ0rZ1fdS+KKGj2 buiUoaUgSriFdmT3OgDy8R/J2uYkOrovjd+Qfzore60Fk5h3XMR6KLxez5ptMg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785417402; a=rsa-sha256; cv=none; b=iYNzPpzQuICPQSzNWx2Z4WvRoj6WQb0teUPZ5J938XvCLlt2RuVdPO6bwY8obwSGkUeqOZ 8rkets8a3eMVfzsMbgbYICbpESIAERTUqmgZx6jUpCyaNijmICV5kfANbI5VaR1lI9dpDj tvqQTfLjGXV8ABBh/rVHLZssdqKiTHnK2zHIHG5DAULL4FJFWkB9nJTysw/DayeKbV82E1 njH0Ij6AshX6JoGt9FclZyy02XbvL5g+wy3/FxJoku0t7Z2I4gMeLJFxNkffBHBLRiiMfm ewzN+ePUQxw8zoc144QmibjL8UGzRjHO3ymQ8OCXgnJIfGY5jQE0xHlQ913VQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785417402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qRIjl8wda/HIqP0XyafN//BY/A5haIDB1u9yMUDj1IQ=; b=IGyCUSaeaJ//JAJ5QYOYZHiXen2eiXV66jbSCX71V8LBzkYrZE3QFe4HvYVxTeueir6nGY Lk4iwIcPI5jegJnaP6wss1bU1PNLB2U58CbsySwbYXjrmiAp2fYfFM6XVH+NccBbmUVv+u YwvzSE9eYNu0Zf3y4SCieldimMAK7hiotdkOlZQaImYlrFLUQXPtLWK03pfcGegAZfHr2W BF7225zlCvSIhmdkCkDi6Q/sFROiyVTQcAwHr/3Bsgc6W2qWM3eIuRQqz8CTsJw9oOS6l+ QJMYofchFpAHf6UbGW7/EcqykmpQ537Eul6PcxMaCJsHuhuxO9yqg81dhRhyTA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4h9qV16QS9z4x for ; Thu, 30 Jul 2026 13:16:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 66UDGffW049265 for ; Thu, 30 Jul 2026 13:16:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 66UDGfCD049264 for virtualization@FreeBSD.org; Thu, 30 Jul 2026 13:16:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 297159] "libuvmem.so.1" not found after update to 15.1.2 Date: Thu, 30 Jul 2026 13:16:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297159 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jul 31 05:59:01 2026 X-Original-To: virtualization@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 4hBFkY20jBz6mW6F for ; Fri, 31 Jul 2026 05:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hBFkY16tyz3H0t for ; Fri, 31 Jul 2026 05:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785477541; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/iQHgu2j9Um4g92JP8yuXBNIn0MmEVVtljSXmxGlP7A=; b=DG6vZTfm3OAnsILEtzPV2P6dHnwMiCfqb93ZW2KiulHfnValGb6tsoEk5iEVncvi0Cvuqu u+zoEILjeUSmcSCaY59uobJ2TsMgOJleVVzwBMas5zzDov63OQ64AqMBUIlcGGK0SFnvfN R0ZBSJfiHBqGmQkTHrKrCl5mMC4a2aCQncGYzP1ekAxYc4TA1u3a5fLnoD1nwyfH6suy55 7WfCGlhmLqVZKtzGQ3QEOtDCOMjvvrcxZqPdZGwmbOZQNOjUDOBbjLnIkipfJDcjUvFeNp ppk8Qy9obc0l4qyP8kqjqN6XYKd+HH814jBmDVQitGjUE7c5syBAT+oES+mYwQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785477541; a=rsa-sha256; cv=none; b=dVoWsgeweTYjhMxnzJFaJvEhWRVS+1jQBAUmXY0PveH69RY9zUclzRBgsv0McWf4d5ttyg ZzmehbhaRcc/eIPtBQ62u92jIeX2LD1wK0XuxG1le+xtrxmqI/8E6Db2obdhydyJcqJLq0 Xi0TF4T5gdZSn3oF4M4iCyhKWvCz6CqQoHeiUJRiKV8RBcMJj/nt+Rxl7g57jRP+Zz9Qx6 4uxi/oPVGYXO6BaiDL2wI87qf+d+IBHhzwBescPS20W5hi8PA+JBQ69uNfbE3J5KPa2TEL PxR4a9OSXO2CVqy4rbe3/RyoOpARfoP+QRrk1lN0rRAqSw5AEjsK5opmvaXJeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785477541; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/iQHgu2j9Um4g92JP8yuXBNIn0MmEVVtljSXmxGlP7A=; b=WFrlq8rZd4HdyBpxECNCtapZJZy3+Sf2gsWN2cQgCxth5U4+LNkfQ5uTaI9jW9NhgGTQ8Q kQr43Lb0PyDnKm0dSvBHop9A4ll2XO+M3v2NLnAsE2jnSU+q9gwmAcguaq0afxKkE+wAbd 4l57e2d206P9LhjXKKxA8+95xh7fRDmjXDoGVmQvJV+H124uBMC/AqahTsXhQX8l7wT6vB v7afV3mzveEyCTQHStt4NrZNH2S3xf+UecsxbHM4TmpyfIoezyjfe4zHx6RB5DnOmogrzz fXgDoPSUcFHx0/t1psVd46lBykbrRBIdpkDZcm1aFQn/+LP5+GmnNbrDWnP1jA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4hBFkX6qfyzmq6 for ; Fri, 31 Jul 2026 05:59:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 66V5x0Qh080222 for ; Fri, 31 Jul 2026 05:59:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 66V5x01X080221 for virtualization@FreeBSD.org; Fri, 31 Jul 2026 05:59:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 297159] "libuvmem.so.1" not found after update to 15.1.2 Date: Fri, 31 Jul 2026 05:59:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: o.kryvulia@flex-it.com.ua X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297159 Oleksandr Kryvulia changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.kryvulia@flex-it.com.ua --- Comment #1 from Oleksandr Kryvulia --- (In reply to J=C3=BCrgen Weber from comment #0) I cannot reproduce it: # freebsd-version -kru 15.1-RELEASE-p2 15.1-RELEASE-p2 15.1-RELEASE-p2 # ldd /usr/sbin/bhyve | grep libuvmem libuvmem.so.1 =3D> /usr/lib/libuvmem.so.1 (0x25f3742bd000) # vm li NAME DATASTORE LOADER CPU MEMORY VNC AUTO STATE test-chr default uefi 2 1G - No Running (27931) test-fbsd151 default uefi 2 4G - No Stopped test-vm02 default uefi 2 4G 0.0.0.0:5900 Yes [1] Running (14339) I think /usr/lib/libuvmem.so.1 somehow lost on your system. Try to restore = it. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jul 31 08:33:44 2026 X-Original-To: virtualization@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 4hBK954cm3z6mmSt for ; Fri, 31 Jul 2026 08:33:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hBK953xn8z3lct for ; Fri, 31 Jul 2026 08:33:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785486825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H4o29ph8PeAkyBLwpz7bMhiyHdrKXJ6+OPfIthPhsuc=; b=Sg9RrUTwd4nhC91CDIzkCXXnN/ZCYF7OSEtKo6SLtCQe/+U6AiTVQIc5V9nd42SEISAPS1 iiWsVs4MWybLxWcKSJfjHLJvCMuhnf+72HhlfOkeszMFAHKwjU+A2eu7D8UB/B7B22M0W3 1FcrYsWu8VPlE1l1/1Ew8gY6mmGvO4/TMy+70Lc0vmWndI82ZE6fqjkG3WxNu5Rd58fKt1 sxtpv6qM43eMCNF0fQqfa1oaWHzNAZYVojh2UP6l0OcOFUZqzDvV/YMf4+TgYxa2RsU//Y sGW2M4q2bPI7WCs9/GN/g7WC36ne1YNJPPirLmeYb4cI/zWaSPQqydoBeBwrlQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785486825; a=rsa-sha256; cv=none; b=G1c6raPcapBtmAaTywc/rp3YjHM/onx3davzgId/vXloSXca7egiJwlxebVDP66ZQc4HF0 zFIdA+bVhPxn2r58KK0RgK65ylMdDpFKWbQjGv1x8x77CKx5C2mT6WesY5BohZJiTo0PtI gg/DjfBKNaFiFdHv5+vM9uvPxGhZlngD6EPn3QbbYHdhE5/KG7RNc0XSfx1rIANg+3cIjs 68A6wW9ptdiVa7WwPbieOdk/iRllPPgfbdYYygH0mS2J4x9gS07QCqERwpIWSoCOBH+F/1 xWcPvGvS42e32wJj73xjh9MJ5bxJ4lws2/0DiNNuRpLmLakpjX+RMvspw7DWqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785486825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H4o29ph8PeAkyBLwpz7bMhiyHdrKXJ6+OPfIthPhsuc=; b=qFPBPF2KeoZ2LXFKk1g5DoFxrFzBOOT1eegTRBj7A6s4IWlqy7RpQ3jLBqKcThX7ozqQl/ skersDHQrxlxDUVSy2B1hOYHPIRu86wMTVs3pFehMc4HMi0H0dFsS1htkx+Z+sTO+Ac/2S rxgVySxixZjLjycIhNUSajkGGE2DmsYG4gOB2oifzR1gyNuITtXp5JNf1vwm1q+XQeTF6H ihSClA0LM1wwDcc+Y5GR/0nN7f/IhIUdshX4SHWYoL9eERpUbT9vUjyJdBPkam7AfT3vNC u3Sn9WPn6SST2/+IoIvAaY2E0XN20I/GBBccXTFWVqwC/cl4rKpEWYu22qy+0g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4hBK952fGLzs8G for ; Fri, 31 Jul 2026 08:33:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 66V8XjOJ028734 for ; Fri, 31 Jul 2026 08:33:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 66V8XjKk028733 for virtualization@FreeBSD.org; Fri, 31 Jul 2026 08:33:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 297159] "libuvmem.so.1" not found after update to 15.1.2 Date: Fri, 31 Jul 2026 08:33:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: weberbug@gmx.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297159 --- Comment #2 from J=C3=BCrgen Weber --- I got libuvmem.* from another system, VMs start again. I updated more systems, libuvmem.* are still there. On one they are missing= , a 14.4.8 VM (freebsd-upgrade). The system I met the bug first, is a quite old freebsd-upgrade system, upda= ted very often, starting with 12.0, I believe. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jul 31 10:39:51 2026 X-Original-To: virtualization@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 4hBMyc1Jxwz6mynk for ; Fri, 31 Jul 2026 10:39:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hBMyb6rrSz4270 for ; Fri, 31 Jul 2026 10:39:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785494392; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D/lvBuQ6CvkkE6HpQy3b+IELbWwTgVJqCkLHQ9ErrLU=; b=y05TCTPVCuABpEGdu/Xp+MSPrLYGBSV1HfbxaBskDpsfv730jncsN2VC2eYIRSAz7BBK2W axLGRCVpVF/5hAM1gYA5bzZnX13ebpCrkl8YMYhIlnSIUNbfiXz+j8CziX5k1NMQf8mseR xEo+lV7WZLHUyFSnXvoXFfV85+dK5HJ2/4m4ct02vU8vaz5KiJIWUg20T/+kLwgh89Qhoo WY1FS7p0y0eX8z3aaQid+nr1kRZSNYZlBGnCe4intaKXQgwvyc9IvLAEzubuJsE/C1ANNd INjOFqf4xVA2kXIo38wikY3Doof/fmxqlK8CrqPyMUXgCg0leCtit8jRdaS3RA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785494392; a=rsa-sha256; cv=none; b=nsGV/McOGm2l0j1t4J+P6OKeq1hndwPlAbjWn84HW6VxWsuNFddm2muQdIU/8nMztLhmRR 2J9a/cPYUA1iBekmyyVNPOqxg6O1K/6Fx3bEtNehqZdUSkpKJQHuaRs31c95kOjez8Y3VZ OC1QCrvB4AQ6VuNOr8xy3UUJgns4kyNPY/i9q8MnmDWcv+Fzwngtk24U1Jg0j+9y6qFneU nqEkZbmh35OUmr5leUfCBhIWzdw8g/7TtvTBRBdHoWlCQrutk6BuC83D5thXMiMzBDFy7D 4sfg1SWJ9D9/FGnRGN4VsEmH/TOmKkDb0E3pSoAOr++S2dRXMGV5A4knCPzh2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785494392; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D/lvBuQ6CvkkE6HpQy3b+IELbWwTgVJqCkLHQ9ErrLU=; b=nJdJ77VPQOOXVF2cWiwPDLIMcTRWWq/JfCU5YQQkz7k4eiBX/BwfkfS97UfNNobBcW6Vpa 7aGj3H8cy2IlRLTWTMUeA2m+AZCajUgGWCzHxd7pHnGFY+TbROT2R92la4Mw6cWu2wMu7w Ba/sx+p0b9sm5x6K0hZ06LMuTXR2nCFfzEyqY65lhIe+gss2+lfsZ877hcwdBfCdET05FR 2xtxnMKK8EzUsISSWIYy5S7IeypIKvMx40FiNDYuM3D9xd8vxYrMwNzXScaeAonVmdECMp DoTJtjim0pCYWb2mu81Xp3qvpwJo0g9HLuS/X+X0KFRqnJnJ3c3qfEgODVv8SQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4hBMyb5RFqzvQQ for ; Fri, 31 Jul 2026 10:39:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 66VAdpX9024221 for ; Fri, 31 Jul 2026 10:39:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 66VAdpAt024219 for virtualization@FreeBSD.org; Fri, 31 Jul 2026 10:39:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 297159] "libuvmem.so.1" not found after update to 15.1.2 Date: Fri, 31 Jul 2026 10:39:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: o.kryvulia@flex-it.com.ua X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297159 --- Comment #3 from Oleksandr Kryvulia --- libuvmem(3) was introduced in 15.1, that's why it is missing in 14.4. --=20 You are receiving this mail because: You are the assignee for the bug.=