shm as domain to virt-viewer protocol? (Daniel P. Berrang?)

[Marc-André Lureau]

Hi David

On Fri, Mar 27, 2020 at 9:52 PM David Geise <dgeise at yahoo.com> wrote:
[..]
> I'm still just skimming & sizing things but it appears the options are:
>
> 1. Fork viewer at some level and become a downstream source code consumer; don't worry about compatibility, etc but don't expect pull requests to be accepted. I.e. add to the open-source jungle.
>
> 2. Similar to #1 but minimize the jungle-effect, try to only fork only Gtk-Spice. To support this downstream environment try to minimize changes to a hook into a separate module that implements shm I/O. Limit shm usage to guest->viewer bitmap transfers. Try to avoid memcpy's, ideally point shm directly into video card's output buffer to minimize cpu/bus overhead if possible. Alternately use RLE or other low-overhead compression. Virt-viewer project's PR acceptance possible but unlikely.
>
> 3. I haven't looked at the spice api yet, but look for the opportunity to re-impliment spice on a shm transport that would partially or entirely replace tcp for standalone scenarios. This seems unlikely unless spice has a good transport abstraction layer.
>
> 4. Look for extensibility hooks in the spice api itself which could be leveraged to implement a 'sideband' shm i/o to offload the high-bandwidth traffic (screen refresh) without changing the spice itself. Just need some way to xfer a pointer & probably a few event notifications.
>
> Your thoughts?
>

As you probably realize, this is not as simple as it may look like.
There are various approaches doing hw accelerated rendering, and
various combinations are possible with virtio-gpu, vgpu, and
passthrough, spice or not.

I think there has been some discussion about combining virtio-gpu &
passthrough to do better gpu display scraping somehow. But for now, it
is probably easier to setup some process in the guest, like
looking-glass/streaming-agent, and give that display content somehow
to the host via different means (ivshmem is probably easy, but
fragile/hackish).

At the client end, I would highly recommend to reuse the dmabuf
mechanism we have in place to share GPU buffers/display from qemu.
That dmabuf mechanism is also used by the spice client, and by vgpu,
so in theory you won't have to touch spice, or spice-gtk, or
virt-viewer. Iow, basic screen scraping could be done by modifying
guest side and qemu only. But I believe there are better plans being
discussed. I think the discussion should be moved to qemu.