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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> 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.

(1) may not be required, if those ifdef's are in target-specific
builds; but that does require that any target-specific stuff goes
through a well defined interface to be a loadable module and not
have a zillion overlapping symbols.

Making it loadable modules feels nice.

Dave

> Stefan


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK