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

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On Thu, May 03, 2018 at 04:16:41PM +0200, Cédric Le Goater wrote:
> Coming back to the initial motivation that Peter pointed out, would
> the goal to be able to run vcpus of different architectures ? It would
> certainly be interesting to model a platform, specially if we can 
> synchronize the execution in some ways and find timing issues.

Yes, there is demand for heterogenous guests.  People have worked on
this problem in the past but nothing mergeable came out of it.

The main issue with a monolithic binary is that today, QEMU builds
target-specific object files (see Makefile.target).  That means the same
C source file is recompiled for each target with different #defines.  We
cannot easily link these "duplicate" object files into a single binary
because the symbol names would collide.

It would be necessary to refactor target-specific #ifdefs.  Here is a
trivial example from arch_init.c:

  #ifdef TARGET_SPARC
  int graphic_width = 1024;
  int graphic_height = 768;
  int graphic_depth = 8;
  #else
  int graphic_width = 800;
  int graphic_height = 600;
  int graphic_depth = 32;
  #endif

This can be converted into a runtime check:

  static void init_graphic_resolution(void)
  {
      if (arch_type == QEMU_ARCH_SPARC) {
          graphic_width = 1024;
          graphic_height = 768;
          graphic_depth = 8;
      } else {
          graphic_width = 800;
          graphic_height = 600;
          graphic_depth = 32;
      }
  }
  target_init(init_graphic_resolution)

I'm assuming target_init() registers functions that will be called once
arch_type has been set.

Of course the meaning of arch_type in a heterogenous system is different
since there can be multiple CPUs.  It would mean the overall board (e.g.
a SPARC machine).  But that is a separate issue and can only be
addressed once target-specific files have been eliminated.

I also want to point out that a monolithic binary is totally orthogonal
to modularity (reducing attack surface, reducing dependencies).  These
two issues do not conflict with each other.  We could have a single
"qemu-softmmu" binary that dynamically loads needed machine types, CPU,
and emulated devices.  That way the monolithic binary can do everything
but is still minimal.

So to clarify, three separate steps:

1. Get rid of target-specific #ifdefs
2a. Modular QEMU, single binary
2b. Heterogenous QEMU

2a and 2b are independent but both depend on 1.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]