On Wed, Apr 19, 2023 at 8:47 AM Michael Tokarev <m...@tls.msk.ru> wrote:
>
> Hello!
>
> TL;DR: skip to The Question: below.
>
> QEMU system mode is a whole-machine emulator which is able to run
> virtual machines of various architectures. Here's the current list
> of emulators on amd64:
>
> total 417456
> -rwxr-xr-x 1 mjt mjt 24042800 Apr 18 20:50 qemu-system-aarch64*
> -rwxr-xr-x 1 mjt mjt 12696784 Apr 18 20:50 qemu-system-alpha*
> -rwxr-xr-x 1 mjt mjt 21832624 Apr 18 20:50 qemu-system-arm*
> -rwxr-xr-x 1 mjt mjt 7887152 Apr 18 20:50 qemu-system-avr*
> -rwxr-xr-x 1 mjt mjt 8045936 Apr 18 20:50 qemu-system-cris*
> -rwxr-xr-x 1 mjt mjt 12768624 Apr 18 20:50 qemu-system-hppa*
> -rwxr-xr-x 1 mjt mjt 19455408 Apr 18 20:50 qemu-system-i386*
> -rwxr-xr-x 1 mjt mjt 14768816 Apr 18 20:50 qemu-system-loongarch64*
> -rwxr-xr-x 1 mjt mjt 9510992 Apr 18 20:50 qemu-system-m68k*
> -rwxr-xr-x 1 mjt mjt 8065904 Apr 18 20:50 qemu-system-microblaze*
> -rwxr-xr-x 1 mjt mjt 8065904 Apr 18 20:50 qemu-system-microblazeel*
> -rwxr-xr-x 1 mjt mjt 14265072 Apr 18 20:50 qemu-system-mips*
> -rwxr-xr-x 1 mjt mjt 14425424 Apr 18 20:50 qemu-system-mips64*
> -rwxr-xr-x 1 mjt mjt 16435440 Apr 18 20:50 qemu-system-mips64el*
> -rwxr-xr-x 1 mjt mjt 14256880 Apr 18 20:50 qemu-system-mipsel*
> -rwxr-xr-x 1 mjt mjt 7907664 Apr 18 20:50 qemu-system-nios2*
> -rwxr-xr-x 1 mjt mjt 12441616 Apr 18 20:50 qemu-system-or1k*
> -rwxr-xr-x 1 mjt mjt 16583760 Apr 18 20:50 qemu-system-ppc*
> -rwxr-xr-x 1 mjt mjt 17534000 Apr 18 20:50 qemu-system-ppc64*
> -rwxr-xr-x 1 mjt mjt 16277552 Apr 18 20:50 qemu-system-riscv32*
> -rwxr-xr-x 1 mjt mjt 16310288 Apr 18 20:50 qemu-system-riscv64*
> -rwxr-xr-x 1 mjt mjt 7857424 Apr 18 20:50 qemu-system-rx*
> -rwxr-xr-x 1 mjt mjt 10151728 Apr 18 20:50 qemu-system-s390x*
> -rwxr-xr-x 1 mjt mjt 12671152 Apr 18 20:50 qemu-system-sh4*
> -rwxr-xr-x 1 mjt mjt 12679344 Apr 18 20:50 qemu-system-sh4eb*
> -rwxr-xr-x 1 mjt mjt 8779312 Apr 18 20:50 qemu-system-sparc*
> -rwxr-xr-x 1 mjt mjt 13066576 Apr 18 20:50 qemu-system-sparc64*
> -rwxr-xr-x 1 mjt mjt 7986096 Apr 18 20:50 qemu-system-tricore*
> -rwxr-xr-x 1 mjt mjt 19507280 Apr 18 20:50 qemu-system-x86_64*
> -rwxr-xr-x 1 mjt mjt 7819376 Apr 18 20:50 qemu-system-x86_64-microvm*
> -rwxr-xr-x 1 mjt mjt 16713616 Apr 18 20:50 qemu-system-xtensa*
> -rwxr-xr-x 1 mjt mjt 16557808 Apr 18 20:50 qemu-system-xtensaeb*
>
> Some years ago we had a single qemu-system package which included
> all the above (actually a bit less than that, there was no arm64,
> loongarch64 or microvm parts). All this stuff requires various
> firmware packages to be useful, - such as various openbios variants,
> u-boot, x86 firmware, slof, and a few more. Due to the large list
> of dependencies, and large size of qemu-system package, I've split
> it into multiple per-architecture-family subpackages such as
> qemu-system-x86 and qemu-system-ppc. This was a trade-off between
> large number of packages and a large package with big set of deps.
> Some emulators went to qemu-system-misc subpackage (which grew
> larger with time).
>
> Later on, the external dependencies has been removed (quite some
> firmware is now built from qemu source package). And qemu started
> being used much more widely due to various debian properties being
> added such as multiarch, cross-compilation efforts, and others.
>
> More packages started using qemu-system in various ways. But due
> to this strange split, the dependencies aren't usually right, and
> it's at least difficult to make them right.
>
> For example, qemu-system provides kvm mode on many platforms,
> which does not enable CPU emulation, using native CPU and hence
> native execution speed. This mode can be used, for example, for
> isolation, for more extensive testing of packages and for many
> other things besides the traditional VM usages.
>
> So it looks like now it's a time to do something with all this.
> In the recent upload (to -experimental due to freeze), I've added
> debian naming for packages and binaries, for example there's now
> qemu-system-amd64 which is a symlink to qemu-system-x86_64 - this
> way it's possible to depend or use qemu-system-${DEB_HOST_ARCH}
> directly without having a translation table. It should already
> help some usages to find the right package and the right binary.
>
> The Question: how to rearrange the qemu-system-foo packages best?
>
> I'm thinking about having two packages here instead of many:
> it is qemu-system-native and qemu-system-emu. The first one
> will have qemu-system binaries for the native CPU/arch, like
> what qemu-system-x86 provides for x86/amd64, or qemu-system-ppc
> for powerpc/ppc64 platform, also like ubuntu-only qemu-system-s390x
> provides on s390x. And the other to contain all the emulators
> for all other platforms, and depend on -native for various
> common modules and whatnot.
>
> Note that -native does not necessary have kvm mode, since it is
> not available on all platforms, - so for some (eg sparc) it
> will still be emulated. So maybe it shouldn't actually exist
> on those platforms.
>
> Another variation is to have qemu-system-kvm package which
> provides native kvm-accelerated mode, plus qemu-system-emu
> package with anything else. qemu-system-kvm will not be available
> at all on platforms not supporting kvm (or we'll have a dummy
> package there).
In terms of naming/usage I like this suggestion of having a
qemu-system-native which would give you the best possible (even if -
as you outlined - that sometimes still is emulation) native experience
and OTOH qemu-system-emu for all the emulators.
Among other things that allows us to just always use -native in tests
where staying smaller (instead of pulling all of -emu) is helpful for
speedup and bandwidth.
But while I see the appeal of reunifying I also have often liked (and
seen people appreciate and use) this being split and explicit.
Do you consider your proposed qemu-system-native be a meta package
that depends on the right qemu-system-$arch, or an actual package with
content.
So would it be:
a)
x86: qemu-system-native -dep-> qemu-system-x86_64
ppc: qemu-system-native -dep-> qemu-system-ppc
or
b)
x86: qemu-system-native
ppc: qemu-system-native
I personally like (a) more to simplify dependencies while not breaking habits.
But that might be just me, so I wanted to ask for clarification so
everyone is on the same page here.
> And the 3rd variant is to just merge everything back into single
> qemu-system package the way it has been a few years back (now
> with greatly reduced set of dependencies but with grown size).
>
> This is - hopefully - the long-term goal, because upstream is
> slowly thinking about building qemu-system as a single binary
> which provides emulation of everything available, - obviously
> we won't try to split such binary into multiple packages :)
> But this goal seems to be too far in the future to be plannable.
>
> Without such merge into single binary, the package will be large
> (see full list of emulator binaries above), but hdd space is
> much cheaper nowadays..
>
> What do you think?
>
> /mjt
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
