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

["Daniel P. Berrangé" <berrange@redhat.com>]

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

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 :|