On Thu, May 03, 2018 at 11:42:23AM +0200, Thomas Huth wrote: > On 03.05.2018 11:33, Daniel P. Berrangé wrote: > > On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: > >> On 2 May 2018 at 12:58, Daniel P. Berrangé <berra...@redhat.com> wrote: > >>> I'm curious what is the compelling benefit of having a single fat QEMU > >>> 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. > > > > 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...
Hmm, yes, even Intel x86_64 boards these days all have the management engine running an old 486 derived CPU. Perhaps one day we'll emulate a new x86 machine type with a ME :-) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
