From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34993 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBkYr-0002Gl-0C for qemu-devel@nongnu.org; Tue, 11 May 2010 04:11:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBkJS-0008Jg-KO for qemu-devel@nongnu.org; Tue, 11 May 2010 03:55:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6777) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBkJS-0008JU-2N for qemu-devel@nongnu.org; Tue, 11 May 2010 03:55:34 -0400 Message-ID: <4BE90D70.2050501@redhat.com> Date: Tue, 11 May 2010 10:55:28 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1271872408-22842-1-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-2-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-3-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-4-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-5-git-send-email-cam@cs.ualberta.ca> <4BE7F517.5010707@redhat.com> <4BE82623.4000905@redhat.com> <4BE82877.1040408@codemonkey.ws> <4BE83B69.4040904@redhat.com> <4BE84172.9080305@codemonkey.ws> In-Reply-To: <4BE84172.9080305@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Cam Macdonell , qemu-devel@nongnu.org, kvm@vger.kernel.org On 05/10/2010 08:25 PM, Anthony Liguori wrote: > On 05/10/2010 11:59 AM, Avi Kivity wrote: >> On 05/10/2010 06:38 PM, Anthony Liguori wrote: >>> >>>>> Otherwise, if the BAR is allocated during initialization, I would >>>>> have >>>>> to use MAP_FIXED to mmap the memory. This is what I did before the >>>>> qemu_ram_mmap() function was added. >>>> >>>> What would happen to any data written to the BAR before the the >>>> handshake completed? I think it would disappear. >>> >>> You don't have to do MAP_FIXED. You can allocate a ram area and map >>> that in when disconnected. When you connect, you create another ram >>> area and memcpy() the previous ram area to the new one. You then >>> map the second ram area in. >> >> But it's a shared memory area. Other peers could have connected and >> written some data in. The memcpy() would destroy their data. > > Why try to attempt to support multi-master shared memory? What's the > use-case? (presuming you mean multiple writers?) This is a surprising take. What's the use of a single master shared memory area? Most uses of shared memory among processes or threads are multi-master. One use case can be a shared cache among the various guests. -- error compiling committee.c: too many arguments to function