From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEAl1-0003hn-Oc for qemu-devel@nongnu.org; Thu, 03 May 2018 05:42:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fEAkw-0006Cc-PI for qemu-devel@nongnu.org; Thu, 03 May 2018 05:42:35 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56698 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fEAkw-0006CU-LG for qemu-devel@nongnu.org; Thu, 03 May 2018 05:42:30 -0400 References: <062deb2a-35fc-319f-b159-3b58cbf910df@redhat.com> <20180502115844.GO3308@redhat.com> <20180503093329.GF11382@redhat.com> From: Thomas Huth Message-ID: <8af696b5-3985-ffd6-43fb-2bcbfe0d0493@redhat.com> Date: Thu, 3 May 2018 11:42:23 +0200 MIME-Version: 1.0 In-Reply-To: <20180503093329.GF11382@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" , Peter Maydell Cc: QEMU Developers , Stefan Hajnoczi , Markus Armbruster , Greg Kurz , =?UTF-8?Q?C=c3=a9dric_Le_Goater?= On 03.05.2018 11:33, Daniel P. Berrang=C3=A9 wrote: > On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: >> On 2 May 2018 at 12:58, Daniel P. Berrang=C3=A9 = wrote: >>> I'm curious what is the compelling benefit of having a single fat QEM= U >>> binary that included all archiectures at once ? >> >> The motivation is "I want to model a board with an SoC that has >> both Arm cores and Microblaze cores". One binary seems the most >> sensible way to do that, since otherwise we'd end up with some >> huge multiplication of binaries for all the possible architecture >> combinations. It also would reduce the number of times we end up >> recompiling and shipping any particular PCI device. From the >> perspective of QEMU as emulation environment, it's a nice >> simplification. >=20 > Ah that's interesting - should have known there was wierd hardware > like that out there :-) It's not that weird. A lot of "normal" machines have a service processor (aka. BMC - board management controller) on board - and this service processor is completely different to the main CPU. For example, the main CPU could be an x86 or PPC, and the service processor is an embedded ARM chip. To emulate a complete board, you'd need both CPU types in one QEMU binary. Or you need to come up with some fancy interface between two QEMU instances... Thomas