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

Hi Yonggang,

On 8/23/2026 8:07 AM, Yonggang Luo wrote:
> This series produces one qemu-system binary that can run ARM (32 and 64)
> and RISC-V (32 and 64, little- and big-endian TargetInfo). It follows
> Pierrick Bouvier's merged series "single-binary: implement dynamic
> filtering for machine types":
> 
>   https://patchew.org/QEMU/[email protected]/
> 
> That work added TYPE_TARGET_SPECIFIC so machines can be filtered per
> target in one process. This series uniquifies remaining per-target C
> symbols and QOM names, selects TargetInfo at runtime, and links ARM
> plus RISC-V into qemu-system.
> 
> A combined link cannot keep C symbols or QOM type names that were unique
> only because each qemu-system-$arch was a separate binary. The first
> patches remove those collisions:
> 
> - TYPE_ACCEL_CPU is a single abstract accel-cpu parent, registered once
>   next to TYPE_ACCEL. Leaf names still encode the CPU type so
>   accel_init_cpu_interfaces() can look up "<accel>-accel-"
>   CPU_RESOLVING_TYPE.
> - ARM and RISC-V virt QOM names become arm-virt and riscv-virt. The
>   boards keep -machine virt via mc->alias after the selected target is
>   applied.
> - virt ACPI helpers and RISC-V TCG crc32/crc32c/wfi helpers get an arch
>   prefix so the combined link does not need meson -D name mangling.
>   LoongArch virt_acpi_setup is renamed in the same pass.
>

Thanks for those patches, that's needed to be able to mix riscv and arm
base architectures.

> Target selection then has to work with more than one TargetInfo in the
> process:
> 
> - Register target-info-<name>-le and -be from one system
>   target-info-def.c unit, sharing arch fields. is_default follows
>   TARGET_BIG_ENDIAN so riscv/arm stay LE and ppc/s390x stay BE when
>   -target is omitted.

What is the goal here? Does it model something existing, or is it an
addition?

> - Parse -target before TargetInfo is fixed. Tokens are target_name or
>   target_name-be / -le. When -target is omitted, infer the token from
>   the program basename (strip .exe, longest registered suffix, drop a
>   trailing w for Windows GUI binaries).
> - Combined binaries cannot keep one global C symbol per arch for
>   query-cpu-definitions, dump notes, or Angel semihosting. Those
>   handlers move onto a process-wide TargetCpuOps table.
> 
> 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.
> 
> Based-on: <[email protected]>
>

thanks for posting this.

I was purposefully waiting to solve filtering issues for
machines/cpus/devices before sending any new command line switch, or
build system for single-binary to help focusing conversations. That
said, that's my personal approach and there is nothing wrong here.
Thanks for giving a glimpse to our community about what it will look like.

Regards,
Pierrick