From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Date: Thu, 11 Mar 2010 08:33:31 +0200 Message-ID: <4B988EBB.1060007@redhat.com> References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <4B97D349.1030105@codemonkey.ws> <4B97D752.3080700@redhat.com> <201003101741.47300.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel@nongnu.org, Cam Macdonell , kvm@vger.kernel.org To: Paul Brook Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41208 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548Ab0CKGdx (ORCPT ); Thu, 11 Mar 2010 01:33:53 -0500 In-Reply-To: <201003101741.47300.paul@codesourcery.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. > TCG interacting with third parties via shared memory is probably never going > to make sense. > The third party in this case is qemu. -- error compiling committee.c: too many arguments to function