[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] release retrospective, next release timing, numbering
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] release retrospective, next release timing, numbering |
Date: |
Thu, 3 May 2018 19:50:41 +0100 |
User-agent: |
Mutt/1.9.5 (2018-04-13) |
* Stefan Hajnoczi (address@hidden) 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 / address@hidden / Manchester, UK
- Re: [Qemu-devel] release retrospective, next release timing, numbering, (continued)
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Laszlo Ersek, 2018/05/02
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/05/02
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/05/02
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Thomas Huth, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Cédric Le Goater, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Cédric Le Goater, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Stefan Hajnoczi, 2018/05/03
- Re: [Qemu-devel] release retrospective, next release timing, numbering,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Stefan Hajnoczi, 2018/05/04
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Markus Armbruster, 2018/05/04
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Stefan Hajnoczi, 2018/05/04
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/05/04
Re: [Qemu-devel] release retrospective, next release timing, numbering, David Gibson, 2018/05/02
Re: [Qemu-devel] release retrospective, next release timing, numbering, Michal Suchánek, 2018/05/07
Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/05/22
Re: [Qemu-devel] release retrospective, next release timing, numbering, Philippe Mathieu-Daudé, 2018/05/28