index | | raw e-mail
*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 <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 > > --=20 Mario. --00000000000064e8190657aa9c5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><h2 class=3D"gmail-hP" tabindex=3D"-1" id=3D"gmail-avWBGd-= 0">---> Worth adding another graphics option to bhyve?</h2><span class= =3D"gmail-J-J5-Ji edeTZ"></span><p class=3D"gmail-font-claude-response-body= gmail-break-words gmail-whitespace-normal" dir=3D"ltr"></p><p class=3D"gma= il-font-claude-response-body gmail-break-words gmail-whitespace-normal" dir= =3D"ltr"><br></p><p class=3D"gmail-font-claude-response-body gmail-break-wo= rds gmail-whitespace-normal" dir=3D"ltr">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.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>The hard part is vhost-user, not virtio-gpu= .</strong></p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr">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:</p> <ul dir=3D"ltr" class=3D"gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-= [li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:l= ast-child)_ol]:pb-1 gmail-list-disc gmail-flex gmail-flex-col gmail-gap-1 g= mail-pl-8 gmail-mb-3 gmail-print:block gmail-print:space-y-1"><li class=3D"= gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words g= mail-pl-2"><strong>Memory sharing model.</strong> vhost-user's <code cl= ass=3D"gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-borde= r-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=3D"gm= ail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gma= il-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-p= x-1 gmail-py-px gmail-text-[0.9rem]">/dev/vmm/<name></code> and is se= t up by <code class=3D"gmail-bg-text-200/5 gmail-border gmail-border-0.5 gm= ail-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_memo= ry()</code> 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.</li><li class=3D"gmail-font-claude-response-body gmail-whitespace-no= rmal 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=3D"gmail-bg-text-200/5 gmail-border gmail-bord= er-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-w= rap 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 cl= ass=3D"gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-borde= r-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 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 <code class=3D"gma= il-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmai= l-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=3D/var/run/foo.soc= k</code> opened lazily).</li><li class=3D"gmail-font-claude-response-body g= mail-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=3D"gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-= border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rou= nded-[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 cla= ss=3D"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 v= erifying rather than assuming.</li></ul> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Lead with the fact that this infrastructure= isn't GPU-specific.</strong> 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@.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Drop bhyve from the scanout path entirely.<= /strong></p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr">The proposal has the renderer send the framebuffer = <em>back</em> 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. <code class=3D"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-d= evice-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=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr">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.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr">The one thing that genuinely does have to come back= to bhyve is <strong>input</strong> =E2=80=94 the external window owns the = keyboard/mouse events and the guest's <code class=3D"gmail-bg-text-200/= 5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-0= 00 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 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.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Tighten the security claim.</strong></p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"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 =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: <em>virglren= derer, Mesa, libepoxy and the entire GL stack stay out of the base system b= inary and out of bhyve's address space.</em> The isolation benefit is b= hyve-side, not guest-side. State it that way and it's defensible.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Scope limits worth stating up front, becaus= e they'll be discovered anyway:</strong></p> <ul dir=3D"ltr" class=3D"gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-= [li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:l= ast-child)_ol]:pb-1 gmail-list-disc gmail-flex gmail-flex-col gmail-gap-1 g= mail-pl-8 gmail-mb-3 gmail-print:block gmail-print:space-y-1"><li class=3D"= gmail-font-claude-response-body gmail-whitespace-normal gmail-break-words g= mail-pl-2"><strong>Windows guests get nothing from this.</strong> 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.</li><li class=3D"gmail-font-claude-response-bo= dy gmail-whitespace-normal gmail-break-words gmail-pl-2"><strong>FreeBSD gu= ests get nothing initially either.</strong> <code class=3D"gmail-bg-text-20= 0/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-p= x gmail-text-[0.9rem]">virtio_gpu(4)</code> 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.</li><li class=3D"gmail-font-claude-response-body gmail-whitesp= ace-normal gmail-break-words gmail-pl-2"><strong>virglrenderer's GL pas= sthrough is the legacy path.</strong> The direction of travel is Venus (Vul= kan) and gfxstream via rutabaga. Since <code class=3D"gmail-bg-text-200/5 g= mail-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 gma= il-text-[0.9rem]">vhost-device-gpu</code> is built on rutabaga anyway, you = inherit that =E2=80=94 but note that rutabaga/vhost-device-gpu is Linux-sha= ped (memfd, eventfd, <code class=3D"gmail-bg-text-200/5 gmail-border gmail-= border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-p= re-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">= /dev/dri</code> assumptions, <code class=3D"gmail-bg-text-200/5 gmail-borde= r gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whit= espace-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=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>On udmabuf's role:</strong> be precise = about where it actually buys you something. It's the right primitive fo= r blob resources with guest-memory backing (<code class=3D"gmail-bg-text-20= 0/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-p= x gmail-text-[0.9rem]">VIRTGPU_BLOB_MEM_GUEST</code>) =E2=80=94 turning gue= st 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 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 <code class=3D"gmail-bg-text= -200/5 gmail-border gmail-border-0.5 gmail-border-border-300 gmail-text-dan= ger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-p= y-px gmail-text-[0.9rem]">EGL_EXT_image_dma_buf_import</code> 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.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Stage it.</strong> Reviewers will ask "= ;why not do the small thing first?", and you want an answer ready:</p> <ol dir=3D"ltr" class=3D"gmail-[li_&]:mb-0 gmail-[li_&]:mt-1 gmail-= [li_&]:gap-1 gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:l= ast-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= =3D"gmail-font-claude-response-body gmail-whitespace-normal gmail-break-wor= ds gmail-pl-2">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.</li><li class=3D"gmail-font-claude-response-body gm= ail-whitespace-normal gmail-break-words gmail-pl-2">Generic vhost-user supp= ort in bhyve, demonstrated with something boring and valuable (virtiofsd, o= r vhost-user-blk).</li><li class=3D"gmail-font-claude-response-body gmail-w= hitespace-normal gmail-break-words gmail-pl-2">vhost-user-gpu as a consumer= of (2), with the backend ported separately.</li></ol> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr">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.</p> <p class=3D"gmail-font-claude-response-body gmail-break-words gmail-whitesp= ace-normal" dir=3D"ltr"><strong>Two things to clear early, while they'r= e cheap:</strong> the vhost-user protocol is documented in QEMU's <code= class=3D"gmail-bg-text-200/5 gmail-border gmail-border-0.5 gmail-border-bo= rder-300 gmail-text-danger-000 gmail-whitespace-pre-wrap gmail-rounded-[0.4= rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">docs/interop/vhost-user.rs= t</code> (and the GPU sub-protocol in <code class=3D"gmail-bg-text-200/5 gm= ail-border gmail-border-0.5 gmail-border-border-300 gmail-text-danger-000 g= mail-whitespace-pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmai= l-text-[0.9rem]">vhost-user-gpu.rst</code>) 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 <em>po= rt</em> in the tree versus a <em>dependency</em> =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.</p><p class=3D"gmail-font-claude-response-body gmail-break-words gmai= l-whitespace-normal" dir=3D"ltr">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</p><p class=3D"gmail-font-claude-response-body gmail-break-word= s gmail-whitespace-normal" dir=3D"ltr"></p><p class=3D"gmail-font-claude-re= sponse-body gmail-break-words gmail-whitespace-normal">Mario.</p></div><br>= <div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"= gmail_attr">On Tue, Jul 28, 2026 at 1:48=E2=80=AFPM yi zishun <<a href= =3D"mailto:zishun.yi.dev@gmail.com">zishun.yi.dev@gmail.com</a>> wrote:<= br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;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.=C2=A0 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=3D"all"></div><br><span class=3D"gmail_si= gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">Ma= rio.<br></div> --00000000000064e8190657aa9c5a--home | help