From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NAOIH-0001bP-Hw
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:40:29 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NAOIC-0001YN-5V
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:40:28 -0500
Received: from [199.232.76.173] (port=50391 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NAOIB-0001Y6-Ue
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:40:23 -0500
Received: from mx1.redhat.com ([209.132.183.28]:58626)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NAOIB-00052p-HF
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 08:40:23 -0500
Message-ID: <4B02A7BD.3020001@redhat.com>
Date: Tue, 17 Nov 2009 15:40:13 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] QEMU redesigned for MPI (Message Passing Interface)
References: <747a56b80911130629q4046b4fbg400f7566997aa931@mail.gmail.com>	<4B019203.7030308@codemonkey.ws>
	<200911171220.28511.paul@codesourcery.com>
In-Reply-To: <200911171220.28511.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Victor Vasilchenko <vvasilchenko@gmail.com>, qemu-devel@nongnu.org

On 11/17/2009 02:20 PM, Paul Brook wrote:
>> What you're describing is commonly referred to as a Single System
>> Image.  It's been around for a while and can be found in software-only
>> verses (pre-Xen VirtualIron, ScaleMP) and hardware-assisted (IBM, 3leaf).
>>      
> Or better still do it at the OS level (e.g. OpenSSI).
>    

This is at best incredibly difficult since you have to cluster a huge 
program (Linux).  If the OS is closed it's impossible even to start.

If you do this at the virtualization level all you need is distributed 
shared memory for guest RAM and clustering at the qemu level.  If each 
node gets its own PCI bus it shouldn't be too difficult.

-- 
error compiling committee.c: too many arguments to function