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 05:41:30PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 8/26/2026 10:40 AM, Mark Cave-Ayland wrote:
> > 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.
> 
> To be fair I don't think Phil and Pierrick are basing their design solely
> on "we must comply to what qemu-system-$target does and has".  From what I
> understood they're trying to get the prototype out of the door to prove that
> it works, i.e. "this is clearest and most viable path we're seeing to make it
> happen". This would naturally adhere to what is already available because,
> well, it's already a proven base to build on top of.

In looking at these patches my impression is introducing "qemu-system"
as its own thing is simpler than trying to make 'qemu-system' be able
to replace & simulate qemu-system-$target, which this does.

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