From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NphOK-000863-Io for qemu-devel@nongnu.org; Thu, 11 Mar 2010 07:21:28 -0500 Received: from [199.232.76.173] (port=45365 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NphOJ-00085o-70 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 07:21:27 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NphOI-0002cY-IN for qemu-devel@nongnu.org; Thu, 11 Mar 2010 07:21:27 -0500 Received: from mx20.gnu.org ([199.232.41.8]:36123) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NphOI-0002cQ-9X for qemu-devel@nongnu.org; Thu, 11 Mar 2010 07:21:26 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NphOG-0001bY-W0 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 07:21:25 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Date: Thu, 11 Mar 2010 12:21:13 +0000 References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <201003101741.47300.paul@codesourcery.com> <4B988EBB.1060007@redhat.com> In-Reply-To: <4B988EBB.1060007@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003111221.15142.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Cam Macdonell , qemu-devel@nongnu.org, kvm@vger.kernel.org > On 03/10/2010 07:41 PM, Paul Brook wrote: > >>> You're much better off using a bulk-data transfer API that relaxes > >>> coherency requirements. IOW, shared memory doesn't make sense for TCG > >> > >> Rather, tcg doesn't make sense for shared memory smp. But we knew that > >> already. > > > > In think TCG SMP is a hard, but soluble problem, especially when you're > > running guests used to coping with NUMA. > > Do you mean by using a per-cpu tlb? These kind of solutions are > generally slow, but tcg's slowness may mask this out. Yes. > > TCG interacting with third parties via shared memory is probably never > > going to make sense. > > The third party in this case is qemu. Maybe. But it's a different instance of qemu, and once this feature exists I bet people will use it for other things. Paul