From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoZg3-00070P-9i for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:55:07 -0500 Received: from [199.232.76.173] (port=35282 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoZg0-0006zm-UA for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:55:04 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoZfz-00056q-FP for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:55:04 -0500 Received: from mail2.shareable.org ([80.68.89.115]:60758) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NoZfz-00056m-4t for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:55:03 -0500 Date: Mon, 8 Mar 2010 09:54:56 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Message-ID: <20100308095456.GC2869@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852A0015-DEAB-4FEF-862B-FDE35AEC9820@suse.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Cam Macdonell , Paul Brook , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" 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. -- Jamie