Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori <anthony@codemonkey.ws>]

Andrea Arcangeli wrote:
> On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote:
>   
>> Spice has been closed source for a long time.  For those that have been 
>> involved with Spice development, I'm sure you understand very well why 
>> it's so wonderful, but for the rest of us, Spice didn't exist until 
>> yesterday so it's going to take a little bit for us to all understand 
>> what actually about it makes it special.
>>     
>
> I personally wasn't involved but I've seen it running with video
> fullscreen and I don't know the comparison with rdesktop as I never
> used it but I know the comparsion with vnc too well ;). It has to get
> even faster and avoid decoding the compressed stream on the server.
>   

I can run video full screen with VNC on my local lan.  In fact, that's 
the benchmark I use to do perf measurements with gtk-vnc.

I'm not saying that VNC handles video as well as Spice, I can pretty 
much guarantee that it doesn't :-)

>> If spice really needs to be able to evolve on it's own, what would it 
>> take for spice to be implementable from an external process?  What level 
>> of interaction does it need with qemu?  As long as we can prevent any 
>> device state from escaping from qemu, I'd be very interested in a model 
>> where spice lived entirely in a separate address space.
>>     
>
> Funny thing is I think it's already in a separate process! ;) (you
> know it wasn't open source until recently so...), but now that you
> mention it, I think it should be changed to not be in a separate
> process...
>
> Linux is monolithic, KVM is the monolithic way (xen is the microkernel
> slow way), I think you don't need to worry about sharing spice libs in
> the same address space. We want to make it as fast as feasible on the
> server side. A separate address space forces tlb flushes, mm switches
> and screw performance and spice is all about performance. We've
> already a pipe to connect server and client, we should try to avoid
> having two pipes as much as possible and have a single exit to qemu
> spice ring and send directly to spice client with virtio instead of
> sending to separate process that eventually sends to remote spice
> client.
>
> Like 99% of microkernel designs they're very wasteful, what good it
> does that the network is still up and running when you lost access to
> your harddisk because the sata driver crashed? Or to have access to
> sata disk but network driver crashed and you can't reach the system
> anymore. Yeah there are corner cases where they can be useful but
> those won't use linux kernel or monolitich kvm design in the first
> place and they will run dogslow and they'll demonstrate math
> correctness all software running on the bare metal with math which
> means you can't patch the software anymore until math people
> recomputes. We're not in that environment (luckily).
>
> In this case keeping it separate means the desktop remains reachable
> through network but virtual graphics card, virtual mouse and stuff
> crashed, if somebody uses qlx that means the VM has to be rebooted
> anyway.

If Spice can crash a guest, that indicates to me that Spice is 
maintaining guest visible state.  That is difficult architecturally 
because if we want to do something like introduce a secure sandbox for 
running guest visible emulation, libspice would have to be part of that 
sandbox which would seem to be difficult.

The VNC server cannot crash a guest by comparison.

FWIW, I don't see any reason why Spice couldn't be made to be separate 
from guest emulation.  I think it would just require the right 
interfacing in qemu.  I think that's purely an implementation detail.

Regards,

Anthony Liguori