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

On 8/26/2026 11:35 AM, Pierrick Bouvier wrote:
> On 8/26/2026 5:32 AM, 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 would add that if you would focus on reviewing and helping for this
> filter problem instead of reinventing the wheel for command line, it
> would be solved by now.
> 
>>
>> 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.
> 
> More seriously. If someone is concerned about it, the simple solution is
> to restrict list of targets and/or Kconfig to include less.
> 
>>
>> 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.
>>
> 
> 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.
> 
>>
>> 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.
>>
> 
> Seems like the Genius.Artist. in the bottle just need to escape, and you
> can send us a nice series doing all this. Meanwhile, I'll try to find a
> carpet, a monkey, a princess and a suit to be the next Aladdin.
>

I was wondering why my brain connected with this, but watching "A whole
new world" video clip and lyrics made it obvious.
https://www.youtube.com/watch?v=EXTLJmYsaUQ&list=RDEXTLJmYsaUQ&start_radio=1

Now, we definitely need an AI generated version for heterogeneous
emulation :)

>>
>> With regards,
>> Daniel
> 
> Regards,
> Pierrick