From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLJrv-0000yT-Dx for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:24:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLJru-0007ma-48 for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:24:03 -0400 Received: from mail-oa0-f45.google.com ([209.85.219.45]:40056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLJrt-0007mE-Vs for qemu-devel@nongnu.org; Mon, 08 Oct 2012 16:24:02 -0400 Received: by mail-oa0-f45.google.com with SMTP id i18so544696oag.4 for ; Mon, 08 Oct 2012 13:24:00 -0700 (PDT) From: Anthony Liguori In-Reply-To: References: Date: Mon, 08 Oct 2012 15:23:56 -0500 Message-ID: <87obkc3e77.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Building QEMU with multiple CPU targets. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Peter Crosthwaite Cc: "Edgar E. Iglesias" , John Williams , "qemu-devel@nongnu.org Developers" , Andreas =?utf-8?Q?F=C3=A4rber?= , Paolo Bonzini Peter Maydell writes: > On 8 October 2012 07:39, Peter Crosthwaite > wrote: >> Im currently investigating the possibility of building QEMU with >> multiple CPU architectures active concurrently. That is, I have a >> binary with both an target-arm and target-microblaze and wish to run >> them as a heterogeneous multiprocessor platform. >> >> Given the recent QOM development in making CPUs just another object, >> shouldn't be possible with a bit of Makefile and configure rework to >> build qemu-system-arm+microblaze and then create machine models >> instantiating both CPU types? >> >> Are the major complications here from either a Make or QOM perspective? > > I certainly think this would be a nice feature to have, but I suspect > the makefile/QOM bits are probably the easy parts :-) > > At the moment things like the translated code cache are basically > globals and would need to be moved to be per-CPU. Also there are > still various settings that are compile time which would need to > become runtime (though we just got rid of the 'size of physical > address type' one at least). > > -- PMM It may be possible to cheat and compile the TCG + CPU code multiple times as dynamic libraries. You can then load the libraries with dlopen() with local symbol resolution. Then it's mostly just a build file exercise. Regards, Anthony Liguori