MAINTAINERS | 1 - accel/accel-common.c | 21 +- hw/arm/virt-acpi-build.c | 4 +- hw/arm/virt.c | 14 +- hw/core/cpu-system.c | 23 +++ hw/core/machine-qmp-cmds.c | 26 +++ hw/loongarch/virt-acpi-build.c | 6 +- hw/loongarch/virt.c | 2 +- hw/riscv/virt-acpi-build.c | 2 +- hw/riscv/virt.c | 12 +- include/accel/accel-cpu-target.h | 3 +- include/accel/accel-cpu.h | 2 + include/hw/arm/virt.h | 6 +- include/hw/loongarch/virt.h | 2 +- include/hw/riscv/virt.h | 6 +- include/qemu/target-info-impl.h | 6 + include/qemu/target-info-init.h | 29 ++- include/qemu/target-info-qom.h | 51 ++++- include/semihosting/common-semi.h | 56 +++++- meson.build | 156 ++++++++++++++- qemu-options.hx | 13 ++ stubs/dump.c | 27 --- stubs/meson.build | 2 - stubs/qmp-cpu.c | 21 -- system/vl.c | 28 ++- target-info-def.c | 61 ++++-- target-info-qom.c | 180 +++++++++++++++++- target-info.c | 32 ++++ target/arm/arch_dump.c | 8 +- target/arm/arm-qmp-cmds.c | 15 +- target/arm/common-semi-target.c | 23 ++- target/arm/meson.build | 7 +- target/i386/arch_dump.c | 8 +- target/i386/cpu-system.c | 12 +- target/i386/cpu.c | 6 +- target/loongarch/arch_dump.c | 8 +- target/loongarch/loongarch-qmp-cmds.c | 15 +- target/mips/system/mips-qmp-cmds.c | 15 +- target/ppc/arch_dump.c | 8 +- target/ppc/ppc-qmp-cmds.c | 15 +- target/riscv/arch_dump.c | 8 +- target/riscv/common-semi-target.c | 25 ++- target/riscv/cpu.c | 10 + target/riscv/helper.h | 6 +- target/riscv/meson.build | 4 +- target/riscv/riscv-qmp-cmds.c | 15 +- target/riscv/tcg/bitmanip_helper.c | 4 +- .../tcg/insn_trans/trans_privileged.c.inc | 2 +- target/riscv/tcg/insn_trans/trans_xlrbr.c.inc | 4 +- target/riscv/tcg/op_helper.c | 2 +- target/s390x/arch_dump.c | 8 +- target/s390x/cpu_models_system.c | 15 +- tests/qtest/fuzz/fuzz.c | 2 +- 53 files changed, 809 insertions(+), 228 deletions(-) delete mode 100644 stubs/dump.c delete mode 100644 stubs/qmp-cpu.c
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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
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.
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.
- 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: <20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com>
Yonggang Luo (12):
accel: use a shared TYPE_ACCEL_CPU parent
hw/riscv/virt: use unique QOM name and target filter
hw/arm/virt: use unique QOM name and target filter
hw/arm/virt: prefix ACPI helpers with arm_virt_
hw/riscv/virt: prefix ACPI helpers with riscv_virt_
hw/loongarch/virt: prefix ACPI helper with loongarch_virt_
target/riscv: uniquify TCG crc32, crc32c, and wfi helper names
target/riscv: seed cfg.big_endian from TargetInfo
target-info: register le and be TargetInfo variants
target-info: add -target and program-name selection
target-info: dispatch CPU QMP, dump, and Angel semihosting
meson: link ARM and RISC-V into qemu-system
MAINTAINERS | 1 -
accel/accel-common.c | 21 +-
hw/arm/virt-acpi-build.c | 4 +-
hw/arm/virt.c | 14 +-
hw/core/cpu-system.c | 23 +++
hw/core/machine-qmp-cmds.c | 26 +++
hw/loongarch/virt-acpi-build.c | 6 +-
hw/loongarch/virt.c | 2 +-
hw/riscv/virt-acpi-build.c | 2 +-
hw/riscv/virt.c | 12 +-
include/accel/accel-cpu-target.h | 3 +-
include/accel/accel-cpu.h | 2 +
include/hw/arm/virt.h | 6 +-
include/hw/loongarch/virt.h | 2 +-
include/hw/riscv/virt.h | 6 +-
include/qemu/target-info-impl.h | 6 +
include/qemu/target-info-init.h | 29 ++-
include/qemu/target-info-qom.h | 51 ++++-
include/semihosting/common-semi.h | 56 +++++-
meson.build | 156 ++++++++++++++-
qemu-options.hx | 13 ++
stubs/dump.c | 27 ---
stubs/meson.build | 2 -
stubs/qmp-cpu.c | 21 --
system/vl.c | 28 ++-
target-info-def.c | 61 ++++--
target-info-qom.c | 180 +++++++++++++++++-
target-info.c | 32 ++++
target/arm/arch_dump.c | 8 +-
target/arm/arm-qmp-cmds.c | 15 +-
target/arm/common-semi-target.c | 23 ++-
target/arm/meson.build | 7 +-
target/i386/arch_dump.c | 8 +-
target/i386/cpu-system.c | 12 +-
target/i386/cpu.c | 6 +-
target/loongarch/arch_dump.c | 8 +-
target/loongarch/loongarch-qmp-cmds.c | 15 +-
target/mips/system/mips-qmp-cmds.c | 15 +-
target/ppc/arch_dump.c | 8 +-
target/ppc/ppc-qmp-cmds.c | 15 +-
target/riscv/arch_dump.c | 8 +-
target/riscv/common-semi-target.c | 25 ++-
target/riscv/cpu.c | 10 +
target/riscv/helper.h | 6 +-
target/riscv/meson.build | 4 +-
target/riscv/riscv-qmp-cmds.c | 15 +-
target/riscv/tcg/bitmanip_helper.c | 4 +-
.../tcg/insn_trans/trans_privileged.c.inc | 2 +-
target/riscv/tcg/insn_trans/trans_xlrbr.c.inc | 4 +-
target/riscv/tcg/op_helper.c | 2 +-
target/s390x/arch_dump.c | 8 +-
target/s390x/cpu_models_system.c | 15 +-
tests/qtest/fuzz/fuzz.c | 2 +-
53 files changed, 809 insertions(+), 228 deletions(-)
delete mode 100644 stubs/dump.c
delete mode 100644 stubs/qmp-cpu.c
--
2.52.0.windows.1
On Sun, Aug 23, 2026 at 11:07:18PM +0800, 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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/ Do you have a public git branch somewhere with this series ? I'm having trouble getting either this series or Pierrick's to cleanly apply at any point to test it. 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 :|
The github branch I built locally
https://github.com/lygstate/qemu/tree/s11.1-riscv-arm
On Tue, Aug 25, 2026 at 11:42 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
>
> On Sun, Aug 23, 2026 at 11:07:18PM +0800, 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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
>
> Do you have a public git branch somewhere with this series ? I'm
> having trouble getting either this series or Pierrick's to cleanly
> apply at any point to test it.
>
>
> 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 :|
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
On Tue, Aug 25, 2026 at 11:42 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
>
> On Sun, Aug 23, 2026 at 11:07:18PM +0800, 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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
>
> Do you have a public git branch somewhere with this series ? I'm
> having trouble getting either this series or Pierrick's to cleanly
> apply at any point to test it.
https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/
you can use git patchew do it
git fetch https://github.com/patchew-project/qemu tags/patchew/
20260823150731.896-1-luoyonggang@gmail.com
a>
>
> 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 :|
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
On Wed, Aug 26, 2026 at 12:55:09AM +0800, Yonggang Luo wrote: > On Tue, Aug 25, 2026 at 11:42 PM Daniel P. Berrangé <berrange@redhat.com> > wrote: > > > > On Sun, Aug 23, 2026 at 11:07:18PM +0800, 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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/ > > > > Do you have a public git branch somewhere with this series ? I'm > > having trouble getting either this series or Pierrick's to cleanly > > apply at any point to test it. > > > https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/ > > you can use git patchew do it > > git fetch https://github.com/patchew-project/qemu tags/patchew/ > 20260823150731.896-1-luoyonggang@gmail.com Oh yes, thanks for the reminder about patchew, that does the job. 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 :|
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/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
>
> 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: <20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com>
>
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
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 :|
On Wed, Aug 26, 2026 at 2:33 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > 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. I am not sure about this. Overall most (not all) of the complexity of command-line processing and legacy arguments is kept at bay, and contained within board code - and boards do not have to support it. The complexity that is left is tied to -drive, mostly due to differences between hot-unplug in -drive and -blockdev. And honestly I'd be very much opposed to dropping -drive because using -blockdev correctly is *extremely* hard and barely documented. If we want a clean break, we need to drop the command line completely and just have a QMP monitor on stdin/stdout (https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence). Start small adding just accel-new and machine-new, and add QMP equivalents of command line objects as needed. That said, I understand that this is just an idea and not the crux of the disagreement. Paolo
On Fri, Aug 28, 2026 at 1:59 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On Wed, Aug 26, 2026 at 2:33 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
> > 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.
Paolo also said keeping qemu-system-riscv64 as a real binary, not a
symlink, is a valid objection.
v2 already takes that part:
https://patchew.org/QEMU/20260826184229.1145-1-luoyonggang@gmail.com/
What v2 changed relative to v1:
- qemu-system-$TARGET is still a separately linked binary. qemu-system
is extra, from the ARM + RISC-V union. v1 installed
qemu-system-{arm,aarch64,riscv32,riscv64} as symlinks; that is gone.
- Bare qemu-system always requires -target. There is no unique-
TargetInfo fallback.
- Dropped little- and big-endian TargetInfo variants from this series.
One TargetInfo per target_name. Endian variants are later work.
- No qemu-systemw for the combined binary, so a Windows GUI twin does
not block enabling modules later.
qemu-system -target aarch64 -M virt ...
qemu-system-riscv64 -M virt ...
The per-target binaries should keep the same QOM list and RSS as today.
The extra RAM and incomplete filtering only apply to the extra
qemu-system binary.
v2 still uses -target and TYPE_TARGET_SPECIFIC on that combined binary.
It does not drop legacy CLI, and it does not mark qemu-system
experimental. I treated those as later work, not required to stop
replacing qemu-system-$TARGET with a symlink.
The v2 still based on TYPE_TARGET_SPECIFIC changes from Pierrick Bouvier,
it's a great changes that
get target-info-def.c to be generic, so maybe we can review the v2 version
instead.
The v2 version can be merged without affecting existing qemu-system-*. if
something wrong v2, tell me in v2 patches.
>
> I am not sure about this. Overall most (not all) of the complexity of
> command-line processing and legacy arguments is kept at bay, and
> contained within board code - and boards do not have to support it.
>
> The complexity that is left is tied to -drive, mostly due to
> differences between hot-unplug in -drive and -blockdev. And honestly
> I'd be very much opposed to dropping -drive because using -blockdev
> correctly is *extremely* hard and barely documented.
>
> If we want a clean break, we need to drop the command line completely
> and just have a QMP monitor on stdin/stdout
> (https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence).
> Start small adding just accel-new and machine-new, and add QMP
> equivalents of command line objects as needed.
>
> That said, I understand that this is just an idea and not the crux of
> the disagreement.
>
> Paolo
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
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.
>
> With regards,
> Daniel
Regards,
Pierrick
On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: > On 8/26/2026 5:32 AM, Daniel P. Berrangé wrote: > > 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. It is not a surprise, I'm just examining the effect. > More seriously. If someone is concerned about it, the simple solution is > to restrict list of targets and/or Kconfig to include less. Building custom minimized QEMU is not a path that works for distro vendors, as we can't tailor to distinct use cases, so the footprint of the generic build and any impact on our packaging is a factor I'm interested in. The 'modules' feature came out of our work to lower the footprint of a default "all features" QEMU build. As long as qemu-system-$target stays around as its current impl, it isn't a blocker. If qemu-system-$target were changed into a symlink to qemu-system, then it becomes a critical path problem for the distro packaging. I think the solution long term is to further expand the use of modules to more of the code. > > 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. We don't have sufficient testing, nor is the current QEMU qemu-system-$target especially good from a design POV as it has decades of historical baggage holding us back. The introduction of a new binary is the ideal time to address this long term problem. It frees us to do changes that are otherwise impossible and to experiment with new ideas without worrying about implications for the current binaries and their users. 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 :|
On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: > 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. This kind of comment is not productive and disrepectful to the time reviewers in invest in looking at the proposed patches. Please stop this. 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 :|
On 8/27/2026 2:44 AM, Daniel P. Berrangé wrote: > On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: >> 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. > > This kind of comment is not productive and disrepectful to the time > reviewers in invest in looking at the proposed patches. Please stop > this. > The only person wasting everyone's time here is YOU. There is not a single person who came on any thread to say "I agree with you Daniel", while several posted or commented they were ok with the approach here. Project is QEMU, not Daniel's EMU. Whether or not you like my joke above does not matter, just focus on the first sentence of it. Send a series implementing your view instead of long emails "I said so" on other people series. And go back to the lamp until it's ready. > With regards, > Daniel Regards, Pierrick
On Thu, Aug 27, 2026 at 6:32 PM Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> wrote: > > On 8/27/2026 2:44 AM, Daniel P. Berrangé wrote: > > On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: > >> 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. > > > > This kind of comment is not productive and disrepectful to the time > > reviewers in invest in looking at the proposed patches. Please stop > > this. > > > > The only person wasting everyone's time here is YOU. > There is not a single person who came on any thread to say "I agree with > you Daniel", while several posted or commented they were ok with the > approach here. > > Project is QEMU, not Daniel's EMU. Whoa whoa. Sometimes people don't reply not because they disagree, but because they trust the people involved to resolve the problem. Let me remind you of the discussion we had about -fms-bitfields and how it was resolved amicably and profitably. I will read the thread and try to understand what's going on but from the first impression, "wanting to keep the single-system qemu-system-riscv64 instead of a symlink" is a valid objection. In fact, with the proviso that I haven't read the code, I don't see why you'd want *anything else*. And especially, "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" is not a good way to conduct a discussion. This project was extremely complex and some disagreements are normal, but overall I would say it has received support from the community for years. It is close to the finish line, let's not forget all the collaboration so far. Paolo
On 8/27/2026 10:48 AM, Paolo Bonzini wrote: > On Thu, Aug 27, 2026 at 6:32 PM Pierrick Bouvier > <pierrick.bouvier@oss.qualcomm.com> wrote: >> >> On 8/27/2026 2:44 AM, Daniel P. Berrangé wrote: >>> On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: >>>> 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. >>> >>> This kind of comment is not productive and disrepectful to the time >>> reviewers in invest in looking at the proposed patches. Please stop >>> this. >>> >> >> The only person wasting everyone's time here is YOU. >> There is not a single person who came on any thread to say "I agree with >> you Daniel", while several posted or commented they were ok with the >> approach here. >> >> Project is QEMU, not Daniel's EMU. > > Whoa whoa. > I apologize to Daniel, and other people on this thread for resorting to sarcasm in this situation, and personally mention Daniel in my answer. It stems from the fact that it's not the first time Daniel come on a thread to push a view (that might be wrong) and don't listen to other's people opinion, or leave the conversation when he has no more arguments or discover he's wrong. I'm not the first one to discover this, and it's a topic that came from multiple people I met. I invite anyone to tell me publicly it's in my head, and that it is wrong. Neuroatypicality does *not* justify passive-aggressive behavior. We have many examples in the community of neuroatypical members that still are open to different opinions, and don't act this way. I don't see it as collaboration but as "I've been there before you, so do what I say", which has absolutely no technical basis, like it should in our community. I don't know how to fix the behavior described above, but since Peter and you manage the community, I'm open to discuss about it. I'm also open to hear "Pierrick, you are the problem", apologize and accept it, learn and keep on working with all of you. In all cases, it does not justify any personal attack, so sorry again about this, it won't happen again. > Sometimes people don't reply not because they disagree, but because > they trust the people involved to resolve the problem. > We presented a plan a year ago, for which multiple people have been supportive in general. Now we are close to having a single binary upstream, we have Daniel coming last minute and asking to solve issues we are not at yet. I feel it's not helping us, and simply blocking work. Daniel's main concern (correct me if I'm wrong), is that we might introduce regressions by introducing a -target option, and filtering on QOM types. I don't see where it is a problem. Even if a mistake comes, it takes a single patch to fix the missing type. So I asked several times to postpone his desire to refactor things, but he keeps on coming and blocking work going any different direction. I have no problem with anyone deciding to refactor the QEMU command line, but it's a different problem from what we are doing now. We just want to provide a first version upstream mixing at least two base architectures, and providing exact same behavior than existing binaries. > Let me remind you of the discussion we had about -fms-bitfields and > how it was resolved amicably and profitably. > I really appreciated this exchange with you. Even if I was a newcomer, you explained where you disagreed, but accepted a different answer. Then we iterated to prove that existing struct layout were not impacted, and we both observed it was safe to remove this option. I felt like we both worked toward a goal, and not that you pushed your personal vision without any technical basis. > I will read the thread and try to understand what's going on but from > the first impression, "wanting to keep the single-system > qemu-system-riscv64 instead of a symlink" is a valid objection. In > fact, with the proviso that I haven't read the code, I don't see why > you'd want *anything else*. > There are other threads you might want to take a look at to have the full picture: - 20260821235112.193381-1-pierrick.bouvier@oss.qualcomm.com - 20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com - https://patchew.org/QEMU/20260514172303.1484273-1-pierrick.bouvier@oss.qualcomm.com/ (v2-v4 for a concrete example of pushing things in a direction without listening to arguments, and not follow up when discovering things are wrong, thus blocking work). > And especially, "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" is not a good way to conduct a > discussion. > I apologize again for sarcasm. > This project was extremely complex and some disagreements are normal, > but overall I would say it has received support from the community for > years. It is close to the finish line, let's not forget all the > collaboration so far. > At this point, I don't see the finish line coming anytime soon. We are stuck in a situation where we now might have to design a whole new command line from scratch, for a reason I ignore. Meanwhile, we fix downstream regressions on single-binary, and it's exhausting. I would appreciate if you, Peter, or Markus, could decide something here, and explicitly say: - let's go with original plan, and just introduce -target option and call it a day for now. CLI refactoring can be initiated in parallel. - let's change the original plan, and Daniel (or anyone willing to) can design a new cli for this binary. I'm personally out of this. I would also add that a new cli is completely unrelated to single-binary/heterogeneous, and it could already be designed/experimented with a single target, without impacting current work. > Paolo > Regards, Pierrick
On 8/27/26 21:58, Pierrick Bouvier wrote: > On 8/27/2026 10:48 AM, Paolo Bonzini wrote: >> Whoa whoa. >> > > I apologize to Daniel, and other people on this thread for resorting to > sarcasm in this situation, and personally mention Daniel in my answer. > > It stems from the fact that it's not the first time Daniel come on a > thread to push a view (that might be wrong) and don't listen to other's > people opinion, or leave the conversation when he has no more arguments > or discover he's wrong. I'm not the first one to discover this, and it's > a topic that came from multiple people I met. I invite anyone to tell me > publicly it's in my head, and that it is wrong. Please stop. Just stop. "It came from multiple people" never ends well. I have my own disagreements with Daniel, which is no surprise since I've known him at work for over 15 years. In fact, we probably had a couple just this week, though that's fortunately above average. We have different personalities, we come from different cultural backgrounds. We are still able to respect each other and I seek his opinion even if (or sometimes because) I know it'll be different and make things harder for me. :) >> Sometimes people don't reply not because they disagree, but because >> they trust the people involved to resolve the problem. > > We presented a plan a year ago, for which multiple people have been > supportive in general. Now we are close to having a single binary > upstream, we have Daniel coming last minute and asking to solve issues > we are not at yet. I feel it's not helping us, and simply blocking work. > > Daniel's main concern (correct me if I'm wrong), is that we might > introduce regressions by introducing a -target option, and filtering on > QOM types. I'll briefly touch the technical part. As it was explained, the problem is really just in the use of symlinks for aarch64 and riscv64 binaries. All that Daniel is *asking for* is to split the experimental part from the existing one. Did he go on a tangent on what else he'd like from the experimental part? Yes, but that's simply a justification for why it's better to keep it split. > I have no problem with anyone deciding to refactor the QEMU command > line, but it's a different problem from what we are doing now. > We just want to provide a first version upstream mixing at least two > base architectures, and providing exact same behavior than existing > binaries. Yes, and that's fine. >> Let me remind you of the discussion we had about -fms-bitfields and >> how it was resolved amicably and profitably. > > I really appreciated this exchange with you. Even if I was a newcomer, > you explained where you disagreed, but accepted a different answer. Then > we iterated to prove that existing struct layout were not impacted, and > we both observed it was safe to remove this option. I felt like we both > worked toward a goal, and not that you pushed your personal vision > without any technical basis. I have a different memory. While I am also satisfied with the outcome, I remember that it was hard to explain why you couldn't just drop -fms-bitfields, and what analysis was required before you did that. And the outcome was positive mostly (or only) because *I* did the analysis that was necessary to ensure there would be no regressions with *your* proposed patch. What Daniel is asking is even less - he's only asking to *remove* the bits that symlink qemu-system-arm and qemu-system-riscv64 into qemu-system. (Perhaps you could do that with a configure option instead, btw, that's also a possibility and would make CI integration easier). >> This project was extremely complex and some disagreements are normal, >> but overall I would say it has received support from the community for >> years. It is close to the finish line, let's not forget all the >> collaboration so far. > > At this point, I don't see the finish line coming anytime soon. > We are stuck in a situation where we now might have to design a whole > new command line from scratch, for a reason I ignore. This is simply not true. The important part: "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". Experimental doesn't mean unusable. > - let's go with original plan, and just introduce -target option and > call it a day for now. CLI refactoring can be initiated in parallel. That's exactly what Daniel suggested. In fact the same is true for more things than just the command line: - filtering can be applied (if needed at all) to qemu-system *after* the binary is available in qemu.git, exactly because qemu-system is experimental; - if we decide later that -target is not always needed, that would also be doable after the merge. I hope this helps not so much solving the technical disagreement, but clarifying that yes, sometimes you've got to "agree to disagree", but personal attacks of any intensity are not "agreeing to disagree". Paolo
On Thu, 27 Aug 2026 at 17:32, Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> wrote: > > On 8/27/2026 2:44 AM, Daniel P. Berrangé wrote: > > On Wed, Aug 26, 2026 at 11:35:11AM -0700, Pierrick Bouvier wrote: > >> 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. > > > > This kind of comment is not productive and disrepectful to the time > > reviewers in invest in looking at the proposed patches. Please stop > > this. > > > > The only person wasting everyone's time here is YOU. > There is not a single person who came on any thread to say "I agree with > you Daniel", while several posted or commented they were ok with the > approach here. > > Project is QEMU, not Daniel's EMU. > > Whether or not you like my joke above does not matter, just focus on the > first sentence of it. Send a series implementing your view instead of > long emails "I said so" on other people series. And go back to the lamp > until it's ready. Pierrick: please calm down and take a less confrontational attitude in your mailing list posts. Daniel is reviewing the code, which is part of the project's process. He hasn't done anything here that merits the sniping you've been doing in this thread. This is entirely separate from any technical issues about what the best approach here is. -- PMM
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
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.
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.
I believe we'll end up doing a break with the past and experimenting a lot with
it (we definitely should mark it as experimental for multiple releases ...).
I also believe that there will be things we'll figure out only after the POC
lands, so might as well strive to get to that point ASAP.
Cheers,
dhb
>
>
> ATB,
>
> Mark.
>
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 :|
On Wed, Aug 26, 2026 at 9:41 PM Mark Cave-Ayland <
mark.caveayland@nutanix.com> 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
This is also why I post these patches, i've already enabled better modules
support, so we can implement devices in dll(win32/linux/osx) all works.
I achieve that by introducing a new plugin and getting the memory to be
more configable. so that we can bind the device to dma-memory by option,
not by link.
> 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.
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
On Wed, Aug 26, 2026 at 02:40:46PM +0100, 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.. > > > > 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 think it is worth considering whether modules could be mandatory unconditionally for everything. We don't need to block on this decision though. > 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? -blockdev isn't as hard as it appears - we make it harder than it ought to be by not documenting it well and carrying on using -hda/-drive in examples so users have little good guidance. Then when people go beyond the needs that -hda can service, they have an worse experiance as a result. Having many different ways to do the same thing and not getting rid of enough outdated/obsoleted stuff is what has always created confusion for QEMU. Also why it is -hda when it is created a SCSI disk (sda), or a VirtIO disk (xda) or a SSD (mmcblk0), or the guest is calling it C:\ :-) Yes, -hda is simple, but it is also nonsensical historical cruft. All the various "convenience" args are also something that could be provided by a higher level launcher script that translates to the canonical syntax, even if they're not in qemu-system itself. 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 :|
© 2016 - 2026 Red Hat, Inc.