From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKnc-00038c-Jh for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:23:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLKnb-0003yn-GZ for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:23:40 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:59657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKnb-0003yg-9b for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:23:39 -0400 Message-ID: <50734456.7030006@weilnetz.de> Date: Mon, 08 Oct 2012 23:23:34 +0200 From: Stefan Weil MIME-Version: 1.0 References: <5072D26A.2040501@suse.de> In-Reply-To: <5072D26A.2040501@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Building QEMU with multiple CPU targets. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Peter Crosthwaite , Paolo Bonzini , John Williams , "qemu-devel@nongnu.org Developers" , "Edgar E. Iglesias" Am 08.10.2012 15:17, schrieb Andreas F=E4rber: > Hi Peter, > > Am 08.10.2012 08:39, schrieb Peter Crosthwaite: >> 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. If this works, it will also be possible to create a single "qemu" executable for all system emulations. >> >> 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= ? > Neither. The major complication is cpu.h and the per-target functions i= t > defines/declares. > > My CPUState refactoring was a step into that direction, to get a solid > QOM base class rather than macro contents inserted in the middle of the > CPUArchState struct. Adding an entry for the guest endianess to the CPU state is also needed when the emulated system includes CPUs with different endianess. Today we have conditional compilation based on TARGET_WORDS_BIGENDIAN. Regards Stefan