[libvirt PATCH v2 00/15] WIP/RFC: add QEMU "-display dbus" support

[Marc-André Lureau]

Hi

On Fri, Dec 3, 2021 at 8:29 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
>
> On Thu, Dec 02, 2021 at 06:23:56PM +0400, marcandre.lureau at redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau at redhat.com>
> >
> > 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@redhat.com/).
> >
> > 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.