From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32961 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCEC1-0003qX-1Q for qemu-devel@nongnu.org; Wed, 12 May 2010 11:49:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCEBz-0004aF-32 for qemu-devel@nongnu.org; Wed, 12 May 2010 11:49:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21040) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCEBy-0004Zz-PH for qemu-devel@nongnu.org; Wed, 12 May 2010 11:49:50 -0400 Message-ID: <4BEACE16.9000206@redhat.com> Date: Wed, 12 May 2010 18:49:42 +0300 From: Avi Kivity 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> <4BE836E5.9070106@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: qemu-devel@nongnu.org, kvm@vger.kernel.org On 05/10/2010 07:48 PM, Cam Macdonell wrote: > On Mon, May 10, 2010 at 10:40 AM, Avi Kivity wrote: > >> On 05/10/2010 06:41 PM, Cam Macdonell wrote: >> >>> >>>> What would happen to any data written to the BAR before the the handshake >>>> completed? I 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. >>> >>> >> Well, that violates PCI. You can't have a PCI device with no BAR, then have >> a BAR appear. It may work since the BAR is registered a lot faster than the >> BIOS is able to peek at it, but it's a race nevertheless. >> > Agreed. I'll get Anthony's idea up and running. It seems that is the > way forward. > What, with the separate allocation and memcpy? Or another one? Why can't we complete initialization before exposing the card and BAR? Seems to be the simplest solution. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.