From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJcA6-0003wr-NY for qemu-devel@nongnu.org; Sat, 12 Dec 2009 19:18:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJcA2-0003tM-4q for qemu-devel@nongnu.org; Sat, 12 Dec 2009 19:18:10 -0500 Received: from [199.232.76.173] (port=43233 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJcA2-0003tG-0G for qemu-devel@nongnu.org; Sat, 12 Dec 2009 19:18:06 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:56305) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJcA1-0006yz-LP for qemu-devel@nongnu.org; Sat, 12 Dec 2009 19:18:05 -0500 Received: by ywh1 with SMTP id 1so1925616ywh.18 for ; Sat, 12 Dec 2009 16:18:04 -0800 (PST) Message-ID: <4B2432B9.5070203@codemonkey.ws> Date: Sat, 12 Dec 2009 18:18:01 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <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> <4B242CD1.6030108@codemonkey.ws> <20091213000439.GE11611@random.random> In-Reply-To: <20091213000439.GE11611@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 05:52:49PM -0600, Anthony Liguori wrote: > >> 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. >> > > Again, a guest crash because of qlx interaction is not what I > mean. And the reason I wasn't even thinking about this scenario is > that the kind of paravirt-driver related guest crash you are talking > about, if it can happen, can happen even if spice lib in the qemu side > lives in a separate address space. Yes, that's absolutely true. > This is why this case of pure guest > crash through qlx is not relevant to decide if to have spice lib > inside our outside of qemu address space, I think that is more about > the qlx driver and not spice on the qemu side. > The guest visible state thing has nothing to do with where it lives. Sorry if that's gotten mixed in with this discussion. The reason I care about what interacts directly with the guest is that I'd like to see us move qemu to where there's a very strong separate between guest-visible interactions and then host services to the point where the portions of guest-visible code could be run in a highly secure environment. If all of libspice would have to live in that environment because it interacts with a guest directly, that would get complicated. >> 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 >> > > I would expect it to be ignorant about anything but qlx (what else > does it need to know), but I never looked into spice before it was > open source so it's not like I'm the right person to ask for those > details ;). > :-) I'm really interested in those details. Regards, Anthony Liguori