Re: Serious doubts about Gitlab CI

[Peter Maydell]

On Tue, 30 Mar 2021 at 12:56, Thomas Huth <thuth@redhat.com> wrote:
> Right, I think we should also work more towards consolidating the QEMU
> binaries, to avoid that we have to always build sooo many target binaries
> again and again. E.g.:
>
> - Do we still need to support 32-bit hosts? If not we could
>    finally get rid of qemu-system-i386, qemu-system-ppc,
>    qemu-system-arm, etc. and just provide the 64-bit variants

We could drop qemu-system-i386 &c without dropping 32-bit host
support (except for the special case of wanting to use KVM):
32-bit host TCG happily runs the qemu-system-foo64 binary.
This does depend on the target arch having been set up so that
the 64-bit version works exactly like the 32-bit one for 32-bit
guest boards, though -- arm does this. I think x86 mostly does
except for differences like the default guest CPU type. riscv
used to have a "32 bit cpus only in the qemu-system-foo64 binary"
setup but I think that is either fixed or being fixed. There's
also the issue that it breaks existing working user commandlines,
of course.

> - Could we maybe somehow unify the targets that have both, big
>    and little endian versions? Then we could merge e.g.
>    qemu-system-microblaze and qemu-system-microblazeel etc.
>
> - Or could we maybe even build a unified qemu-system binary that
>    contains all target CPUs? ... that would also allow e.g.
>    machines with a x86 main CPU and an ARM-based board management
>    controller...

I would like to see this one day, but it's a pretty non-trivial
amount of engineering work to identify all the places where we
currently hard-code a compile-time setting about the target
architecture and make them runtime instead (in a way that doesn't
torpedo performance). "is the target CPU big-endian" is one of those...

> Also I wonder whether we could maybe even get rid of the capstone and slirp
> submodules in QEMU now ... these libraries should be available in the most
> distros by now, and otherwise people could also install them manually instead?

I suspect that's rather overoptimistic, but how widely available they
are is a question of fact that we can check.

thanks
-- PMM