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

On 26/08/2026 13:32, Daniel P. Berrangé wrote:

> 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

I would even go as far as to suggest that we should make modules 
mandatory for qemu-system, so that devices can be loaded upon demand 
during machine construction to help keep the size down.

I'll leave whether that is through dependency tracking or via an 
explicit load directive for someone else to decide :)
>   * 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

The only problem with this is that I often get a lot of complaints that 
QEMU command lines are complicated from retro folks who just want to run 
their favourite old games. Why would they want to come up with a 
long-winded -drive command line when they can just use -hda instead?

> 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.
I agree that this is a good opportunity to explore new things without 
being tied to past decisions.


ATB,

Mark.