From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np7Ax-0003IA-2t for qemu-devel@nongnu.org; Tue, 09 Mar 2010 16:41:15 -0500 Received: from [199.232.76.173] (port=42172 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np7Aw-0003HO-DR for qemu-devel@nongnu.org; Tue, 09 Mar 2010 16:41:14 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np7Au-0000xz-VY for qemu-devel@nongnu.org; Tue, 09 Mar 2010 16:41:14 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:38685) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np7Au-0000xt-Hf for qemu-devel@nongnu.org; Tue, 09 Mar 2010 16:41:12 -0500 Received: by gwaa18 with SMTP id a18so3474163gwa.4 for ; Tue, 09 Mar 2010 13:41:11 -0800 (PST) Message-ID: <4B96C071.3050601@codemonkey.ws> Date: Tue, 09 Mar 2010 15:41:05 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <1267833161-25267-2-git-send-email-cam@cs.ualberta.ca> <201003072254.00040.paul@codesourcery.com> <20100308014537.GA24024@shareable.org> <852A0015-DEAB-4FEF-862B-FDE35AEC9820@suse.de> <20100308095456.GC2869@shareable.org> In-Reply-To: <20100308095456.GC2869@shareable.org> 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: Jamie Lokier Cc: "qemu-devel@nongnu.org" , Cam Macdonell , Alexander Graf , "kvm@vger.kernel.org" , Paul Brook On 03/08/2010 03:54 AM, Jamie Lokier wrote: > Alexander Graf wrote: > >> Or we could put in some code that tells the guest the host shm >> architecture and only accept x86 on x86 for now. If anyone cares for >> other combinations, they're free to implement them. >> >> Seriously, we're looking at an interface designed for kvm here. Let's >> please keep it as simple and fast as possible for the actual use case, >> not some theoretically possible ones. >> > The concern is that a perfectly working guest image running on kvm, > the guest being some OS or app that uses this facility (_not_ a > kvm-only guest driver), is later run on qemu on a different host, and > then mostly works except for some silent data corruption. > > That is not a theoretical scenario. > Hint: no matter what you do, shared memory is a hack that's going to lead to subtle failures one way or another. It's useful to support because it has some interesting academic uses but it's not a mechanism that can ever be used for real world purposes. It's impossible to support save/restore correctly. It can never be made to work with TCG in a safe way. That's why I've been advocating keeping this as simple as humanly possible. It's just not worth trying to make this fancier than it needs to be because it will never be fully correct. Regards, Anthony Liguori > Well, the bit with this driver is theoretical, obviously :-) > But not the bit about moving to a different host. > > -- Jamie > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >