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