Re: [PATCH 00/12] single-binary: link ARM and RISC-V into qemu-system

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote:
> On 8/26/2026 5:32 AM, Daniel P. Berrangé wrote:
> > I think this is probably also what leads to the increased RAM
> > usage in qemu-system-riscv64. Starting
> > 
> >   qemu-system-riscv64 -nodefaults -display none -M none
> > 
> > shows an increase in RAM usage from  17.3 to 20.7 MB which
> > is about 15% increase. NB this is dirty, private RAM per
> > process. The shared RAM pages also increase but that's not
> > a concern since they're common to all QEMU processes.
> > 
> > qemu-system-aarch64 shows a much smaller RAM increase, since
> > it only grew from 1430 classes to 1530 classes.
> > 
> > We have many more target though, so if we assume the end
> > point where every single target is unified, the the union
> > of all classes for all targets comes to approx 3600.
> > 
> > My guesstimate is that would mean a memory increase for
> > qemu-system-riscv64 from 17.3 to 39.9 MB, which is a
> > 72% increase.
> > 
> > In absolute terms this is still modest, but for deployments
> > with large VM counts  and small RAM sizes, that gets to be
> > significant.
> >
> 
> How surprising (:eye-roll:) it is that adding more code and more classes
> would result in a higher memory usage, or bigger binary size for
> qemu-system.

It is not a surprise, I'm just examining the effect.

> More seriously. If someone is concerned about it, the simple solution is
> to restrict list of targets and/or Kconfig to include less.

Building custom minimized QEMU is not a path that works for
distro vendors, as we can't tailor to distinct use cases,
so the footprint of the generic build and any impact on our
packaging is a factor I'm interested in.

The 'modules' feature came out of our work to lower the
footprint of a default "all features" QEMU build.

As long as qemu-system-$target stays around as its current
impl, it isn't a blocker. If qemu-system-$target were changed
into a symlink to qemu-system, then it becomes a critical path
problem for the distro packaging.

I think the solution long term is to further expand the use
of modules to more of the code.

> > IMHO we should make a clean break with the past. Leave
> > the existing qemu-system-$TARGET binaries being built
> > from the same pieces they are today, such that there
> > is better confidence that we are not making behavioural
> > changes to them.
> >
> 
> Funny enough, it reminded me word for word of a blog post from a
> Microsoft employee where he explained that powershell existed only
> because young developers were scared to modify original cmd shell.
> 
> Regression issues are solved with testing and good design, not by
> inventing new things.

We don't have sufficient testing, nor is the current QEMU
qemu-system-$target especially good from a design POV as
it has decades of historical baggage holding us back. The
introduction of a new binary is the ideal time to address
this long term problem. It frees us to do changes that are
otherwise impossible and to experiment with new ideas
without worrying about implications for the current binaries
and their users.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|