From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJVxG-0001D6-Kx for qemu-devel@nongnu.org; Sat, 12 Dec 2009 12:40:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJVxC-00015C-Qz for qemu-devel@nongnu.org; Sat, 12 Dec 2009 12:40:30 -0500 Received: from [199.232.76.173] (port=54925 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJVxC-00014Y-6O for qemu-devel@nongnu.org; Sat, 12 Dec 2009 12:40:26 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:47795) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJVxB-0002eM-4N for qemu-devel@nongnu.org; Sat, 12 Dec 2009 12:40:25 -0500 Received: by yxe26 with SMTP id 26so1791220yxe.4 for ; Sat, 12 Dec 2009 09:40:24 -0800 (PST) Message-ID: <4B23D585.70400@codemonkey.ws> Date: Sat, 12 Dec 2009 11:40:21 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211223250.129675fc@redhat.com> <4B22B035.3010601@codemonkey.ws> <20091211233158.22e6681f@redhat.com> <4B22C093.2090806@codemonkey.ws> <4B231182.1080208@codemonkey.ws> <20091212144433.GA26966@random.random> <4B23B0BE.7080408@codemonkey.ws> <20091212160626.GB26966@random.random> In-Reply-To: <20091212160626.GB26966@random.random> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: Paolo Bonzini , qemu-devel@nongnu.org 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