[Spice-devel] Spice Protocol Missing Headers

[Frediano Ziglio]

----- Original Message -----
> From: geoff at hostfission.com
> To: "Frediano Ziglio" <fziglio at redhat.com>
> Cc: "Christophe Fergeau" <cfergeau at redhat.com>, spice-devel at lists.freedesktop.org
> Sent: Saturday, October 14, 2017 8:34:42 AM
> Subject: Re: [Spice-devel] Spice Protocol Missing Headers
> 
> On 2017-10-13 20:05, Frediano Ziglio wrote:
> >> 
> >> > I tried a few years back (spice-protocol 0.12.10) to move these code
> >> > generation scripts to spice-protocol, but this did not work out
> >> > nicely so this was reverted.
> >> 
> >> I found this too, I opted to use the spice.proto file to write my own
> >> header
> >> with the basics that were required.
> >> 
> >> >
> >> > I agree that having the initial link messages in spice/protocol.h, but
> >> > not the rest of the protocol in spice-protocol is unexpected. For now,
> >> > I
> >> > would suggest that you copy this messages.h file as you suggested, even
> >> > if that's suboptimal. I don't expect that file to change that often.
> >> >
> >> > Can you give more details about the project you are working on?
> >> 
> >> Sure :). I spend most of my time in a Linux environment for work but
> >> enjoy the odd game, so I figured I would give a Windows VM a go with
> >> VGA
> >> passthrough. It works a treat but the issue is getting a video feed
> >> back
> >> to the host, the solutions that are available IMO are substandard
> >> (ShadowPlay or Steam InHouse Streaming) as I want to have full control
> >> over the host as well, not just in games.
> >> 
> >> These services compress to h264 and stream it over the network, where
> >> it
> >> is decoded for display. Since this is all on the local host, I figured
> >> all those overheads could be bypassed by writing a windows driver that
> >> allows the host to share some memory mapped ram with the guest. Then
> >> on
> >> the guest I wrote an application that uses NvFBC to capture raw frames
> >> of the desktop and copy them into the shared memory segment.
> >> 
> >> This is why I needed a custom client, I am not using spice for the
> >> video
> >> feed, it's just there for mouse and keyboard input. The end result is
> >> outstanding, the latency is near zero and the video quality is
> >> lossless.
> > 
> > Maybe a silly question but if it's all local, don't you have a
> > physical monitor connected? NcFBC means you passed an Nvidia card to
> > the VM. Or basically you have 2 cards, one Nvidia and one Intel but
> > you want the output on the Intel one as, for instance, you don't have
> > a monitor attached to the Nvidia (this can happens on some laptops) ?
> 
> I do have a physical monitor connected, but the point is that I don't
> want to have it connected. This would also open doors for those with
> integrated graphic cards that have no outputs such as those you mention
> on laptops.
> 
> > 
> > In theory you could use a QXL device for memory sharing, copying the
> > output to its memory and send draw commands to get the output.
> > Unfortunately NvFBC system memory API handle the system buffer so
> > this means that you'll probably have 3 copy:
> > - Nvidia GPU -> system (NvFBC)
> > - system -> shared
> > - shared -> host GPU
> > But probably is not a problem for you (you possibly can avoid a
> > copy using CUDA or GL NvFBC interface).
> 
> I am already doing three copies, but I believe I can remove one if I can
> get qemu to directly map a texture buffer into the Guest VM. This way it
> would be
> 
> nVidia GPU -> System (NvFBC) -> Host GPU texture.
> 

I don't think this is possible. This would mean that the VM has access
to part of physical Host GPU but this would require that also nVidia
GPU would have access to it through DMA access which would break
passthrough security, unless nVidia GPU has another vision of physical
memory different from VM code which is currently not possible.

> I was unaware that it would be possible to map memory through QXL, I
> went the easiest route to test this proof of concept before heavily
> investing time into a more robust solution. I am new to working with
> qemu and windows drivers in general, so it has been a slow start, any
> suggestions/pointers would be very welcome.
> 
> -Geoff
> 
> 

No idea which is the best way to share memory host <-> guest.
There are some shared memory devices in Qemu but code seems not
really maintained. Of course you can write a new device.

Frediano