Hi On Fri, Dec 3, 2021 at 8:29 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Thu, Dec 02, 2021 at 06:23:56PM +0400, marcandre.lureau@xxxxxxxxxx wrote: > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > Hi, > > > > This series implements supports for the upcoming QEMU "-display dbus" support. > > Development is still in progress, but I hope to land the QEMU support early in > > 6.3 (last version posted: > > https://patchew.org/QEMU/20211009210838.2219430-1-marcandre.lureau@xxxxxxxxxx/). > > > > By default, libvirt will start a private VM bus (sharing and reusing the > > existing "vmstate" VM bus & code). > > > > The feature set should cover the needs to replace Spice as local client of choice, > > including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and arbitrary > > chardev/channels (for serial etc). > > > > The test Gtk4 client is also in progress, currently in development at > > https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such as > > zbus, require an upcoming release. virt-viewer & boxes will need a port to Gtk4 > > to make use of the shared widget. > > How is this intended to work permissions wise ? > > For the qemu:///session instance, everything is running the same user > account, so its fairly easy. > > For the qemu:///system instance, the VM's private dbus-daemon bus will be > running under a qemu:qemu user account, while the user wishing to have a > client window will be a completely different account. How will the Gtk4 > client get permission to connect to dbus-daemon ? Tbh, I haven't tried system instance yet! The per-vm bus needs to allow user connections (just like the dbus system bus). I'll add this to my todo/tocheck list for the next iteration. > Also what are the long term implications for the rest of the QEMU builtin > display backends ? > > It feels like all of VNC, SPICE, SDL and GTK backends that are currently > run in the main QEMU process, could be split off to be separate programs > using dbus. Yes, I even started a VNC server (https://gitlab.com/marcandre.lureau/qemu-display/-/tree/master/qemu-vnc), although it's really a toy compared to qemu implementation at this point. I would rather focus on an RDP server though. > > Libvirt currently represents each fo these backenjds as a <graphics> > type, and I think we'd want to continue to use that syntax even if they > were separate processes. > > ie, i would want something more like > > <graphics type="spice"> > <backend type="builtin|dbus"/> > </graphics> > > to request that libvirt spawn a SPICE server, connecting over dbus > vs built-in. Likewise for the other options. > > IOW, do we actually want to expose type="dbus" as a concept long term, > or are we better off just having it as an internal impl detail ? If we can make it an internal impl detail, that would be great (like we did for slirp-helper - even if nobody really uses it ;) > > Of course we would actually need the dbus clients to exist first... Yes, it will take a while to get there.
