From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Date: Thu, 11 Mar 2010 12:21:13 +0000 Message-ID: <201003111221.15142.paul@codesourcery.com> References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <201003101741.47300.paul@codesourcery.com> <4B988EBB.1060007@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel@nongnu.org, Cam Macdonell , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mail.codesourcery.com ([38.113.113.100]:43021 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757763Ab0CKMVY (ORCPT ); Thu, 11 Mar 2010 07:21:24 -0500 In-Reply-To: <4B988EBB.1060007@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > 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