[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] release retrospective, next release timing, numbering
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] release retrospective, next release timing, numbering |
Date: |
Thu, 3 May 2018 19:02:40 +0100 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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
signature.asc
Description: PGP signature
- 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 <=
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Dr. David Alan Gilbert, 2018/05/03
- 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