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.
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.