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