From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v5 4/5] Inter-VM shared memory PCI device Date: Mon, 10 May 2010 12:25:06 -0500 Message-ID: <4BE84172.9080305@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-qy0-f183.google.com ([209.85.221.183]:35403 "EHLO mail-qy0-f183.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751248Ab0EJRZM (ORCPT ); Mon, 10 May 2010 13:25:12 -0400 Received: by qyk13 with SMTP id 13so6485157qyk.1 for ; Mon, 10 May 2010 10:25:11 -0700 (PDT) In-Reply-To: <4BE83B69.4040904@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? Regards, Anthony Liguori >> >> From the guest's perspective, it's totally transparent. For the >> backend, I'd suggest having an explicit "initialized" ack or >> something so that it knows that the data is now mapped to the guest. > > From the peers' perspective, it's non-transparent :( > > Also it doubles the transient memory requirement. > >> >> If you're doing just a ring queue in shared memory, it should allow >> disconnect/reconnect during live migration asynchronously to the >> actual qemu live migration. >> > > Live migration of guests using shared memory is interesting. You'd > need to freeze all peers on one node, disconnect, reconnect, and > restart them on the other node. >