From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55561 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBVj8-0005qH-2d for qemu-devel@nongnu.org; Mon, 10 May 2010 12:21:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBVj0-0002tV-Ck for qemu-devel@nongnu.org; Mon, 10 May 2010 12:21:05 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:35623) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBVj0-0002tK-9I for qemu-devel@nongnu.org; Mon, 10 May 2010 12:20:58 -0400 Received: by vws10 with SMTP id 10so220114vws.4 for ; Mon, 10 May 2010 09:20:57 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4BE82877.1040408@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> Date: Mon, 10 May 2010 10:20:50 -0600 Message-ID: From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On Mon, May 10, 2010 at 9:38 AM, Anthony Liguori wr= ote: > 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 crazy = */ >>>>> + =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 the >>> 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. =A0B= ut 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? =A0This will be behavior would be impor= tant > for live migration as it would let you quickly migrate preserving the mem= ory > 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. =A0This 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 handshak= e >> completed? =A0I think it would disappear. > > You don't have to do MAP_FIXED. =A0You can allocate a ram area and map th= at in > when disconnected. =A0When you connect, you create another ram area and > memcpy() the previous ram area to the new one. =A0You 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. > > From the guest's perspective, it's totally transparent. =A0For the backen= d, > 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