From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Date: Tue, 09 Mar 2010 15:41:05 -0600 Message-ID: <4B96C071.3050601@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Paul Brook , "qemu-devel@nongnu.org" , Cam Macdonell , "kvm@vger.kernel.org" To: Jamie Lokier Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:59381 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751239Ab0CIVlM (ORCPT ); Tue, 9 Mar 2010 16:41:12 -0500 Received: by gwb15 with SMTP id 15so3807626gwb.19 for ; Tue, 09 Mar 2010 13:41:11 -0800 (PST) In-Reply-To: <20100308095456.GC2869@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: 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 >