From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoaeK-0002bl-2F for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:57:24 -0500 Received: from [199.232.76.173] (port=43121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoaeJ-0002bZ-FW for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:57:23 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoaeH-0003JB-St for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:57:23 -0500 Received: from cantor.suse.de ([195.135.220.2]:47147 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NoaeH-0003Ip-HR for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:57:21 -0500 Message-ID: <4B94D80E.1060800@suse.de> Date: Mon, 08 Mar 2010 11:57:18 +0100 From: Alexander Graf 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 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Cam Macdonell , Paul Brook , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" 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. > > Well, the bit with this driver is theoretical, obviously :-) > But not the bit about moving to a different host. > I agree. Hence there should be a safety check so people can't corrupt their data silently. Alex