From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: [PATCH v5 4/5] Inter-VM shared memory PCI device Date: Mon, 10 May 2010 10:20:50 -0600 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Anthony Liguori Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:59339 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752599Ab0EJQU5 convert rfc822-to-8bit (ORCPT ); Mon, 10 May 2010 12:20:57 -0400 Received: by vws17 with SMTP id 17so216509vws.19 for ; Mon, 10 May 2010 09:20:57 -0700 (PDT) In-Reply-To: <4BE82877.1040408@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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: >>> >>>> >>>>> + >>>>> + =A0 =A0/* if the position is -1, then it's shared memory region= fd */ >>>>> + =A0 =A0if (incoming_posn =3D=3D -1) { >>>>> + >>>>> + =A0 =A0 =A0 =A0s->num_eventfds =3D 0; >>>>> + >>>>> + =A0 =A0 =A0 =A0if (check_shm_size(s, incoming_fd) =3D=3D -1) { >>>>> + =A0 =A0 =A0 =A0 =A0 =A0exit(-1); >>>>> + =A0 =A0 =A0 =A0} >>>>> + >>>>> + =A0 =A0 =A0 =A0/* creating a BAR in qemu_chr callback may be cr= azy */ >>>>> + =A0 =A0 =A0 =A0create_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 t= he >>> server before the BAR can be created via qemu_ram_mmap() which adds >>> the necessary memory >>> >> >> >> We could do the handshake during initialization. =A0I'm worried that= the >> device will appear without the BAR, and strange things will happen. = =A0But 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 t= o a > mmap()'d fd after initialization? =A0This will be behavior would be i= mportant > 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 h= ave >>> to use MAP_FIXED to mmap the memory. =A0This is what I did before t= he >>> qemu_ram_mmap() function was added. >> >> What would happen to any data written to the BAR before the the hand= shake >> completed? =A0I think it would disappear. > > You don't have to do MAP_FIXED. =A0You can allocate a ram area and ma= p that in > when disconnected. =A0When you connect, you create another ram area a= nd > memcpy() the previous ram area to the new one. =A0You then map the se= cond ram > area in. the memcpy() would overwrite the contents of the shared memory each time a guest joins which would be dangerous. > > From the guest's perspective, it's totally transparent. =A0For the ba= ckend, > 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? Cam