From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42127 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCF3l-0002JT-Hc for qemu-devel@nongnu.org; Wed, 12 May 2010 12:45:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCF3j-0005CF-Fr for qemu-devel@nongnu.org; Wed, 12 May 2010 12:45:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59370) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCF3i-0005C2-9G for qemu-devel@nongnu.org; Wed, 12 May 2010 12:45:22 -0400 Message-ID: <4BEADB18.4080704@redhat.com> Date: Wed, 12 May 2010 19:45:12 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1271872408-22842-1-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> <4BEACE16.9000206@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/12/2010 07:14 PM, Cam Macdonell wrote: > >> Why can't we complete initialization before exposing the card and BAR? >> Seems to be the simplest solution. >> > Looking at it more closely, you're right, the fds for shared > memory/eventfds are received in a fraction of a second, so that's why > I haven't seen any problems since the memory is mapped before the BIOS > detects and configures the device. > > We can't block on a qemu char device (in anyway I can see) so we have > to handle mapping the memory BAR in the callback function. But, we > can make the semantics that the VM ID is not set until the memory is > mapped. So if the VM ID is -1, then the memory has not been mapped > yet, reads/writes work but don't do anything useful. So the user can > detect the mapping of the memory > and it does not invalidate PCI since the BAR is always present, but > just not mapped to the shared memory. > I don't like this very much. We expose an internal qemu implementation detail, the lack of ability to complete negotiation during init, and make the device more error prone to use. However, it does make some sense if we regard the device as an HBA accessing an external memory, so it's not unreasonable. But please be sure to document this. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.