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

On Sun, Aug 23, 2026 at 11:07:18PM +0800, Yonggang Luo wrote:

snip,

..to comment just on the end result for now..

> The last patch builds qemu-system (and qemu-systemw on Windows) from
> aarch64 common/system objects plus RISC-V arch objects, and installs
> qemu-system-{arm,aarch64,riscv32,riscv64} as symlinks so argv[0] still
> selects TargetInfo.
> 
> Examples:
> 
>   qemu-system -target aarch64 -M virt ...
>   qemu-system-riscv64 -M virt ...
> 
> A basename that matches no registered token falls through to the unique
> default. A combined binary with no suffix requires -target when more
> than one default TargetInfo is registered.

In testing and comparing  the new qemu-system-riscv64 symlink
to qemu-system vs the current standalone qemu-system-riscv64
binary there are some significant user visible changes.

The simplest is 'qom-list-types' went from reporting approx
770 classes, to reporting approx 1530 classes. IOW, the
qemu-system-riscv64 binary is now reporting supporting for
all the classes that were unique to arm.

The '-device help' output similarly shows a great many more
devices

TL;DR introspecting qemu-system-riscv64 is no longer accurate
wrt riscv64 capabilities. 

This is not suprising, since we register all TypeInfo meaning
we get all QOM classes present. Some of Pierricks patches try
to filter places which iterate over classes, but this does not
have full coverage.


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.


None of this means single binary is a bad idea.


My main takeaway is that we're creating uneccessary work
for ourselves by trying to make 'qemu-sytem' identical
in behaviour to qemu-system-$TARGET.

The complex filtering patches / QOM interfaces that I
found uncomfortable in Pierrick's base series are largely
around the filtering needed to simulate qemu-system-$TARGET,
and they're still incomplete. I don't have high confidence
in our ability to avoid regressions if we go route this
route.


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.


qemu-system should be built alongside qemu-system-$TARGET
and offer new semantics where it is documented as exposing
everything from all targets whenever introspected and does
not apply target type or target Kconfig filtering to inputs/
outputs. 

We still get the benefit of only building most  .o files
once, so keeping qemu-system-$TARGET is only a small
overhead in the final step of linking everything together.


qemu-system will still have the increased memory overhead
but that's fine as qemu-system-$TARGET will be unaffected.
We can tackle the memory overhead of qemu-system at our
leisure through use of loadable modules, and thus not have
that as a task to think about today.


With the clean break with the past, we also have the
ability to tackle various long standing design mistakes
present in qemu-system-$TARGET instead of carrying them
over into the new binary.

Specifically

 * -nodefaults should become the default
 
 * All CLI args should be processed in order from
   the command line, so we eliminate the nonsense
   where we process some -object, then -chardev,
   then more -object through hand crafted deps

 * No default machine type

 * Drop all legacy syntax so we only have a single
   QAPI based way of configuring.
   eg drop -hda, -hdb, -cdrom, -drive, etc
      only keeping -blockdev
   eg drop -mon, -monitor, -qmp, etc only
      keeping -object

We don't have to do all that straightaway. If we declare
qemu-system "experimental" initially we can iterate on
that intentionally breaking compat in releases, without
any impact on qemu-system-$TARGET.

Avoiding the back compat task will give us more flexibility
with the follow on work when people come to create new
machine types with heterogenous CPU targets.


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 :|