From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJblh-0003zh-V1 for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:52:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJbld-0003r5-Df for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:52:57 -0500 Received: from [199.232.76.173] (port=54861 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJbld-0003qw-BB for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:52:53 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:46415) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJbld-0005bx-0H for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:52:53 -0500 Received: by yxe26 with SMTP id 26so1944087yxe.4 for ; Sat, 12 Dec 2009 15:52:51 -0800 (PST) Message-ID: <4B242CD1.6030108@codemonkey.ws> Date: Sat, 12 Dec 2009 17:52:49 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <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> <4B23D585.70400@codemonkey.ws> <20091212234305.GD11611@random.random> In-Reply-To: <20091212234305.GD11611@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 11:40:21AM -0600, Anthony Liguori wrote: > >> If Spice can crash a guest, that indicates to me that Spice is >> > > That's not what I meant, anything in qemu address space can crash a > guest not just spice, even qcow2 could crash a guest, you just need to > *vaddr_in_guest_physical_space = 0 through a corrupted pointer > (corrupted pointers are very rare, gcc is very pedantic, there are > tools to trap those but they historically happened a few times in the > kernel), but when I said it I didn't in mind crashing just the guest, > I meant corrupting qemu memory itself through a different corrupted > vaddr, but it is the same risk, you could flip a bit in a buffer > header holding ext4 metadata in the guest physical address space or > flip a bit in qcow2 cluster bitmap, it doesn't make a difference both > could result in fs corruption in an extremely unlikely scenario (and > that extremely unlikely scenario is the only one where the microkernel > design would eventually payoff, where you get the graphics and mouse > hosed, but the guest sill is reachable through the network). I simply > meant spice should live in the same address space where the other > virtio drivers are living for the same reasons (performance), it's no > different. This is the bit that confuses me. VNC is not a driver. When I say it cannot crash the guest, I mean that if the VNC server makes a mistake, there may be a SEGV in qemu or it may just result in a VNC client seeing corruption. The guest does not see a bad VGA register content though or something like that. VNC is a host driver or backend service or whatever you want to call it. VNC does not have migration state because it has no guest visible state. When you compare Spice to a virtio driver, that implies to me that it does interact directly with the guest. In fact, when you have a driver passing high level commands to Spice, you would think that the status of these commands would be pending state, no? Let's say the guest sends a fill rectangle command and the Spice server sends that to a client. The Spice server needs to know when the client has finished that (maybe not, but let's assume it does) so there is now a pending request that someone has to keep track of. If you do a savevm or a live migration, or the client disconnects, the state of that request has to be saved somewhere (unless you tell the guest that the client has disconnected which is how Xen handles pv device migration). So that's what I'm trying to understand. How far does the guest's visibility go? Is the guest totally ignorant of anything other than QXL? If so, that's good, and I'm very happy about it :-) Regards, Anthony Liguori