On 05/03/2018 11:45 AM, Daniel P. Berrangé wrote: > 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 :-)
There are quite a few Intel boards with an Aspeed (ARM) BMC. C.
