From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37104 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBV6j-000538-Kh for qemu-devel@nongnu.org; Mon, 10 May 2010 11:41:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBV6e-0004aC-8i for qemu-devel@nongnu.org; Mon, 10 May 2010 11:41:25 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:34483) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBV6d-0004Zv-Sy for qemu-devel@nongnu.org; Mon, 10 May 2010 11:41:20 -0400 Received: by vws10 with SMTP id 10so179866vws.4 for ; Mon, 10 May 2010 08:41:18 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4BE82623.4000905@redhat.com> 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> Date: Mon, 10 May 2010 09:41:18 -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: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Mon, May 10, 2010 at 9: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. =A0Bu= t the > chardev API is probably not geared for passing data during init. More specifically, the challenge I've found is that there is no function to tell a chardev to block and wait for the initialization data. > > Anthony, any ideas? > >> 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 handshake > completed? =A0I think it would disappear. But, the BAR isn't there until the handshake is completed. Only after receiving the shared memory fd does my device call pci_register_bar() in the callback function. So there may be a case with BAR2 (the shared memory BAR) missing during initialization. FWIW, I haven't encountered this. > > So it's a good idea to make the initialization process atomic. > > -- > error compiling committee.c: too many arguments to function > >