From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39655 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBWDZ-00028L-H4 for qemu-devel@nongnu.org; Mon, 10 May 2010 12:52:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBWDS-0000Wl-Fv for qemu-devel@nongnu.org; Mon, 10 May 2010 12:52:32 -0400 Received: from mail-qy0-f188.google.com ([209.85.221.188]:57713) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBWDS-0000WW-DC for qemu-devel@nongnu.org; Mon, 10 May 2010 12:52:26 -0400 Received: by qyk26 with SMTP id 26so6185914qyk.19 for ; Mon, 10 May 2010 09:52:20 -0700 (PDT) Message-ID: <4BE839BD.1060502@codemonkey.ws> Date: Mon, 10 May 2010 11:52:13 -0500 From: Anthony Liguori 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> In-Reply-To: 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: Cam Macdonell Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On 05/10/2010 11:20 AM, Cam Macdonell wrote: > On Mon, May 10, 2010 at 9:38 AM, Anthony Liguori wrote: > >> On 05/10/2010 10:28 AM, Avi Kivity wrote: >> >>> On 05/10/2010 06:22 PM, Cam Macdonell wrote: >>> >>>> >>>>> >>>>>> + >>>>>> + /* if the position is -1, then it's shared memory region fd */ >>>>>> + if (incoming_posn == -1) { >>>>>> + >>>>>> + s->num_eventfds = 0; >>>>>> + >>>>>> + if (check_shm_size(s, incoming_fd) == -1) { >>>>>> + exit(-1); >>>>>> + } >>>>>> + >>>>>> + /* creating a BAR in qemu_chr callback may be crazy */ >>>>>> + create_shared_memory_BAR(s, incoming_fd); >>>>>> >>>>>> >>>>> It probably is... why can't you create it during initialization? >>>>> >>>> This is for the shared memory server implementation, so the fd for the >>>> shared memory has to be received (over the qemu char device) from the >>>> server before the BAR can be created via qemu_ram_mmap() which adds >>>> the necessary memory >>>> >>>> >>> >>> We could do the handshake during initialization. I'm worried that the >>> device will appear without the BAR, and strange things will happen. But the >>> chardev API is probably not geared for passing data during init. >>> >>> Anthony, any ideas? >>> >> Why can't we create the BAR with just normal RAM and then change it to a >> mmap()'d fd after initialization? This will be behavior would be important >> for live migration as it would let you quickly migrate preserving the memory >> contents without waiting for an external program to reconnect. >> >> Regards, >> >> Anthony Lioguori >> >> >>>> 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. >> > the memcpy() would overwrite the contents of the shared memory each > time a guest joins which would be dangerous. > I think those are reasonable semantics and is really the only way to get guest-transparent reconnect. The later is pretty critical for guest transparent live migration. >> 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. >> > Yes, I think the ack is the way to go, so the guest has to be aware of > it. Would setting a flag in the driver-specific config space be an > acceptable ack that the shared region is now mapped? > You know it's mapped because it's mapped when the pci map function returns. You don't need the guest to explicitly tell you. Regards, Anthony Liguori > Cam >