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

[Cédric Le Goater]

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é <address@hidden> 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.