Re: [Qemu-devel] release retrospective, next release timing, numbering

[Thomas Huth <thuth@redhat.com>]

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é <berrange@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...

 Thomas