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

[Peter Maydell]

On 2 May 2018 at 12:58, Daniel P. Berrangé <address@hidden> 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.

> From a security POV I find it desirable for us to go in the other direction
> away from monolithic binaries that include everything. We've started that
> work with turning various pieces of QEMU into loadable modules. In the future
> we might see some pieces being moved into completely separate binaries. eg we
> could have a core QEMU binary and separate binaries for GTK, SPICE, VNC, etc
> frontends.
>
> If each target architecture could be a loadable module, it might be
> acceptable, but I wouldn't much like the idea of having every architecture
> compiled into a single binary. Distros like to build every QEMU feature,
> but users reasonably don't want to expand their attack surface by having
> all features installed, so being able to install packages for each target
> arch separately is a compelling benefit of current set of QEMU per-target
> binaries that I wouldn't want to loose.

Well, we already have issues with that where for instance
qemu-system-aarch64 has a lot of device models that the
typical KVM VM doesn't need. More modularity might help
(though we have shied away from having devices be modules
in the past).

thanks
-- PMM