Now that we can link a single-binary with at least two targets (arm, aarch64),
we want to make sure that we expose the same set of machines (later devices and
cpus) than target binaries. For that, we implemented a static filtering based on
target interfaces that each machine will implement to declare which targets have
this machine.

However, we discovered that this static filtering is not enough. Indeed, some
machines and devices do not depend only on target, and their presence can depend
on Kconfig or host/target combination. Thus, our static approach can't work, and
we need something more flexible.

The goal of this series is to focus on the filtering mechanism, not on the
qemu-system binary itself, even though it's included here to give a full picture
of what we are building.

v3
--

Suggested by Richard, we simply use a callback added to TypeInfo.
Added full example with a single binary for arm+aarch64, and then
arm+aarch64+microblaze.
Also, added scripts/single-binary-compare-cmdline.sh, which compares list of
cpus, devices and machines between single-binary and original binaries.
This is what we can use in CI to ensure we correctly tagged all QOM types.

v2
--

Suggested by Daniel, we share a list of requirement for type to be available,
for future introspection needs.

v1
--
This series adds a new TYPE_TARGET_SPECIFIC, that declare a single function
bool is_available(void). From there, any machine type (and later devices and
cpus) can implement it to override their presence for each target.
We first replace the existing static mechanism with this, and once done, we
cleanup all the old interface. One nice benefit is that we can get rid of
config/targets/*.c files, which saves duplication.

Pierrick Bouvier (41):
  hw/remote/machine: remove unsupported arm target
  single-binary: command line reference
  qom/object: add is_available callback to TypeInfo
  hw/arm: filter minimal set of machines
  system: query machines using TYPE_MACHINE
  target-info: remove machine_typename
  configs/targets: remove target info definitions
  target-info: rename target-info-stub.c in target-info-def.c
  hw/arm: remove TYPE_TARGET_{AARCH64,ARM}_MACHINE
  hw/arm: remove {arm,arm_aarch64,aarch64}_machine_interfaces
  hw/arm: remove DEFINE_MACHINE_{AARCH64,ARM}
  hw/arm: remove machines-qom.h
  hw/riscv: remove TYPE_TARGET_{RISCV32,RISCV64}_MACHINE
  hw/riscv: remove {riscv32,riscv32_64,riscv64}_machine_interfaces
  hw/riscv: remove DEFINE_MACHINE_{RISCV32,RISCV64}
  hw/riscv: remove machines-qom.h
  target-info: add target_config_multiprocess
  hw/remote/machine: filter from CONFIG_MULTIPROCESS
  target-info: add target_config_nitro
  hw/nitro/machine: filter from CONFIG_NITRO
  hw/arm: filter aarch64 only machines
  target-info: add target_config_dpcd
  hw/display/dpcd: filter from CONFIG_DPCD
  hw/nitro: filter from CONFIG_NITRO
  hw/remote/proxy: filter from CONFIG_MULTIPROCESS
  target/arm: filter cpus from target
  system/vl: add new option -target
  system/vl: fallback to detect target from argv[0]
  meson: build single binary for arm+aarch64 targets
  scripts: add single-binary-compare-cmdline.sh
  hw/core/boards.h: add available callback to DEFINE_MACHINE_EXTENDED
  hw/core/boards.h: remove unused DEFINE_MACHINE_WITH_INTERFACE*
  hw/core/boards.h: add available callback to DEFINE_MACHINE
  hw/arm: filter arm machines
  target-info: add target_microblaze
  hw/microblaze: filter microblaze machines
  target/microblaze/cpu: filter microblaze cpu
  hw: filter arm devices
  target-info: add target_config_cxl
  hw/pci-bridge: filter from CONFIG_CXL
  meson: add microblaze to single-binary

Richard Henderson (6):
  target/arm: Move -cpu max stuff out of cpu32.c
  target/arm: Build cpu32.c once in system mode
  target/arm: Rename and adjust aarch32_max_v8_tcg_initfn
  target/arm: Introduce cpu types max-v8 and max-v9
  target/arm: Use -cpu max-v8 with aarch64=off
  target/arm: Separate cpu types max-v8 and max-v9

 cmdline_ref/qemu-aarch64.cpu_help             |  16 +
 cmdline_ref/qemu-aarch64.help                 |  50 ++
 cmdline_ref/qemu-aarch64_be.cpu_help          |  16 +
 cmdline_ref/qemu-aarch64_be.help              |  50 ++
 cmdline_ref/qemu-alpha.cpu_help               |   8 +
 cmdline_ref/qemu-alpha.help                   |  50 ++
 cmdline_ref/qemu-arm.cpu_help                 |  26 +
 cmdline_ref/qemu-arm.help                     |  50 ++
 cmdline_ref/qemu-armeb.cpu_help               |  26 +
 cmdline_ref/qemu-armeb.help                   |  50 ++
 cmdline_ref/qemu-hexagon.cpu_help             |  13 +
 cmdline_ref/qemu-hexagon.help                 |  50 ++
 cmdline_ref/qemu-hppa.cpu_help                |   4 +
 cmdline_ref/qemu-hppa.help                    |  50 ++
 cmdline_ref/qemu-i386.cpu_help                | 259 ++++++++
 cmdline_ref/qemu-i386.help                    |  50 ++
 cmdline_ref/qemu-loongarch64.cpu_help         |   4 +
 cmdline_ref/qemu-loongarch64.help             |  50 ++
 cmdline_ref/qemu-m68k.cpu_help                |  11 +
 cmdline_ref/qemu-m68k.help                    |  50 ++
 cmdline_ref/qemu-microblaze.cpu_help          |   2 +
 cmdline_ref/qemu-microblaze.help              |  50 ++
 cmdline_ref/qemu-microblazeel.cpu_help        |   2 +
 cmdline_ref/qemu-microblazeel.help            |  50 ++
 cmdline_ref/qemu-mips.cpu_help                |  19 +
 cmdline_ref/qemu-mips.help                    |  50 ++
 cmdline_ref/qemu-mips64.cpu_help              |  35 ++
 cmdline_ref/qemu-mips64.help                  |  50 ++
 cmdline_ref/qemu-mips64el.cpu_help            |  35 ++
 cmdline_ref/qemu-mips64el.help                |  50 ++
 cmdline_ref/qemu-mipsel.cpu_help              |  19 +
 cmdline_ref/qemu-mipsel.help                  |  50 ++
 cmdline_ref/qemu-mipsn32.cpu_help             |  35 ++
 cmdline_ref/qemu-mipsn32.help                 |  50 ++
 cmdline_ref/qemu-mipsn32el.cpu_help           |  35 ++
 cmdline_ref/qemu-mipsn32el.help               |  50 ++
 cmdline_ref/qemu-or1k.cpu_help                |   3 +
 cmdline_ref/qemu-or1k.help                    |  50 ++
 cmdline_ref/qemu-ppc.cpu_help                 | 432 +++++++++++++
 cmdline_ref/qemu-ppc.help                     |  50 ++
 cmdline_ref/qemu-ppc64.cpu_help               | 464 ++++++++++++++
 cmdline_ref/qemu-ppc64.help                   |  50 ++
 cmdline_ref/qemu-ppc64le.cpu_help             | 464 ++++++++++++++
 cmdline_ref/qemu-ppc64le.help                 |  50 ++
 cmdline_ref/qemu-riscv32.cpu_help             |   9 +
 cmdline_ref/qemu-riscv32.help                 |  50 ++
 cmdline_ref/qemu-riscv64.cpu_help             |  20 +
 cmdline_ref/qemu-riscv64.help                 |  50 ++
 cmdline_ref/qemu-s390x.cpu_help               | 512 +++++++++++++++
 cmdline_ref/qemu-s390x.help                   |  50 ++
 cmdline_ref/qemu-sh4.cpu_help                 |   4 +
 cmdline_ref/qemu-sh4.help                     |  50 ++
 cmdline_ref/qemu-sh4eb.cpu_help               |   4 +
 cmdline_ref/qemu-sh4eb.help                   |  50 ++
 cmdline_ref/qemu-sparc.cpu_help               |  17 +
 cmdline_ref/qemu-sparc.help                   |  50 ++
 cmdline_ref/qemu-sparc32plus.cpu_help         |  21 +
 cmdline_ref/qemu-sparc32plus.help             |  50 ++
 cmdline_ref/qemu-sparc64.cpu_help             |  21 +
 cmdline_ref/qemu-sparc64.help                 |  50 ++
 cmdline_ref/qemu-system-aarch64.cpu_help      |  40 ++
 cmdline_ref/qemu-system-aarch64.device_help   | 446 +++++++++++++
 cmdline_ref/qemu-system-aarch64.help          | 592 +++++++++++++++++
 cmdline_ref/qemu-system-aarch64.machine_help  | 114 ++++
 cmdline_ref/qemu-system-alpha.cpu_help        |   8 +
 cmdline_ref/qemu-system-alpha.device_help     | 243 +++++++
 cmdline_ref/qemu-system-alpha.help            | 555 ++++++++++++++++
 cmdline_ref/qemu-system-alpha.machine_help    |   3 +
 cmdline_ref/qemu-system-arm.cpu_help          |  26 +
 cmdline_ref/qemu-system-arm.device_help       | 442 +++++++++++++
 cmdline_ref/qemu-system-arm.help              | 592 +++++++++++++++++
 cmdline_ref/qemu-system-arm.machine_help      |  96 +++
 cmdline_ref/qemu-system-avr.cpu_help          |   4 +
 cmdline_ref/qemu-system-avr.device_help       |   5 +
 cmdline_ref/qemu-system-avr.help              | 555 ++++++++++++++++
 cmdline_ref/qemu-system-avr.machine_help      |  10 +
 cmdline_ref/qemu-system-hexagon.cpu_help      |  13 +
 cmdline_ref/qemu-system-hexagon.device_help   |  53 ++
 cmdline_ref/qemu-system-hexagon.help          | 555 ++++++++++++++++
 cmdline_ref/qemu-system-hexagon.machine_help  |   4 +
 cmdline_ref/qemu-system-hppa.cpu_help         |   4 +
 cmdline_ref/qemu-system-hppa.device_help      | 238 +++++++
 cmdline_ref/qemu-system-hppa.help             | 555 ++++++++++++++++
 cmdline_ref/qemu-system-hppa.machine_help     |   6 +
 cmdline_ref/qemu-system-i386.cpu_help         | 259 ++++++++
 cmdline_ref/qemu-system-i386.device_help      | 492 +++++++++++++++
 cmdline_ref/qemu-system-i386.help             | 595 ++++++++++++++++++
 cmdline_ref/qemu-system-i386.machine_help     |  42 ++
 cmdline_ref/qemu-system-loongarch64.cpu_help  |   4 +
 .../qemu-system-loongarch64.device_help       | 247 ++++++++
 cmdline_ref/qemu-system-loongarch64.help      | 582 +++++++++++++++++
 .../qemu-system-loongarch64.machine_help      |   5 +
 cmdline_ref/qemu-system-m68k.cpu_help         |  11 +
 cmdline_ref/qemu-system-m68k.device_help      |  59 ++
 cmdline_ref/qemu-system-m68k.help             | 559 ++++++++++++++++
 cmdline_ref/qemu-system-m68k.machine_help     |  25 +
 cmdline_ref/qemu-system-microblaze.cpu_help   |   2 +
 .../qemu-system-microblaze.device_help        | 145 +++++
 cmdline_ref/qemu-system-microblaze.help       | 555 ++++++++++++++++
 .../qemu-system-microblaze.machine_help       |   5 +
 cmdline_ref/qemu-system-mips.cpu_help         |  19 +
 cmdline_ref/qemu-system-mips.device_help      | 244 +++++++
 cmdline_ref/qemu-system-mips.help             | 558 ++++++++++++++++
 cmdline_ref/qemu-system-mips.machine_help     |   3 +
 cmdline_ref/qemu-system-mips64.cpu_help       |  35 ++
 cmdline_ref/qemu-system-mips64.device_help    | 244 +++++++
 cmdline_ref/qemu-system-mips64.help           | 558 ++++++++++++++++
 cmdline_ref/qemu-system-mips64.machine_help   |   5 +
 cmdline_ref/qemu-system-mips64el.cpu_help     |  35 ++
 cmdline_ref/qemu-system-mips64el.device_help  | 262 ++++++++
 cmdline_ref/qemu-system-mips64el.help         | 558 ++++++++++++++++
 cmdline_ref/qemu-system-mips64el.machine_help |   8 +
 cmdline_ref/qemu-system-mipsel.cpu_help       |  19 +
 cmdline_ref/qemu-system-mipsel.device_help    | 244 +++++++
 cmdline_ref/qemu-system-mipsel.help           | 558 ++++++++++++++++
 cmdline_ref/qemu-system-mipsel.machine_help   |   3 +
 cmdline_ref/qemu-system-or1k.cpu_help         |   3 +
 cmdline_ref/qemu-system-or1k.device_help      | 232 +++++++
 cmdline_ref/qemu-system-or1k.help             | 555 ++++++++++++++++
 cmdline_ref/qemu-system-or1k.machine_help     |   4 +
 cmdline_ref/qemu-system-ppc.cpu_help          | 385 ++++++++++++
 cmdline_ref/qemu-system-ppc.device_help       | 271 ++++++++
 cmdline_ref/qemu-system-ppc.help              | 559 ++++++++++++++++
 cmdline_ref/qemu-system-ppc.machine_help      |  14 +
 cmdline_ref/qemu-system-ppc64.cpu_help        | 417 ++++++++++++
 cmdline_ref/qemu-system-ppc64.device_help     | 447 +++++++++++++
 cmdline_ref/qemu-system-ppc64.help            | 559 ++++++++++++++++
 cmdline_ref/qemu-system-ppc64.machine_help    |  39 ++
 cmdline_ref/qemu-system-riscv32.cpu_help      |   9 +
 cmdline_ref/qemu-system-riscv32.device_help   | 385 ++++++++++++
 cmdline_ref/qemu-system-riscv32.help          | 586 +++++++++++++++++
 cmdline_ref/qemu-system-riscv32.machine_help  |   8 +
 cmdline_ref/qemu-system-riscv64.cpu_help      |  29 +
 cmdline_ref/qemu-system-riscv64.device_help   | 388 ++++++++++++
 cmdline_ref/qemu-system-riscv64.help          | 586 +++++++++++++++++
 cmdline_ref/qemu-system-riscv64.machine_help  |  13 +
 cmdline_ref/qemu-system-rx.cpu_help           |   2 +
 cmdline_ref/qemu-system-rx.device_help        |  10 +
 cmdline_ref/qemu-system-rx.help               | 555 ++++++++++++++++
 cmdline_ref/qemu-system-rx.machine_help       |   4 +
 cmdline_ref/qemu-system-s390x.cpu_help        | 512 +++++++++++++++
 cmdline_ref/qemu-system-s390x.device_help     | 257 ++++++++
 cmdline_ref/qemu-system-s390x.help            | 556 ++++++++++++++++
 cmdline_ref/qemu-system-s390x.machine_help    |  21 +
 cmdline_ref/qemu-system-sh4.cpu_help          |   4 +
 cmdline_ref/qemu-system-sh4.device_help       | 240 +++++++
 cmdline_ref/qemu-system-sh4.help              | 555 ++++++++++++++++
 cmdline_ref/qemu-system-sh4.machine_help      |   3 +
 cmdline_ref/qemu-system-sh4eb.cpu_help        |   4 +
 cmdline_ref/qemu-system-sh4eb.device_help     | 240 +++++++
 cmdline_ref/qemu-system-sh4eb.help            | 555 ++++++++++++++++
 cmdline_ref/qemu-system-sh4eb.machine_help    |   3 +
 cmdline_ref/qemu-system-sparc.cpu_help        |  17 +
 cmdline_ref/qemu-system-sparc.device_help     |  12 +
 cmdline_ref/qemu-system-sparc.help            | 558 ++++++++++++++++
 cmdline_ref/qemu-system-sparc.machine_help    |  12 +
 cmdline_ref/qemu-system-sparc64.cpu_help      |  21 +
 cmdline_ref/qemu-system-sparc64.device_help   | 244 +++++++
 cmdline_ref/qemu-system-sparc64.help          | 558 ++++++++++++++++
 cmdline_ref/qemu-system-sparc64.machine_help  |   5 +
 cmdline_ref/qemu-system-tricore.cpu_help      |   5 +
 cmdline_ref/qemu-system-tricore.device_help   |   5 +
 cmdline_ref/qemu-system-tricore.help          | 555 ++++++++++++++++
 cmdline_ref/qemu-system-tricore.machine_help  |   4 +
 cmdline_ref/qemu-system-x86_64.cpu_help       | 259 ++++++++
 cmdline_ref/qemu-system-x86_64.device_help    | 492 +++++++++++++++
 cmdline_ref/qemu-system-x86_64.help           | 595 ++++++++++++++++++
 cmdline_ref/qemu-system-x86_64.machine_help   |  42 ++
 cmdline_ref/qemu-system-xtensa.cpu_help       |   9 +
 cmdline_ref/qemu-system-xtensa.device_help    | 226 +++++++
 cmdline_ref/qemu-system-xtensa.help           | 558 ++++++++++++++++
 cmdline_ref/qemu-system-xtensa.machine_help   |  12 +
 cmdline_ref/qemu-system-xtensaeb.cpu_help     |   3 +
 cmdline_ref/qemu-system-xtensaeb.device_help  | 226 +++++++
 cmdline_ref/qemu-system-xtensaeb.help         | 558 ++++++++++++++++
 cmdline_ref/qemu-system-xtensaeb.machine_help |  12 +
 cmdline_ref/qemu-x86_64.cpu_help              | 259 ++++++++
 cmdline_ref/qemu-x86_64.help                  |  50 ++
 cmdline_ref/qemu-xtensa.cpu_help              |   9 +
 cmdline_ref/qemu-xtensa.help                  |  51 ++
 cmdline_ref/qemu-xtensaeb.cpu_help            |   3 +
 cmdline_ref/qemu-xtensaeb.help                |  51 ++
 cmdline_update_ref.sh                         |  49 ++
 configs/targets/aarch64-softmmu.c             |  27 -
 configs/targets/arm-softmmu.c                 |  27 -
 configs/targets/meson.build                   |   6 -
 configs/targets/riscv32-softmmu.c             |  26 -
 configs/targets/riscv64-softmmu.c             |  26 -
 docs/system/arm/emulation.rst                 |  13 +-
 hw/alpha/dp264.c                              |   2 +-
 hw/arm/aspeed.c                               |   1 -
 hw/arm/aspeed_ast1040_evb.c                   |   3 +-
 hw/arm/aspeed_ast10x0_evb.c                   |   5 +-
 hw/arm/aspeed_ast2400_palmetto.c              |   3 +-
 hw/arm/aspeed_ast2400_quanta-q71l.c           |   3 +-
 hw/arm/aspeed_ast2400_supermicrox11.c         |   3 +-
 hw/arm/aspeed_ast2500_evb.c                   |   3 +-
 hw/arm/aspeed_ast2500_g220a.c                 |   3 +-
 hw/arm/aspeed_ast2500_romulus.c               |   3 +-
 hw/arm/aspeed_ast2500_supermicro-x11spi.c     |   3 +-
 hw/arm/aspeed_ast2500_tiogapass.c             |   3 +-
 hw/arm/aspeed_ast2500_witherspoon.c           |   3 +-
 hw/arm/aspeed_ast2500_yosemitev2.c            |   3 +-
 hw/arm/aspeed_ast2600_anacapa.c               |   3 +-
 hw/arm/aspeed_ast2600_bletchley.c             |   3 +-
 hw/arm/aspeed_ast2600_catalina.c              |   3 +-
 hw/arm/aspeed_ast2600_evb.c                   |   3 +-
 hw/arm/aspeed_ast2600_fby35.c                 |   3 +-
 hw/arm/aspeed_ast2600_fuji.c                  |   3 +-
 hw/arm/aspeed_ast2600_gb200nvl.c              |   3 +-
 hw/arm/aspeed_ast2600_rainier.c               |   3 +-
 hw/arm/aspeed_ast27x0-fc.c                    |   3 +-
 hw/arm/aspeed_ast27x0_evb.c                   |   5 +-
 hw/arm/ax3000-boards.c                        |   2 -
 hw/arm/ax3000-evk.c                           |   1 +
 hw/arm/b-l475e-iot01a.c                       |   3 +-
 hw/arm/bananapi_m2u.c                         |   3 +-
 hw/arm/collie.c                               |   3 +-
 hw/arm/cubieboard.c                           |   3 +-
 hw/arm/digic_boards.c                         |   3 +-
 hw/arm/exynos4_boards.c                       |   5 +-
 hw/arm/imx25_pdk.c                            |   3 +-
 hw/arm/imx8mm-evk.c                           |  19 +-
 hw/arm/imx8mp-evk.c                           |   3 +-
 hw/arm/integratorcp.c                         |   3 +-
 hw/arm/kzm.c                                  |   3 +-
 hw/arm/max78000fthr.c                         |   3 +-
 hw/arm/mcimx6ul-evk.c                         |   3 +-
 hw/arm/mcimx7d-sabre.c                        |   3 +-
 hw/arm/microbit.c                             |   3 +-
 hw/arm/mps2-tz.c                              |   9 +-
 hw/arm/mps2.c                                 |   9 +-
 hw/arm/mps3r.c                                |   3 +-
 hw/arm/msf2-som.c                             |   3 +-
 hw/arm/musca.c                                |   5 +-
 hw/arm/musicpal.c                             |   3 +-
 hw/arm/netduino2.c                            |   3 +-
 hw/arm/netduinoplus2.c                        |   3 +-
 hw/arm/npcm7xx_boards.c                       |  11 +-
 hw/arm/npcm8xx_boards.c                       |   3 +-
 hw/arm/olimex-stm32-h405.c                    |   4 +-
 hw/arm/omap_sx1.c                             |   5 +-
 hw/arm/orangepi.c                             |   3 +-
 hw/arm/raspi.c                                |  11 +-
 hw/arm/raspi4b.c                              |   3 +-
 hw/arm/realview.c                             |   9 +-
 hw/arm/sabrelite.c                            |   3 +-
 hw/arm/sbsa-ref.c                             |   5 +-
 hw/arm/stellaris.c                            |   5 +-
 hw/arm/stm32vldiscovery.c                     |   4 +-
 hw/arm/versatilepb.c                          |   5 +-
 hw/arm/vexpress.c                             |   5 +-
 hw/arm/virt.c                                 |   5 +-
 hw/arm/xen-pvh.c                              |   2 -
 hw/arm/xilinx_zynq.c                          |   3 +-
 hw/arm/xlnx-versal-virt.c                     |   5 +-
 hw/arm/xlnx-zcu102.c                          |   3 +-
 hw/core/machine-qmp-cmds.c                    |   2 +-
 hw/core/null-machine.c                        |   9 +-
 hw/display/dpcd.c                             |   1 +
 hw/m68k/an5206.c                              |   2 +-
 hw/m68k/mcf5208.c                             |   2 +-
 hw/microblaze/petalogix_ml605_mmu.c           |   3 +-
 hw/microblaze/petalogix_s3adsp1800_mmu.c      |   1 +
 hw/microblaze/xlnx-zynqmp-pmu.c               |   3 +-
 hw/mips/boston.c                              |   2 +-
 hw/mips/fuloong2e.c                           |   2 +-
 hw/mips/malta.c                               |   2 +-
 hw/nitro/heartbeat.c                          |   1 +
 hw/nitro/machine.c                            |   7 +-
 hw/nitro/serial-vsock.c                       |   1 +
 hw/pci-bridge/cxl_downstream.c                |   1 +
 hw/pci-bridge/cxl_root_port.c                 |   1 +
 hw/pci-bridge/cxl_upstream.c                  |   1 +
 hw/pci-host/aspeed_pcie.c                     |   1 +
 hw/ppc/amigaone.c                             |   2 +-
 hw/ppc/pegasos.c                              |   2 +-
 hw/ppc/ppc440_bamboo.c                        |   2 +-
 hw/ppc/prep.c                                 |   2 +-
 hw/ppc/sam460ex.c                             |   2 +-
 hw/ppc/virtex_ml507.c                         |   2 +-
 hw/remote/machine.c                           |   4 +-
 hw/remote/proxy.c                             |   1 +
 hw/riscv/boston-aia.c                         |   3 +-
 hw/riscv/k230.c                               |   2 -
 hw/riscv/microblaze-v-generic.c               |   3 +-
 hw/riscv/microchip_pfsoc.c                    |   2 -
 hw/riscv/opentitan.c                          |   2 -
 hw/riscv/shakti_c.c                           |   2 -
 hw/riscv/sifive_e.c                           |   2 -
 hw/riscv/sifive_u.c                           |   2 -
 hw/riscv/spike.c                              |   2 -
 hw/riscv/tt_atlantis.c                        |   2 -
 hw/riscv/virt.c                               |   3 -
 hw/riscv/xiangshan_kmh.c                      |   2 -
 hw/sh4/r2d.c                                  |   2 +-
 hw/sparc/leon3.c                              |   2 +-
 hw/tricore/tricore_testboard.c                |   2 +-
 hw/xenpv/xen_machine_pv.c                     |   2 +-
 hw/xtensa/sim.c                               |   2 +-
 hw/xtensa/virt.c                              |   2 +-
 include/hw/arm/machines-qom.h                 |  46 --
 include/hw/core/boards.h                      |  16 +-
 include/hw/riscv/machines-qom.h               |  46 --
 include/qemu/target-info-impl.h               |  11 +-
 include/qemu/target-info-qom.h                |   2 +
 include/qemu/target-info.h                    |  43 +-
 include/qom/object.h                          |   3 +
 meson.build                                   |  53 +-
 monitor/qemu-config-qmp.c                     |   2 +-
 qemu-options.hx                               |   8 +
 qom/object.c                                  |   4 +
 rust/qom/src/qom.rs                           |   1 +
 scripts/single-binary-compare-cmdline.sh      |  51 ++
 system/vl.c                                   |  39 +-
 target-info-stub.c => target-info-def.c       |  17 +-
 target-info-qom.c                             | 117 +++-
 target-info.c                                 |  31 +-
 target/arm/cpu-max.c                          |   6 +-
 target/arm/cpu.c                              |   3 +-
 target/arm/cpu64.c                            |   2 +-
 target/arm/internals.h                        |   7 +-
 target/arm/machine.c                          |  18 -
 target/arm/tcg/cpu-max-v8.c                   | 130 ++++
 target/arm/tcg/cpu-v7m.c                      |   2 +-
 target/arm/tcg/cpu32.c                        | 118 +---
 target/arm/tcg/cpu64.c                        | 161 +++--
 target/arm/tcg/meson.build                    |  11 +-
 target/arm/tcg/stubs32.c                      |   7 +-
 target/microblaze/cpu.c                       |   1 +
 target/riscv/machine.c                        |  17 -
 .../aarch64/test_virt_aarch64_off.py          |   4 +-
 tests/qtest/arm-cpu-features.c                |   4 +-
 tests/qtest/fuzz/fuzz.c                       |   2 +-
 334 files changed, 31366 insertions(+), 716 deletions(-)
 create mode 100644 cmdline_ref/qemu-aarch64.cpu_help
 create mode 100644 cmdline_ref/qemu-aarch64.help
 create mode 100644 cmdline_ref/qemu-aarch64_be.cpu_help
 create mode 100644 cmdline_ref/qemu-aarch64_be.help
 create mode 100644 cmdline_ref/qemu-alpha.cpu_help
 create mode 100644 cmdline_ref/qemu-alpha.help
 create mode 100644 cmdline_ref/qemu-arm.cpu_help
 create mode 100644 cmdline_ref/qemu-arm.help
 create mode 100644 cmdline_ref/qemu-armeb.cpu_help
 create mode 100644 cmdline_ref/qemu-armeb.help
 create mode 100644 cmdline_ref/qemu-hexagon.cpu_help
 create mode 100644 cmdline_ref/qemu-hexagon.help
 create mode 100644 cmdline_ref/qemu-hppa.cpu_help
 create mode 100644 cmdline_ref/qemu-hppa.help
 create mode 100644 cmdline_ref/qemu-i386.cpu_help
 create mode 100644 cmdline_ref/qemu-i386.help
 create mode 100644 cmdline_ref/qemu-loongarch64.cpu_help
 create mode 100644 cmdline_ref/qemu-loongarch64.help
 create mode 100644 cmdline_ref/qemu-m68k.cpu_help
 create mode 100644 cmdline_ref/qemu-m68k.help
 create mode 100644 cmdline_ref/qemu-microblaze.cpu_help
 create mode 100644 cmdline_ref/qemu-microblaze.help
 create mode 100644 cmdline_ref/qemu-microblazeel.cpu_help
 create mode 100644 cmdline_ref/qemu-microblazeel.help
 create mode 100644 cmdline_ref/qemu-mips.cpu_help
 create mode 100644 cmdline_ref/qemu-mips.help
 create mode 100644 cmdline_ref/qemu-mips64.cpu_help
 create mode 100644 cmdline_ref/qemu-mips64.help
 create mode 100644 cmdline_ref/qemu-mips64el.cpu_help
 create mode 100644 cmdline_ref/qemu-mips64el.help
 create mode 100644 cmdline_ref/qemu-mipsel.cpu_help
 create mode 100644 cmdline_ref/qemu-mipsel.help
 create mode 100644 cmdline_ref/qemu-mipsn32.cpu_help
 create mode 100644 cmdline_ref/qemu-mipsn32.help
 create mode 100644 cmdline_ref/qemu-mipsn32el.cpu_help
 create mode 100644 cmdline_ref/qemu-mipsn32el.help
 create mode 100644 cmdline_ref/qemu-or1k.cpu_help
 create mode 100644 cmdline_ref/qemu-or1k.help
 create mode 100644 cmdline_ref/qemu-ppc.cpu_help
 create mode 100644 cmdline_ref/qemu-ppc.help
 create mode 100644 cmdline_ref/qemu-ppc64.cpu_help
 create mode 100644 cmdline_ref/qemu-ppc64.help
 create mode 100644 cmdline_ref/qemu-ppc64le.cpu_help
 create mode 100644 cmdline_ref/qemu-ppc64le.help
 create mode 100644 cmdline_ref/qemu-riscv32.cpu_help
 create mode 100644 cmdline_ref/qemu-riscv32.help
 create mode 100644 cmdline_ref/qemu-riscv64.cpu_help
 create mode 100644 cmdline_ref/qemu-riscv64.help
 create mode 100644 cmdline_ref/qemu-s390x.cpu_help
 create mode 100644 cmdline_ref/qemu-s390x.help
 create mode 100644 cmdline_ref/qemu-sh4.cpu_help
 create mode 100644 cmdline_ref/qemu-sh4.help
 create mode 100644 cmdline_ref/qemu-sh4eb.cpu_help
 create mode 100644 cmdline_ref/qemu-sh4eb.help
 create mode 100644 cmdline_ref/qemu-sparc.cpu_help
 create mode 100644 cmdline_ref/qemu-sparc.help
 create mode 100644 cmdline_ref/qemu-sparc32plus.cpu_help
 create mode 100644 cmdline_ref/qemu-sparc32plus.help
 create mode 100644 cmdline_ref/qemu-sparc64.cpu_help
 create mode 100644 cmdline_ref/qemu-sparc64.help
 create mode 100644 cmdline_ref/qemu-system-aarch64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-aarch64.device_help
 create mode 100644 cmdline_ref/qemu-system-aarch64.help
 create mode 100644 cmdline_ref/qemu-system-aarch64.machine_help
 create mode 100644 cmdline_ref/qemu-system-alpha.cpu_help
 create mode 100644 cmdline_ref/qemu-system-alpha.device_help
 create mode 100644 cmdline_ref/qemu-system-alpha.help
 create mode 100644 cmdline_ref/qemu-system-alpha.machine_help
 create mode 100644 cmdline_ref/qemu-system-arm.cpu_help
 create mode 100644 cmdline_ref/qemu-system-arm.device_help
 create mode 100644 cmdline_ref/qemu-system-arm.help
 create mode 100644 cmdline_ref/qemu-system-arm.machine_help
 create mode 100644 cmdline_ref/qemu-system-avr.cpu_help
 create mode 100644 cmdline_ref/qemu-system-avr.device_help
 create mode 100644 cmdline_ref/qemu-system-avr.help
 create mode 100644 cmdline_ref/qemu-system-avr.machine_help
 create mode 100644 cmdline_ref/qemu-system-hexagon.cpu_help
 create mode 100644 cmdline_ref/qemu-system-hexagon.device_help
 create mode 100644 cmdline_ref/qemu-system-hexagon.help
 create mode 100644 cmdline_ref/qemu-system-hexagon.machine_help
 create mode 100644 cmdline_ref/qemu-system-hppa.cpu_help
 create mode 100644 cmdline_ref/qemu-system-hppa.device_help
 create mode 100644 cmdline_ref/qemu-system-hppa.help
 create mode 100644 cmdline_ref/qemu-system-hppa.machine_help
 create mode 100644 cmdline_ref/qemu-system-i386.cpu_help
 create mode 100644 cmdline_ref/qemu-system-i386.device_help
 create mode 100644 cmdline_ref/qemu-system-i386.help
 create mode 100644 cmdline_ref/qemu-system-i386.machine_help
 create mode 100644 cmdline_ref/qemu-system-loongarch64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-loongarch64.device_help
 create mode 100644 cmdline_ref/qemu-system-loongarch64.help
 create mode 100644 cmdline_ref/qemu-system-loongarch64.machine_help
 create mode 100644 cmdline_ref/qemu-system-m68k.cpu_help
 create mode 100644 cmdline_ref/qemu-system-m68k.device_help
 create mode 100644 cmdline_ref/qemu-system-m68k.help
 create mode 100644 cmdline_ref/qemu-system-m68k.machine_help
 create mode 100644 cmdline_ref/qemu-system-microblaze.cpu_help
 create mode 100644 cmdline_ref/qemu-system-microblaze.device_help
 create mode 100644 cmdline_ref/qemu-system-microblaze.help
 create mode 100644 cmdline_ref/qemu-system-microblaze.machine_help
 create mode 100644 cmdline_ref/qemu-system-mips.cpu_help
 create mode 100644 cmdline_ref/qemu-system-mips.device_help
 create mode 100644 cmdline_ref/qemu-system-mips.help
 create mode 100644 cmdline_ref/qemu-system-mips.machine_help
 create mode 100644 cmdline_ref/qemu-system-mips64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-mips64.device_help
 create mode 100644 cmdline_ref/qemu-system-mips64.help
 create mode 100644 cmdline_ref/qemu-system-mips64.machine_help
 create mode 100644 cmdline_ref/qemu-system-mips64el.cpu_help
 create mode 100644 cmdline_ref/qemu-system-mips64el.device_help
 create mode 100644 cmdline_ref/qemu-system-mips64el.help
 create mode 100644 cmdline_ref/qemu-system-mips64el.machine_help
 create mode 100644 cmdline_ref/qemu-system-mipsel.cpu_help
 create mode 100644 cmdline_ref/qemu-system-mipsel.device_help
 create mode 100644 cmdline_ref/qemu-system-mipsel.help
 create mode 100644 cmdline_ref/qemu-system-mipsel.machine_help
 create mode 100644 cmdline_ref/qemu-system-or1k.cpu_help
 create mode 100644 cmdline_ref/qemu-system-or1k.device_help
 create mode 100644 cmdline_ref/qemu-system-or1k.help
 create mode 100644 cmdline_ref/qemu-system-or1k.machine_help
 create mode 100644 cmdline_ref/qemu-system-ppc.cpu_help
 create mode 100644 cmdline_ref/qemu-system-ppc.device_help
 create mode 100644 cmdline_ref/qemu-system-ppc.help
 create mode 100644 cmdline_ref/qemu-system-ppc.machine_help
 create mode 100644 cmdline_ref/qemu-system-ppc64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-ppc64.device_help
 create mode 100644 cmdline_ref/qemu-system-ppc64.help
 create mode 100644 cmdline_ref/qemu-system-ppc64.machine_help
 create mode 100644 cmdline_ref/qemu-system-riscv32.cpu_help
 create mode 100644 cmdline_ref/qemu-system-riscv32.device_help
 create mode 100644 cmdline_ref/qemu-system-riscv32.help
 create mode 100644 cmdline_ref/qemu-system-riscv32.machine_help
 create mode 100644 cmdline_ref/qemu-system-riscv64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-riscv64.device_help
 create mode 100644 cmdline_ref/qemu-system-riscv64.help
 create mode 100644 cmdline_ref/qemu-system-riscv64.machine_help
 create mode 100644 cmdline_ref/qemu-system-rx.cpu_help
 create mode 100644 cmdline_ref/qemu-system-rx.device_help
 create mode 100644 cmdline_ref/qemu-system-rx.help
 create mode 100644 cmdline_ref/qemu-system-rx.machine_help
 create mode 100644 cmdline_ref/qemu-system-s390x.cpu_help
 create mode 100644 cmdline_ref/qemu-system-s390x.device_help
 create mode 100644 cmdline_ref/qemu-system-s390x.help
 create mode 100644 cmdline_ref/qemu-system-s390x.machine_help
 create mode 100644 cmdline_ref/qemu-system-sh4.cpu_help
 create mode 100644 cmdline_ref/qemu-system-sh4.device_help
 create mode 100644 cmdline_ref/qemu-system-sh4.help
 create mode 100644 cmdline_ref/qemu-system-sh4.machine_help
 create mode 100644 cmdline_ref/qemu-system-sh4eb.cpu_help
 create mode 100644 cmdline_ref/qemu-system-sh4eb.device_help
 create mode 100644 cmdline_ref/qemu-system-sh4eb.help
 create mode 100644 cmdline_ref/qemu-system-sh4eb.machine_help
 create mode 100644 cmdline_ref/qemu-system-sparc.cpu_help
 create mode 100644 cmdline_ref/qemu-system-sparc.device_help
 create mode 100644 cmdline_ref/qemu-system-sparc.help
 create mode 100644 cmdline_ref/qemu-system-sparc.machine_help
 create mode 100644 cmdline_ref/qemu-system-sparc64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-sparc64.device_help
 create mode 100644 cmdline_ref/qemu-system-sparc64.help
 create mode 100644 cmdline_ref/qemu-system-sparc64.machine_help
 create mode 100644 cmdline_ref/qemu-system-tricore.cpu_help
 create mode 100644 cmdline_ref/qemu-system-tricore.device_help
 create mode 100644 cmdline_ref/qemu-system-tricore.help
 create mode 100644 cmdline_ref/qemu-system-tricore.machine_help
 create mode 100644 cmdline_ref/qemu-system-x86_64.cpu_help
 create mode 100644 cmdline_ref/qemu-system-x86_64.device_help
 create mode 100644 cmdline_ref/qemu-system-x86_64.help
 create mode 100644 cmdline_ref/qemu-system-x86_64.machine_help
 create mode 100644 cmdline_ref/qemu-system-xtensa.cpu_help
 create mode 100644 cmdline_ref/qemu-system-xtensa.device_help
 create mode 100644 cmdline_ref/qemu-system-xtensa.help
 create mode 100644 cmdline_ref/qemu-system-xtensa.machine_help
 create mode 100644 cmdline_ref/qemu-system-xtensaeb.cpu_help
 create mode 100644 cmdline_ref/qemu-system-xtensaeb.device_help
 create mode 100644 cmdline_ref/qemu-system-xtensaeb.help
 create mode 100644 cmdline_ref/qemu-system-xtensaeb.machine_help
 create mode 100644 cmdline_ref/qemu-x86_64.cpu_help
 create mode 100644 cmdline_ref/qemu-x86_64.help
 create mode 100644 cmdline_ref/qemu-xtensa.cpu_help
 create mode 100644 cmdline_ref/qemu-xtensa.help
 create mode 100644 cmdline_ref/qemu-xtensaeb.cpu_help
 create mode 100644 cmdline_ref/qemu-xtensaeb.help
 create mode 100755 cmdline_update_ref.sh
 delete mode 100644 configs/targets/aarch64-softmmu.c
 delete mode 100644 configs/targets/arm-softmmu.c
 delete mode 100644 configs/targets/meson.build
 delete mode 100644 configs/targets/riscv32-softmmu.c
 delete mode 100644 configs/targets/riscv64-softmmu.c
 delete mode 100644 include/hw/arm/machines-qom.h
 delete mode 100644 include/hw/riscv/machines-qom.h
 create mode 100755 scripts/single-binary-compare-cmdline.sh
 rename target-info-stub.c => target-info-def.c (81%)
 create mode 100644 target/arm/tcg/cpu-max-v8.c

-- 
2.43.0

On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
> Now that we can link a single-binary with at least two targets (arm, aarch64),
> we want to make sure that we expose the same set of machines (later devices and
> cpus) than target binaries. For that, we implemented a static filtering based on
> target interfaces that each machine will implement to declare which targets have
> this machine.
> 
> However, we discovered that this static filtering is not enough. Indeed, some
> machines and devices do not depend only on target, and their presence can depend
> on Kconfig or host/target combination. Thus, our static approach can't work, and
> we need something more flexible.
> 
> The goal of this series is to focus on the filtering mechanism, not on the
> qemu-system binary itself, even though it's included here to give a full picture
> of what we are building.
> 
> v3
> --
> 
> Suggested by Richard, we simply use a callback added to TypeInfo.
> Added full example with a single binary for arm+aarch64, and then
> arm+aarch64+microblaze.
> Also, added scripts/single-binary-compare-cmdline.sh, which compares list of
> cpus, devices and machines between single-binary and original binaries.
> This is what we can use in CI to ensure we correctly tagged all QOM types.
>

After applying this series, and running
scripts/single-binary-compare-cmdline.sh, you'll see than many devices
are visible for microblaze, and should not.

microblaze+arm is a more interesting combination than riscv+arm because
riscv has a lot of devices in common with arm. On the opposite,
microblaze has a very reduced set (no virtio, no pci, etc).

I would like to focus the conversation on how to filter the remaining
types. We could maybe generate something directly from Kconfig output,
so we don't need boilerplate for each CONFIG_X entry.

I understand the discussion has shifted to what qemu-system and its cli
should look like. Even if we end up creating a new cli from scratch, we
still need to solve the filtering part (or at least express the
constraints in a way that allows to filter it).

Thus, I hope we can stay focus on this series, and find something that
work all together. All ideas are welcome!

Regards,
Pierrick

On Fri, Aug 28, 2026 at 04:13:32PM -0700, Pierrick Bouvier wrote:
> On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
> > Now that we can link a single-binary with at least two targets (arm, aarch64),
> > we want to make sure that we expose the same set of machines (later devices and
> > cpus) than target binaries. For that, we implemented a static filtering based on
> > target interfaces that each machine will implement to declare which targets have
> > this machine.
> > 
> > However, we discovered that this static filtering is not enough. Indeed, some
> > machines and devices do not depend only on target, and their presence can depend
> > on Kconfig or host/target combination. Thus, our static approach can't work, and
> > we need something more flexible.
> > 
> > The goal of this series is to focus on the filtering mechanism, not on the
> > qemu-system binary itself, even though it's included here to give a full picture
> > of what we are building.
> > 
> > v3
> > --
> > 
> > Suggested by Richard, we simply use a callback added to TypeInfo.
> > Added full example with a single binary for arm+aarch64, and then
> > arm+aarch64+microblaze.
> > Also, added scripts/single-binary-compare-cmdline.sh, which compares list of
> > cpus, devices and machines between single-binary and original binaries.
> > This is what we can use in CI to ensure we correctly tagged all QOM types.
> >
> 
> After applying this series, and running
> scripts/single-binary-compare-cmdline.sh, you'll see than many devices
> are visible for microblaze, and should not.
> 
> microblaze+arm is a more interesting combination than riscv+arm because
> riscv has a lot of devices in common with arm. On the opposite,
> microblaze has a very reduced set (no virtio, no pci, etc).
> 
> I would like to focus the conversation on how to filter the remaining
> types. We could maybe generate something directly from Kconfig output,
> so we don't need boilerplate for each CONFIG_X entry.

I'm still not clear on why we need to filter the devices at all for
a new "qemu-system" binary ?

Looking at the device delta listed in your other mail, a large number
of those are PCI based. The microblaze machine types don't expose a
PCI controller, so those PCI devices are redundant / won't be used
with microblaze machines, which is why existing qemu-system-microblaze
doesn't link to those devices.

The same is true of many of the arm machines too though. Only a subset
of arm machines have PCI, but the qemu-system-arm binary still includes
and lists all these PCI devices. Users simply can't create a PCI device
for the arm machines that lack a PCI controller, or they'll receive an
error.

Why doesn't this approach extend into the future qemu-system binary ?
List everything, and if the user tries to add a device that's not
compatible with a machine, then it will simply result in an error.

It seems like much less work overall to do no filtering at all, than
trying to do per-target filtering which is the wrong granularity to
begin with, since the device usability contraints come from the
machine rather than the target.
 
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 Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
>
> On Fri, Aug 28, 2026 at 04:13:32PM -0700, Pierrick Bouvier wrote:
> > On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
> > > Now that we can link a single-binary with at least two targets (arm,
aarch64),
> > > we want to make sure that we expose the same set of machines (later
devices and
> > > cpus) than target binaries. For that, we implemented a static
filtering based on
> > > target interfaces that each machine will implement to declare which
targets have
> > > this machine.
> > >
> > > However, we discovered that this static filtering is not enough.
Indeed, some
> > > machines and devices do not depend only on target, and their presence
can depend
> > > on Kconfig or host/target combination. Thus, our static approach
can't work, and
> > > we need something more flexible.
> > >
> > > The goal of this series is to focus on the filtering mechanism, not
on the
> > > qemu-system binary itself, even though it's included here to give a
full picture
> > > of what we are building.
> > >
> > > v3
> > > --
> > >
> > > Suggested by Richard, we simply use a callback added to TypeInfo.
> > > Added full example with a single binary for arm+aarch64, and then
> > > arm+aarch64+microblaze.
> > > Also, added scripts/single-binary-compare-cmdline.sh, which compares
list of
> > > cpus, devices and machines between single-binary and original
binaries.
> > > This is what we can use in CI to ensure we correctly tagged all QOM
types.
> > >
> >
> > After applying this series, and running
> > scripts/single-binary-compare-cmdline.sh, you'll see than many devices
> > are visible for microblaze, and should not.
> >
> > microblaze+arm is a more interesting combination than riscv+arm because
> > riscv has a lot of devices in common with arm. On the opposite,
> > microblaze has a very reduced set (no virtio, no pci, etc).
> >
> > I would like to focus the conversation on how to filter the remaining
> > types. We could maybe generate something directly from Kconfig output,
> > so we don't need boilerplate for each CONFIG_X entry.
>
> I'm still not clear on why we need to filter the devices at all for
> a new "qemu-system" binary ?
>
> Looking at the device delta listed in your other mail, a large number
> of those are PCI based. The microblaze machine types don't expose a
> PCI controller, so those PCI devices are redundant / won't be used
> with microblaze machines, which is why existing qemu-system-microblaze
> doesn't link to those devices.
>
> The same is true of many of the arm machines too though. Only a subset
> of arm machines have PCI, but the qemu-system-arm binary still includes
> and lists all these PCI devices. Users simply can't create a PCI device
> for the arm machines that lack a PCI controller, or they'll receive an
> error.
>
> Why doesn't this approach extend into the future qemu-system binary ?
> List everything, and if the user tries to add a device that's not
> compatible with a machine, then it will simply result in an error.

Device filtering would be complicated, I guess, as there is so much
CONFIG_* for devices. Another approach is to just place devices under an
meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
listed(memory consumption will also be reduced when it's not needed).

But machine listings still need the filtering, considering virt is present
for many different arches(riscv/arm/i686). so machine listing is still a
thing.
The current is_avaible works fine for machines.
Pierrick is already pending the device filtering work, so I guess it's fine
now, we are just filtering the machines according to
https://lore.kernel.org/qemu-devel/20260901202043.26532-1-pierrick.bouvier@oss.qualcomm.com/
?

I also add patches based on this, so that we can list machines for
different  arches(riscv/arm/i686) properly for qemu-system, as I add a
TargetInfo parameter to is_available callback.
The patches is at
https://lore.kernel.org/qemu-devel/20260903205018.975-1-luoyonggang@gmail.com/



>
> It seems like much less work overall to do no filtering at all, than
> trying to do per-target filtering which is the wrong granularity to
> begin with, since the device usability contraints come from the
> machine rather than the target.
>
> 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 Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote:
> On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> >
> > On Fri, Aug 28, 2026 at 04:13:32PM -0700, Pierrick Bouvier wrote:
> > > On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
> > > > Now that we can link a single-binary with at least two targets (arm,
> aarch64),
> > > > we want to make sure that we expose the same set of machines (later
> devices and
> > > > cpus) than target binaries. For that, we implemented a static
> filtering based on
> > > > target interfaces that each machine will implement to declare which
> targets have
> > > > this machine.
> > > >
> > > > However, we discovered that this static filtering is not enough.
> Indeed, some
> > > > machines and devices do not depend only on target, and their presence
> can depend
> > > > on Kconfig or host/target combination. Thus, our static approach
> can't work, and
> > > > we need something more flexible.
> > > >
> > > > The goal of this series is to focus on the filtering mechanism, not
> on the
> > > > qemu-system binary itself, even though it's included here to give a
> full picture
> > > > of what we are building.
> > > >
> > > > v3
> > > > --
> > > >
> > > > Suggested by Richard, we simply use a callback added to TypeInfo.
> > > > Added full example with a single binary for arm+aarch64, and then
> > > > arm+aarch64+microblaze.
> > > > Also, added scripts/single-binary-compare-cmdline.sh, which compares
> list of
> > > > cpus, devices and machines between single-binary and original
> binaries.
> > > > This is what we can use in CI to ensure we correctly tagged all QOM
> types.
> > > >
> > >
> > > After applying this series, and running
> > > scripts/single-binary-compare-cmdline.sh, you'll see than many devices
> > > are visible for microblaze, and should not.
> > >
> > > microblaze+arm is a more interesting combination than riscv+arm because
> > > riscv has a lot of devices in common with arm. On the opposite,
> > > microblaze has a very reduced set (no virtio, no pci, etc).
> > >
> > > I would like to focus the conversation on how to filter the remaining
> > > types. We could maybe generate something directly from Kconfig output,
> > > so we don't need boilerplate for each CONFIG_X entry.
> >
> > I'm still not clear on why we need to filter the devices at all for
> > a new "qemu-system" binary ?
> >
> > Looking at the device delta listed in your other mail, a large number
> > of those are PCI based. The microblaze machine types don't expose a
> > PCI controller, so those PCI devices are redundant / won't be used
> > with microblaze machines, which is why existing qemu-system-microblaze
> > doesn't link to those devices.
> >
> > The same is true of many of the arm machines too though. Only a subset
> > of arm machines have PCI, but the qemu-system-arm binary still includes
> > and lists all these PCI devices. Users simply can't create a PCI device
> > for the arm machines that lack a PCI controller, or they'll receive an
> > error.
> >
> > Why doesn't this approach extend into the future qemu-system binary ?
> > List everything, and if the user tries to add a device that's not
> > compatible with a machine, then it will simply result in an error.
> 
> Device filtering would be complicated, I guess, as there is so much
> CONFIG_* for devices. Another approach is to just place devices under an
> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
> listed(memory consumption will also be reduced when it's not needed).

While modules are important for reducing memory consumption, I don't think
they need to be a blocker - making more things into modules can be done
in the backaround as & when people want to work on it.

> But machine listings still need the filtering, considering virt is present
> for many different arches(riscv/arm/i686). so machine listing is still a
> thing.

We still need the ability to query all machines present in the binary
and what targets they can be used with, for the purposes of introspection,
which the filtering doesn't allow for AFAICT. Renaming the clashing
machine names looks inescapable for the new qemu-system binary.

> The current is_avaible works fine for machines.
> Pierrick is already pending the device filtering work, so I guess it's fine
> now, we are just filtering the machines according to
> https://lore.kernel.org/qemu-devel/20260901202043.26532-1-pierrick.bouvier@oss.qualcomm.com/
> ?
> 
> I also add patches based on this, so that we can list machines for
> different  arches(riscv/arm/i686) properly for qemu-system, as I add a
> TargetInfo parameter to is_available callback.
> The patches is at
> https://lore.kernel.org/qemu-devel/20260903205018.975-1-luoyonggang@gmail.com/

For listing machines I'd expect to see the "MachineInfo" QAPI type
gain a "targets" parameter. eg something like this:

diff --git a/qapi/machine.json b/qapi/machine.json
index 2d63c1bac3..a614baa03a 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -195,6 +195,7 @@
 # @compat-props: The machine type's compatibility properties.  Only
 #     present when `query-machines` argument @compat-props is true.
 #     (since 9.1)
+# @targets: list of targets that can run this machine (since 11.2)
 #
 # Features:
 #
@@ -207,6 +208,7 @@
             '*is-default': 'bool', 'cpu-max': 'int',
             'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
             'deprecated': 'bool', '*default-cpu-type': 'str',
+            'targets': ['SysEmuTarget'],
             '*default-ram-id': 'str', 'acpi': 'bool',
             '*compat-props': { 'type': ['CompatProperty'],
                                'features': ['unstable'] } } }


which can be populated from the machine class

diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 543dd3201b..4852be25ca 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -104,6 +104,8 @@ MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
         MachineClass *mc = el->data;
         const char *default_cpu_type = machine_class_default_cpu_type(mc);
         MachineInfo *info;
+        SysEmuTargetList **tgts;
+        int n;
 
         info = g_malloc0(sizeof(*info));
         if (mc->is_default) {
@@ -120,6 +122,11 @@ MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
         info->hotpluggable_cpus = mc->has_hotpluggable_cpus;
         info->numa_mem_supported = mc->numa_mem_supported;
         info->deprecated = !!mc->deprecation_reason;
+
+        tgts = &(info->targets);
+        for (n = 0; mc->targets && mc->targets[n] != SYS_EMU_TARGET__MAX; n++) {
+            QAPI_LIST_APPEND(tgts, mc->targets[n]);
+        }
         info->acpi = !!object_class_property_find(OBJECT_CLASS(mc), "acpi");
         if (default_cpu_type) {
             info->default_cpu_type = g_strdup(default_cpu_type);
diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h
index a436d48c8e..436eb9fe84 100644
--- a/include/hw/core/boards.h
+++ b/include/hw/core/boards.h
@@ -322,6 +322,8 @@ struct MachineClass {
     SMPCompatProps smp_props;
     const char *default_ram_id;
 
+    SysEmuTarget *targets;
+
     HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
                                            DeviceState *dev);
     bool (*hotplug_allowed)(MachineState *state, DeviceState *dev,


This MachineInfo QAPI type is how to report other key information
about the machine classes.

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

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote:
>> Device filtering would be complicated, I guess, as there is so much
>> CONFIG_* for devices. Another approach is to just place devices under an
>> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
>> listed(memory consumption will also be reduced when it's not needed).
>
> While modules are important for reducing memory consumption, I don't think
> they need to be a blocker - making more things into modules can be done
> in the backaround as & when people want to work on it.

I fear modules need serious work to before we can use them more widely.
I described issues in

    Subject: Dynamic & heterogeneous machines, initial configuration: problems
    Date: Wed, 31 Jan 2024 21:14:21 +0100
    Message-ID: <87o7d1i7ky.fsf@pond.sub.org>
    https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/

Copy of relevant part:

= Problem 3: Loadable modules =

QOM wasn't designed for loadable modules.  Support for them was grafted
on, and there are serious deficiencies.

Building a loadable module results in a DSO.  Additionally, module
meta-data necessary to load it is compiled into the executables that can
load modules.  Actually loading a module can fail, e.g. when the module
was not deployed.

Loadable modules are designed to be transparent, i.e. users don't need
to know whether a module is compiled in or loadable.

QOM types don't exist until the module is initialized.  Compiled-in
modules are initialized early in startup.  Loadable modules are
initialized on load.

QMP command qom-list-types returns all QOM types.  To be able to find
them all, it needs to load all modules.  Modules that cannot be found
(or have dependencies that cannot be found) are silently ignored.  Any
other loading errors are reported to stderr with error_report_err(),
which is inappropriate.  In either case, the types provided by the
unloadable modules are not returned by the command.

We have two functions to look up an object class by name:
object_class_by_name() and module_object_class_by_name().  The latter
attempts to load a module when the type doesn't exist.  Again, modules
that cannot be found are silently ignored, and other loading errors are
reported with error_report_err(), which is inappropriate in certain
contexts.

When to use which of the two functions is unclear.  Existing usage may
well be wrong.

The QOM functions to create objects in-place (object_initialize(), ...)
or on the heap (object_new(), ...) cannot fail.  This is just fine in
QOM's original design.  It is not fine when a loadable module fails to
load.  Since the functions can't fail, they exit(1) then.

This means things like a hot plugging a device provided by a loadable
module can crash a VM immediately.

Attempting to load all modules beforehand with qom-list-types does not
protect against this: we try to load again, fail again, and exit(1).

On Fri, Sep 04, 2026 at 01:25:23PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote:
> >> Device filtering would be complicated, I guess, as there is so much
> >> CONFIG_* for devices. Another approach is to just place devices under an
> >> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
> >> listed(memory consumption will also be reduced when it's not needed).
> >
> > While modules are important for reducing memory consumption, I don't think
> > they need to be a blocker - making more things into modules can be done
> > in the backaround as & when people want to work on it.
> 
> I fear modules need serious work to before we can use them more widely.
> I described issues in
> 
>     Subject: Dynamic & heterogeneous machines, initial configuration: problems
>     Date: Wed, 31 Jan 2024 21:14:21 +0100
>     Message-ID: <87o7d1i7ky.fsf@pond.sub.org>
>     https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/
> 
> Copy of relevant part:
> 
> = Problem 3: Loadable modules =
> 
> QOM wasn't designed for loadable modules.  Support for them was grafted
> on, and there are serious deficiencies.
> 
> Building a loadable module results in a DSO.  Additionally, module
> meta-data necessary to load it is compiled into the executables that can
> load modules.  Actually loading a module can fail, e.g. when the module
> was not deployed.
> 
> Loadable modules are designed to be transparent, i.e. users don't need
> to know whether a module is compiled in or loadable.
> 
> QOM types don't exist until the module is initialized.  Compiled-in
> modules are initialized early in startup.  Loadable modules are
> initialized on load.
> 
> QMP command qom-list-types returns all QOM types.  To be able to find
> them all, it needs to load all modules.  Modules that cannot be found
> (or have dependencies that cannot be found) are silently ignored.  Any
> other loading errors are reported to stderr with error_report_err(),
> which is inappropriate.  In either case, the types provided by the
> unloadable modules are not returned by the command.
> 
> We have two functions to look up an object class by name:
> object_class_by_name() and module_object_class_by_name().  The latter
> attempts to load a module when the type doesn't exist.  Again, modules
> that cannot be found are silently ignored, and other loading errors are
> reported with error_report_err(), which is inappropriate in certain
> contexts.
> 
> When to use which of the two functions is unclear.  Existing usage may
> well be wrong.
> 
> The QOM functions to create objects in-place (object_initialize(), ...)
> or on the heap (object_new(), ...) cannot fail.  This is just fine in
> QOM's original design.  It is not fine when a loadable module fails to
> load.  Since the functions can't fail, they exit(1) then.
> 
> This means things like a hot plugging a device provided by a loadable
> module can crash a VM immediately.

The object_new() side effect is unpleasant, but we're not all that
far away from avoiding the crash on device hotplug AFAICT.

qdev_device_add_from_qdict() will call qdev_get_device_class() and
if that returns NULL will gracefully return the error to the client.

qdev_get_device_class() will call module_object_class_by_name()
which triggers module loading and can return NULL if loading
fails. Unfortnuately it throws away the error message, and
qdev_get_device_class() doesn't appear to handle NULL correctly
in all scenarios. It is not that far away from being able to
handle module load failures correctly though AFAICS.

The unpleasant bit is that we would need to audit other QMP entry
points that can trigger module loading, and ensure they all trigger
module loading prior to object_new(), and perhaps most importantly
have a way to test this in functional tests. Without the latter
we'll surely bit-rot this subtle edgecase.

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 Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com> wrote:
> On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > I'm still not clear on why we need to filter the devices at all for
> > a new "qemu-system" binary ?
> >
> > Looking at the device delta listed in your other mail, a large number
> > of those are PCI based. The microblaze machine types don't expose a
> > PCI controller, so those PCI devices are redundant / won't be used
> > with microblaze machines, which is why existing qemu-system-microblaze
> > doesn't link to those devices.
> >
> > The same is true of many of the arm machines too though. Only a subset
> > of arm machines have PCI, but the qemu-system-arm binary still includes
> > and lists all these PCI devices. Users simply can't create a PCI device
> > for the arm machines that lack a PCI controller, or they'll receive an
> > error.
> >
> > Why doesn't this approach extend into the future qemu-system binary ?
> > List everything, and if the user tries to add a device that's not
> > compatible with a machine, then it will simply result in an error.
>
> Device filtering would be complicated, I guess, as there is so much CONFIG_* for devices. Another approach is to just place devices under an meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be listed(memory consumption will also be reduced when it's not needed).
>
> But machine listings still need the filtering, considering virt is present for many different arches(riscv/arm/i686). so machine listing is still a thing.

I was wondering if maybe one way to approach that is some
"disambiguation" syntax on the machine name; so one could write
"-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
disambiguate when just "-machine virt" would be ambiguous; but if
there's only one machine of that name then just "-machine foo" would
work. That extends nicely to truly heterogenous machine names:
"-machine my-mixed-machine" wouldn't need the user to explicitly
give it a -target option or otherwise say that it includes aarch64
and microblaze CPUs. (We'd probably need to put something in to
prevent future machine name clashes across targets, so that the
only clashes are our existing legacy ones.)

This rests on the assumption that the only thing we need to
disambiguate is machine names, i.e. there aren't multiple
targets with user-facing (i.e. not easily renameable) device
names that are shared.

-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> I was wondering if maybe one way to approach that is some
> "disambiguation" syntax on the machine name; so one could write
> "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> disambiguate when just "-machine virt" would be ambiguous; but if
> there's only one machine of that name then just "-machine foo" would
> work. That extends nicely to truly heterogenous machine names:
> "-machine my-mixed-machine" wouldn't need the user to explicitly
> give it a -target option or otherwise say that it includes aarch64
> and microblaze CPUs. (We'd probably need to put something in to
> prevent future machine name clashes across targets, so that the
> only clashes are our existing legacy ones.)

Do we need new syntax?

Rename the clashing machine types, keeping the old name as alias.  When
getting a machine by name, require the name to be unambiguous.

> This rests on the assumption that the only thing we need to
> disambiguate is machine names, i.e. there aren't multiple
> targets with user-facing (i.e. not easily renameable) device
> names that are shared.

On Fri, Sep 04, 2026 at 01:01:03PM +0200, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > I was wondering if maybe one way to approach that is some
> > "disambiguation" syntax on the machine name; so one could write
> > "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> > disambiguate when just "-machine virt" would be ambiguous; but if
> > there's only one machine of that name then just "-machine foo" would
> > work. That extends nicely to truly heterogenous machine names:
> > "-machine my-mixed-machine" wouldn't need the user to explicitly
> > give it a -target option or otherwise say that it includes aarch64
> > and microblaze CPUs. (We'd probably need to put something in to
> > prevent future machine name clashes across targets, so that the
> > only clashes are our existing legacy ones.)
> 
> Do we need new syntax?
> 
> Rename the clashing machine types, keeping the old name as alias.  When
> getting a machine by name, require the name to be unambiguous.

This probably requires us to support more than 1 alias per machine.

Specifically with aarch64 we have:

  virt                 QEMU 11.2 ARM Virtual Machine (alias of virt-11.2)

so we need to rename "virt-11.2" but have already used its "alias"
feature for "virt", which would also need renaming

ie we would need

  arm-virt-11.2

with aliases

    virt-11.2
    arm-virt
    virt

So is it better to extend the alias feature, or have the new -machine
syntax ? 

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 Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> On Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com> wrote:
> > On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > I'm still not clear on why we need to filter the devices at all for
> > > a new "qemu-system" binary ?
> > >
> > > Looking at the device delta listed in your other mail, a large number
> > > of those are PCI based. The microblaze machine types don't expose a
> > > PCI controller, so those PCI devices are redundant / won't be used
> > > with microblaze machines, which is why existing qemu-system-microblaze
> > > doesn't link to those devices.
> > >
> > > The same is true of many of the arm machines too though. Only a subset
> > > of arm machines have PCI, but the qemu-system-arm binary still includes
> > > and lists all these PCI devices. Users simply can't create a PCI device
> > > for the arm machines that lack a PCI controller, or they'll receive an
> > > error.
> > >
> > > Why doesn't this approach extend into the future qemu-system binary ?
> > > List everything, and if the user tries to add a device that's not
> > > compatible with a machine, then it will simply result in an error.
> >
> > Device filtering would be complicated, I guess, as there is so much CONFIG_* for devices. Another approach is to just place devices under an meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be listed(memory consumption will also be reduced when it's not needed).
> >
> > But machine listings still need the filtering, considering virt is present for many different arches(riscv/arm/i686). so machine listing is still a thing.
> 
> I was wondering if maybe one way to approach that is some
> "disambiguation" syntax on the machine name; so one could write
> "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> disambiguate when just "-machine virt" would be ambiguous; but if
> there's only one machine of that name then just "-machine foo" would
> work.

Currently the QOM type name is directly derived from the machine
type name, just with a "-machine" suffix attached. So if the
machine name is not unique, then neither is the QOM type name.

At the very least we need the QOM type name to be unique. We
could de-couple the two to make this work though, which does
not seem too hard.

>       That extends nicely to truly heterogenous machine names:
> "-machine my-mixed-machine" wouldn't need the user to explicitly
> give it a -target option or otherwise say that it includes aarch64
> and microblaze CPUs. (We'd probably need to put something in to
> prevent future machine name clashes across targets, so that the
> only clashes are our existing legacy ones.)

We don't have many examples of clashing machine names. Is there
any beyond just the 'virt' boards ? Now that we know we want
globally unique names, this feels easy enough to spot during
review.

> This rests on the assumption that the only thing we need to
> disambiguate is machine names, i.e. there aren't multiple
> targets with user-facing (i.e. not easily renameable) device
> names that are shared.

IMHO it is best if our goal is to ensure type names are unique
throughout the codebase, so hopefully we don't have clashing
device names.

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

Daniel P. Berrangé <berrange@redhat.com> writes:

> Currently the QOM type name is directly derived from the machine
> type name, just with a "-machine" suffix attached. So if the
> machine name is not unique, then neither is the QOM type name.
>
> At the very least we need the QOM type name to be unique. We
> could de-couple the two to make this work though, which does
> not seem too hard.

[...]

> We don't have many examples of clashing machine names. Is there
> any beyond just the 'virt' boards ? Now that we know we want
> globally unique names, this feels easy enough to spot during
> review.

I checked -machine help for all qemu-system-T, and it seems to be just
"none", "virt" and "virt-VERSION", not counting duplicates between
architecture variants such as aarch64 and arm, x86_64 and i386, and so
forth.

>> This rests on the assumption that the only thing we need to
>> disambiguate is machine names, i.e. there aren't multiple
>> targets with user-facing (i.e. not easily renameable) device
>> names that are shared.
>
> IMHO it is best if our goal is to ensure type names are unique
> throughout the codebase, so hopefully we don't have clashing
> device names.

Yes.

Quick glance at type_new():

    if (type_table_lookup(info->name) != NULL) {
        fprintf(stderr, "Registering `%s' which already exists\n", info->name);
        abort();
    }

If we have duplicate type names, they won't survive being linked
together in a single binary.

On Fri, Sep 04, 2026 at 01:19:19PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > Currently the QOM type name is directly derived from the machine
> > type name, just with a "-machine" suffix attached. So if the
> > machine name is not unique, then neither is the QOM type name.
> >
> > At the very least we need the QOM type name to be unique. We
> > could de-couple the two to make this work though, which does
> > not seem too hard.
> 
> [...]
> 
> > We don't have many examples of clashing machine names. Is there
> > any beyond just the 'virt' boards ? Now that we know we want
> > globally unique names, this feels easy enough to spot during
> > review.
> 
> I checked -machine help for all qemu-system-T, and it seems to be just
> "none", "virt" and "virt-VERSION", not counting duplicates between
> architecture variants such as aarch64 and arm, x86_64 and i386, and so
> forth.
> 
> >> This rests on the assumption that the only thing we need to
> >> disambiguate is machine names, i.e. there aren't multiple
> >> targets with user-facing (i.e. not easily renameable) device
> >> names that are shared.
> >
> > IMHO it is best if our goal is to ensure type names are unique
> > throughout the codebase, so hopefully we don't have clashing
> > device names.
> 
> Yes.
> 
> Quick glance at type_new():
> 
>     if (type_table_lookup(info->name) != NULL) {
>         fprintf(stderr, "Registering `%s' which already exists\n", info->name);
>         abort();
>     }
> 
> If we have duplicate type names, they won't survive being linked
> together in a single binary.

If we want perfect testing coverage, then the main constraint here
is how quickly we get to a point where 'qemu-system' can build with
all targets. I don't that's a show stopper though, as the uniqueness
only becomes a real problem as we enable each new target in the single
binary. We don't appear to have many examples of existing clashes to
suggest it is a major problem to solve any sooner.

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

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Sep 04, 2026 at 01:19:19PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:

[...]

>> > IMHO it is best if our goal is to ensure type names are unique
>> > throughout the codebase, so hopefully we don't have clashing
>> > device names.
>> 
>> Yes.
>> 
>> Quick glance at type_new():
>> 
>>     if (type_table_lookup(info->name) != NULL) {
>>         fprintf(stderr, "Registering `%s' which already exists\n", info->name);
>>         abort();
>>     }
>> 
>> If we have duplicate type names, they won't survive being linked
>> together in a single binary.
>
> If we want perfect testing coverage, then the main constraint here
> is how quickly we get to a point where 'qemu-system' can build with
> all targets. I don't that's a show stopper though, as the uniqueness
> only becomes a real problem as we enable each new target in the single
> binary. We don't appear to have many examples of existing clashes to
> suggest it is a major problem to solve any sooner.

Agree!

On 4/9/26 13:55, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
>> On Fri, Sep 04, 2026 at 01:19:19PM +0200, Markus Armbruster wrote:
>>> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> [...]
> 
>>>> IMHO it is best if our goal is to ensure type names are unique
>>>> throughout the codebase, so hopefully we don't have clashing
>>>> device names.
>>>
>>> Yes.
>>>
>>> Quick glance at type_new():
>>>
>>>      if (type_table_lookup(info->name) != NULL) {
>>>          fprintf(stderr, "Registering `%s' which already exists\n", info->name);
>>>          abort();
>>>      }
>>>
>>> If we have duplicate type names, they won't survive being linked
>>> together in a single binary.
>>
>> If we want perfect testing coverage, then the main constraint here
>> is how quickly we get to a point where 'qemu-system' can build with
>> all targets. I don't that's a show stopper though, as the uniqueness
>> only becomes a real problem as we enable each new target in the single
>> binary. We don't appear to have many examples of existing clashes to
>> suggest it is a major problem to solve any sooner.

The only thing I see useful for a 'qemu-system' binary is to report
"sorry must be run with -target foo" then either have a script for
each qemu-system-foo which call 'qemu-system -target foo' or use
symlink and parse argv. No need to alter the test suite at all.

On Fri, 4 Sept 2026 at 10:55, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> >       That extends nicely to truly heterogenous machine names:
> > "-machine my-mixed-machine" wouldn't need the user to explicitly
> > give it a -target option or otherwise say that it includes aarch64
> > and microblaze CPUs. (We'd probably need to put something in to
> > prevent future machine name clashes across targets, so that the
> > only clashes are our existing legacy ones.)
>
> We don't have many examples of clashing machine names. Is there
> any beyond just the 'virt' boards ? Now that we know we want
> globally unique names, this feels easy enough to spot during
> review.

Yeah; but if it's easy to have it automatically detected during
"make check" then that's more reliable than catching it by
eye in code review, especially as most target-architecture
reviewers are probably not very familiar with machine names used
by other architectures.

> > This rests on the assumption that the only thing we need to
> > disambiguate is machine names, i.e. there aren't multiple
> > targets with user-facing (i.e. not easily renameable) device
> > names that are shared.
>
> IMHO it is best if our goal is to ensure type names are unique
> throughout the codebase, so hopefully we don't have clashing
> device names.

Yes, that's certainly what I'd hope we have; but if you told
me "actually it turns out that architectures foo and bar
both have a simple interrupt controller they named 'intc'"
I wouldn't be super surprised :-)

-- PMM

On Fri, Sep 04, 2026 at 11:23:12AM +0100, Peter Maydell wrote:
> On Fri, 4 Sept 2026 at 10:55, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> > >       That extends nicely to truly heterogenous machine names:
> > > "-machine my-mixed-machine" wouldn't need the user to explicitly
> > > give it a -target option or otherwise say that it includes aarch64
> > > and microblaze CPUs. (We'd probably need to put something in to
> > > prevent future machine name clashes across targets, so that the
> > > only clashes are our existing legacy ones.)
> >
> > We don't have many examples of clashing machine names. Is there
> > any beyond just the 'virt' boards ? Now that we know we want
> > globally unique names, this feels easy enough to spot during
> > review.
> 
> Yeah; but if it's easy to have it automatically detected during
> "make check" then that's more reliable than catching it by
> eye in code review, especially as most target-architecture
> reviewers are probably not very familiar with machine names used
> by other architectures.
> 
> > > This rests on the assumption that the only thing we need to
> > > disambiguate is machine names, i.e. there aren't multiple
> > > targets with user-facing (i.e. not easily renameable) device
> > > names that are shared.
> >
> > IMHO it is best if our goal is to ensure type names are unique
> > throughout the codebase, so hopefully we don't have clashing
> > device names.
> 
> Yes, that's certainly what I'd hope we have; but if you told
> me "actually it turns out that architectures foo and bar
> both have a simple interrupt controller they named 'intc'"
> I wouldn't be super surprised :-)

With a bit of grepping for TypeInfo declarations and TYPE_ constants
I found on possible clash in "openprom" which is defined separately
for sparc sun4m and sparc64 sun4u machines. Possibly those ought to
be using some common parent, but since they're built-in devices we
can likely just rename them to be unique.


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 Fri, Sep 4, 2026 at 5:55 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
>
> On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> > On Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com>
wrote:
> > > On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
> > > > I'm still not clear on why we need to filter the devices at all for
> > > > a new "qemu-system" binary ?
> > > >
> > > > Looking at the device delta listed in your other mail, a large
number
> > > > of those are PCI based. The microblaze machine types don't expose a
> > > > PCI controller, so those PCI devices are redundant / won't be used
> > > > with microblaze machines, which is why existing
qemu-system-microblaze
> > > > doesn't link to those devices.
> > > >
> > > > The same is true of many of the arm machines too though. Only a
subset
> > > > of arm machines have PCI, but the qemu-system-arm binary still
includes
> > > > and lists all these PCI devices. Users simply can't create a PCI
device
> > > > for the arm machines that lack a PCI controller, or they'll receive
an
> > > > error.
> > > >
> > > > Why doesn't this approach extend into the future qemu-system binary
?
> > > > List everything, and if the user tries to add a device that's not
> > > > compatible with a machine, then it will simply result in an error.
> > >
> > > Device filtering would be complicated, I guess, as there is so much
CONFIG_* for devices. Another approach is to just place devices under an
meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
listed(memory consumption will also be reduced when it's not needed).
> > >
> > > But machine listings still need the filtering, considering virt is
present for many different arches(riscv/arm/i686). so machine listing is
still a thing.
> >
> > I was wondering if maybe one way to approach that is some
> > "disambiguation" syntax on the machine name; so one could write
> > "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> > disambiguate when just "-machine virt" would be ambiguous; but if
> > there's only one machine of that name then just "-machine foo" would
> > work.
>
> Currently the QOM type name is directly derived from the machine
> type name, just with a "-machine" suffix attached. So if the
> machine name is not unique, then neither is the QOM type name.
>
> At the very least we need the QOM type name to be unique. We
> could de-couple the two to make this work though, which does
> not seem too hard.

I have did that, for example:
 hw/riscv/virt.c         | 3 ++-
 include/hw/riscv/virt.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index dd396410178..5e57f9443c2 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1739,6 +1739,7 @@ static void virt_machine_class_init(ObjectClass *oc,
const void *data)
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);

     mc->desc = "RISC-V VirtIO board";
+    machine_class_set_name(mc, "virt");
     mc->init = virt_machine_init;
     mc->max_cpus = VIRT_CPUS_MAX;
     mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
@@ -1802,7 +1803,7 @@ static void virt_machine_class_init(ObjectClass *oc,
const void *data)
 }

 static const TypeInfo virt_machine_typeinfo = {
-    .name       = MACHINE_TYPE_NAME("virt"),
+    .name       = TYPE_RISCV_VIRT_MACHINE,
     .parent     = TYPE_MACHINE,
     .class_init = virt_machine_class_init,
     .instance_init = virt_machine_instance_init,
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index 7c862b0da25..9f96dd98c6a 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -30,7 +30,7 @@
 #define VIRT_SOCKETS_MAX_BITS          2
 #define VIRT_SOCKETS_MAX               (1 << VIRT_SOCKETS_MAX_BITS)

-#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
+#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("riscv-virt")
 typedef struct RISCVVirtState RISCVVirtState;
 DECLARE_INSTANCE_CHECKER(RISCVVirtState, RISCV_VIRT_MACHINE,
                          TYPE_RISCV_VIRT_MACHINE)


Maybe we have a better way for it?

For device conflict, that needs to be detected after the qemu-system is
present.


>
> >       That extends nicely to truly heterogenous machine names:
> > "-machine my-mixed-machine" wouldn't need the user to explicitly
> > give it a -target option or otherwise say that it includes aarch64
> > and microblaze CPUs. (We'd probably need to put something in to
> > prevent future machine name clashes across targets, so that the
> > only clashes are our existing legacy ones.)
>
> We don't have many examples of clashing machine names. Is there
> any beyond just the 'virt' boards ? Now that we know we want
> globally unique names, this feels easy enough to spot during
> review.
>
> > This rests on the assumption that the only thing we need to
> > disambiguate is machine names, i.e. there aren't multiple
> > targets with user-facing (i.e. not easily renameable) device
> > names that are shared.
>
> IMHO it is best if our goal is to ensure type names are unique
> throughout the codebase, so hopefully we don't have clashing
> device names.
>
> 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 Fri, Sep 04, 2026 at 06:04:24PM +0800, Yonggang Luo wrote:
> On Fri, Sep 4, 2026 at 5:55 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> >
> > On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> > > On Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com>
> wrote:
> > > > On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> > > > > I'm still not clear on why we need to filter the devices at all for
> > > > > a new "qemu-system" binary ?
> > > > >
> > > > > Looking at the device delta listed in your other mail, a large
> number
> > > > > of those are PCI based. The microblaze machine types don't expose a
> > > > > PCI controller, so those PCI devices are redundant / won't be used
> > > > > with microblaze machines, which is why existing
> qemu-system-microblaze
> > > > > doesn't link to those devices.
> > > > >
> > > > > The same is true of many of the arm machines too though. Only a
> subset
> > > > > of arm machines have PCI, but the qemu-system-arm binary still
> includes
> > > > > and lists all these PCI devices. Users simply can't create a PCI
> device
> > > > > for the arm machines that lack a PCI controller, or they'll receive
> an
> > > > > error.
> > > > >
> > > > > Why doesn't this approach extend into the future qemu-system binary
> ?
> > > > > List everything, and if the user tries to add a device that's not
> > > > > compatible with a machine, then it will simply result in an error.
> > > >
> > > > Device filtering would be complicated, I guess, as there is so much
> CONFIG_* for devices. Another approach is to just place devices under an
> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
> listed(memory consumption will also be reduced when it's not needed).
> > > >
> > > > But machine listings still need the filtering, considering virt is
> present for many different arches(riscv/arm/i686). so machine listing is
> still a thing.
> > >
> > > I was wondering if maybe one way to approach that is some
> > > "disambiguation" syntax on the machine name; so one could write
> > > "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> > > disambiguate when just "-machine virt" would be ambiguous; but if
> > > there's only one machine of that name then just "-machine foo" would
> > > work.
> >
> > Currently the QOM type name is directly derived from the machine
> > type name, just with a "-machine" suffix attached. So if the
> > machine name is not unique, then neither is the QOM type name.
> >
> > At the very least we need the QOM type name to be unique. We
> > could de-couple the two to make this work though, which does
> > not seem too hard.
> 
> I have did that, for example:
>  hw/riscv/virt.c         | 3 ++-
>  include/hw/riscv/virt.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index dd396410178..5e57f9443c2 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1739,6 +1739,7 @@ static void virt_machine_class_init(ObjectClass *oc,
> const void *data)
>      HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
> 
>      mc->desc = "RISC-V VirtIO board";
> +    machine_class_set_name(mc, "virt");
>      mc->init = virt_machine_init;
>      mc->max_cpus = VIRT_CPUS_MAX;
>      mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
> @@ -1802,7 +1803,7 @@ static void virt_machine_class_init(ObjectClass *oc,
> const void *data)
>  }
> 
>  static const TypeInfo virt_machine_typeinfo = {
> -    .name       = MACHINE_TYPE_NAME("virt"),
> +    .name       = TYPE_RISCV_VIRT_MACHINE,
>      .parent     = TYPE_MACHINE,
>      .class_init = virt_machine_class_init,
>      .instance_init = virt_machine_instance_init,
> diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
> index 7c862b0da25..9f96dd98c6a 100644
> --- a/include/hw/riscv/virt.h
> +++ b/include/hw/riscv/virt.h
> @@ -30,7 +30,7 @@
>  #define VIRT_SOCKETS_MAX_BITS          2
>  #define VIRT_SOCKETS_MAX               (1 << VIRT_SOCKETS_MAX_BITS)
> 
> -#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
> +#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("riscv-virt")
>  typedef struct RISCVVirtState RISCVVirtState;
>  DECLARE_INSTANCE_CHECKER(RISCVVirtState, RISCV_VIRT_MACHINE,
>                           TYPE_RISCV_VIRT_MACHINE)
> 
> 
> Maybe we have a better way for it?
> 
> For device conflict, that needs to be detected after the qemu-system is
> present.

Our existing qom-test should already be validate that in fact, if we
run them against the qemu-system binary, aas it'll start
'qemu-system -machine none' and list all QOM types & properties,
at least for the targets & associated devices that we have converted
to work with 'qemu-system'. Best coverage would require all targets
to be converted but we don't have to get there straightaway.

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 4/9/26 12:11, Daniel P. Berrangé wrote:
> On Fri, Sep 04, 2026 at 06:04:24PM +0800, Yonggang Luo wrote:
>> On Fri, Sep 4, 2026 at 5:55 PM Daniel P. Berrangé <berrange@redhat.com>
>> wrote:
>>>
>>> On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
>>>> On Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com>
>> wrote:
>>>>> On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
>> wrote:
>>>>>> I'm still not clear on why we need to filter the devices at all for
>>>>>> a new "qemu-system" binary ?
>>>>>>
>>>>>> Looking at the device delta listed in your other mail, a large
>> number
>>>>>> of those are PCI based. The microblaze machine types don't expose a
>>>>>> PCI controller, so those PCI devices are redundant / won't be used
>>>>>> with microblaze machines, which is why existing
>> qemu-system-microblaze
>>>>>> doesn't link to those devices.
>>>>>>
>>>>>> The same is true of many of the arm machines too though. Only a
>> subset
>>>>>> of arm machines have PCI, but the qemu-system-arm binary still
>> includes
>>>>>> and lists all these PCI devices. Users simply can't create a PCI
>> device
>>>>>> for the arm machines that lack a PCI controller, or they'll receive
>> an
>>>>>> error.
>>>>>>
>>>>>> Why doesn't this approach extend into the future qemu-system binary
>> ?
>>>>>> List everything, and if the user tries to add a device that's not
>>>>>> compatible with a machine, then it will simply result in an error.
>>>>>
>>>>> Device filtering would be complicated, I guess, as there is so much
>> CONFIG_* for devices. Another approach is to just place devices under an
>> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
>> listed(memory consumption will also be reduced when it's not needed).
>>>>>
>>>>> But machine listings still need the filtering, considering virt is
>> present for many different arches(riscv/arm/i686). so machine listing is
>> still a thing.
>>>>
>>>> I was wondering if maybe one way to approach that is some
>>>> "disambiguation" syntax on the machine name; so one could write
>>>> "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
>>>> disambiguate when just "-machine virt" would be ambiguous; but if
>>>> there's only one machine of that name then just "-machine foo" would
>>>> work.
>>>
>>> Currently the QOM type name is directly derived from the machine
>>> type name, just with a "-machine" suffix attached. So if the
>>> machine name is not unique, then neither is the QOM type name.
>>>
>>> At the very least we need the QOM type name to be unique. We
>>> could de-couple the two to make this work though, which does
>>> not seem too hard.
>>
>> I have did that, for example:
>>   hw/riscv/virt.c         | 3 ++-
>>   include/hw/riscv/virt.h | 2 +-
>>   2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
>> index dd396410178..5e57f9443c2 100644
>> --- a/hw/riscv/virt.c
>> +++ b/hw/riscv/virt.c
>> @@ -1739,6 +1739,7 @@ static void virt_machine_class_init(ObjectClass *oc,
>> const void *data)
>>       HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
>>
>>       mc->desc = "RISC-V VirtIO board";
>> +    machine_class_set_name(mc, "virt");
>>       mc->init = virt_machine_init;
>>       mc->max_cpus = VIRT_CPUS_MAX;
>>       mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
>> @@ -1802,7 +1803,7 @@ static void virt_machine_class_init(ObjectClass *oc,
>> const void *data)
>>   }
>>
>>   static const TypeInfo virt_machine_typeinfo = {
>> -    .name       = MACHINE_TYPE_NAME("virt"),
>> +    .name       = TYPE_RISCV_VIRT_MACHINE,
>>       .parent     = TYPE_MACHINE,
>>       .class_init = virt_machine_class_init,
>>       .instance_init = virt_machine_instance_init,
>> diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
>> index 7c862b0da25..9f96dd98c6a 100644
>> --- a/include/hw/riscv/virt.h
>> +++ b/include/hw/riscv/virt.h
>> @@ -30,7 +30,7 @@
>>   #define VIRT_SOCKETS_MAX_BITS          2
>>   #define VIRT_SOCKETS_MAX               (1 << VIRT_SOCKETS_MAX_BITS)
>>
>> -#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
>> +#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("riscv-virt")
>>   typedef struct RISCVVirtState RISCVVirtState;
>>   DECLARE_INSTANCE_CHECKER(RISCVVirtState, RISCV_VIRT_MACHINE,
>>                            TYPE_RISCV_VIRT_MACHINE)
>>
>>
>> Maybe we have a better way for it?
>>
>> For device conflict, that needs to be detected after the qemu-system is
>> present.
> 
> Our existing qom-test should already be validate that in fact, if we
> run them against the qemu-system binary, aas it'll start
> 'qemu-system -machine none' and list all QOM types & properties,
> at least for the targets & associated devices that we have converted
> to work with 'qemu-system'. Best coverage would require all targets
> to be converted but we don't have to get there straightaway.

I feel the whole series discussion derailed. Can we start a new design
thread to clarify what people want? Apparently we don't refer to the
same understanding of what "qemu-system" binary is or aim for.

> I was wondering if maybe one way to approach that is some
> "disambiguation" syntax on the machine name; so one could write
> "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to

That's the Proposal B: target only in -M or argv[0] (alternative)
Do not add -target. The target is always embedded in the machine
argument, or inferred from argv[0].

- qemu-system-aarch64 -M virt: single-target from argv[0].
- qemu-system -M arm:virt: single-target from -M.
- qemu-system -M virt: error (heterogeneous not supported yet).

There is no global option that selects TargetInfo before -M.
Early option parsing still has to read -M (and argv[0]) before
machines initialize, the same as proposal A reads -target.

  qemu-system -M help
  qemu-system -M virt              # error: heterogeneous not supported
  qemu-system -M arm:virt ...
  qemu-system -M aarch64:virt,gic-version=3 ...
  qemu-system-riscv64 -M virt ...

at:
https://lore.kernel.org/qemu-devel/CAE2XoE_-ewv3iC_MZ2sM1eKG=CUKM7MZa-ppJV0Vk1rE1h+19w@mail.gmail.com/


> disambiguate when just "-machine virt" would be ambiguous; but if
> there's only one machine of that name then just "-machine foo" would
> work. That extends nicely to truly heterogeneous machine names:
> "-machine my-mixed-machine" wouldn't need the user to explicitly
> give it a -target option or otherwise say that it includes aarch64


Seems this direction is fine, May I post experiment patches with this
direction?
The machine-filtering is still needed. and when the target is not specified
by machine parameter. The default TargetInfo will be target
SYS_EMU_TARGET_NONE. And it means emulating heterogeneous machines.

> and microblaze CPUs. (We'd probably need to put something in to
> prevent future machine name clashes across targets, so that the
> only clashes are our existing legacy ones.)
>
> This rests on the assumption that the only thing we need to
> disambiguate is machine names, i.e. there aren't multiple
> targets with user-facing (i.e. not easily renameable) device
> names that are shared.
>
> -- PMM



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

On Fri, 4 Sept 2026 at 10:34, Yonggang Luo <luoyonggang@gmail.com> wrote:
>
>
> > I was wondering if maybe one way to approach that is some
> > "disambiguation" syntax on the machine name; so one could write
> > "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
>
> That's the Proposal B: target only in -M or argv[0] (alternative)
> Do not add -target. The target is always embedded in the machine
> argument, or inferred from argv[0].
>
> - qemu-system-aarch64 -M virt: single-target from argv[0].
> - qemu-system -M arm:virt: single-target from -M.
> - qemu-system -M virt: error (heterogeneous not supported yet).
>
> There is no global option that selects TargetInfo before -M.
> Early option parsing still has to read -M (and argv[0]) before
> machines initialize, the same as proposal A reads -target.
>
>   qemu-system -M help
>   qemu-system -M virt              # error: heterogeneous not supported

This should be an error because it's ambiguous (and ideally
the error could include listing the possible candidates, like
"Did you mean 'riscv64:virt' or 'aarch64:virt' or 'arm:virt' ?"),
not because of anything to do with heterogenous machines. For
instance there's no reason
    qemu-system -M vexpress-a9
couldn't work without a "arm:" disambiguator, as there's only one
"vexpress-a9" machine across all our target archs.

>   qemu-system -M arm:virt ...
>   qemu-system -M aarch64:virt,gic-version=3 ...
>   qemu-system-riscv64 -M virt ...
>
> at:
> https://lore.kernel.org/qemu-devel/CAE2XoE_-ewv3iC_MZ2sM1eKG=CUKM7MZa-ppJV0Vk1rE1h+19w@mail.gmail.com/
>
>
> > disambiguate when just "-machine virt" would be ambiguous; but if
> > there's only one machine of that name then just "-machine foo" would
> > work. That extends nicely to truly heterogeneous machine names:
> > "-machine my-mixed-machine" wouldn't need the user to explicitly
> > give it a -target option or otherwise say that it includes aarch64
>
>
> Seems this direction is fine, May I post experiment patches with this direction?
> The machine-filtering is still needed. and when the target is not specified by machine parameter. The default TargetInfo will be target
> SYS_EMU_TARGET_NONE. And it means emulating heterogeneous machines.

I think we could also let the default (no target specified) work
for non-heterogenous machines, as noted above.

-- PMM

On 4/9/26 11:41, Peter Maydell wrote:
> On Fri, 4 Sept 2026 at 10:34, Yonggang Luo <luoyonggang@gmail.com> wrote:
>>
>>
>>> I was wondering if maybe one way to approach that is some
>>> "disambiguation" syntax on the machine name; so one could write
>>> "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
>>
>> That's the Proposal B: target only in -M or argv[0] (alternative)
>> Do not add -target. The target is always embedded in the machine
>> argument, or inferred from argv[0].
>>
>> - qemu-system-aarch64 -M virt: single-target from argv[0].
>> - qemu-system -M arm:virt: single-target from -M.
>> - qemu-system -M virt: error (heterogeneous not supported yet).
>>
>> There is no global option that selects TargetInfo before -M.
>> Early option parsing still has to read -M (and argv[0]) before
>> machines initialize, the same as proposal A reads -target.
>>
>>    qemu-system -M help
>>    qemu-system -M virt              # error: heterogeneous not supported
> 
> This should be an error because it's ambiguous (and ideally
> the error could include listing the possible candidates, like
> "Did you mean 'riscv64:virt' or 'aarch64:virt' or 'arm:virt' ?"),
> not because of anything to do with heterogenous machines. For
> instance there's no reason
>      qemu-system -M vexpress-a9
> couldn't work without a "arm:" disambiguator, as there's only one
> "vexpress-a9" machine across all our target archs.
> 
>>    qemu-system -M arm:virt ...
>>    qemu-system -M aarch64:virt,gic-version=3 ...

I don't understand why we are discussing the CLI options and machine
names in qemu-system when nobody has a clue what qemu-system is for.

The overall discussion gives the impression qemu-system will be
helpful toward heterogenous emulation, but this is the opposite,
it hinder our work. We have identified many core problems in
QEMU APIs and planned to fixed them when needed (because too many
issues) and only expose heterogeneous-able working machines.
The current approach try to expose everything with core APIs
totally broken. If we go this way -- which I don't object at
all -- I don't plan to look at the issues reported, for my own
mental health.

>>    qemu-system-riscv64 -M virt ...
>>
>> at:
>> https://lore.kernel.org/qemu-devel/CAE2XoE_-ewv3iC_MZ2sM1eKG=CUKM7MZa-ppJV0Vk1rE1h+19w@mail.gmail.com/
>>
>>
>>> disambiguate when just "-machine virt" would be ambiguous; but if
>>> there's only one machine of that name then just "-machine foo" would
>>> work. That extends nicely to truly heterogeneous machine names:
>>> "-machine my-mixed-machine" wouldn't need the user to explicitly
>>> give it a -target option or otherwise say that it includes aarch64
>>
>>
>> Seems this direction is fine, May I post experiment patches with this direction?
>> The machine-filtering is still needed. and when the target is not specified by machine parameter. The default TargetInfo will be target
>> SYS_EMU_TARGET_NONE. And it means emulating heterogeneous machines.
> 
> I think we could also let the default (no target specified) work
> for non-heterogenous machines, as noted above.
> 
> -- PMM
>

On 8/28/2026 4:13 PM, Pierrick Bouvier wrote:
> On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
>> Now that we can link a single-binary with at least two targets (arm, aarch64),
>> we want to make sure that we expose the same set of machines (later devices and
>> cpus) than target binaries. For that, we implemented a static filtering based on
>> target interfaces that each machine will implement to declare which targets have
>> this machine.
>>
>> However, we discovered that this static filtering is not enough. Indeed, some
>> machines and devices do not depend only on target, and their presence can depend
>> on Kconfig or host/target combination. Thus, our static approach can't work, and
>> we need something more flexible.
>>
>> The goal of this series is to focus on the filtering mechanism, not on the
>> qemu-system binary itself, even though it's included here to give a full picture
>> of what we are building.
>>
>> v3
>> --
>>
>> Suggested by Richard, we simply use a callback added to TypeInfo.
>> Added full example with a single binary for arm+aarch64, and then
>> arm+aarch64+microblaze.
>> Also, added scripts/single-binary-compare-cmdline.sh, which compares list of
>> cpus, devices and machines between single-binary and original binaries.
>> This is what we can use in CI to ensure we correctly tagged all QOM types.
>>
> 
> After applying this series, and running
> scripts/single-binary-compare-cmdline.sh, you'll see than many devices
> are visible for microblaze, and should not.
> 

For reference, please find attached the list of devices that are not yet
filtered for qemu-system -target microblaze.

Regards,
Pierrickninja: Entering directory `build'
[1/113] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
------------------------------------------------------------------
------------------------------------------------------------------
------------------------------------------------------------------
diff --git a/dev/fd/63 b/dev/fd/62
--- a/dev/fd/63
+++ b/dev/fd/62
@@ -1,9 +1,40 @@
Controller/Bridge/Hub devices:
name "i82801b11-bridge", bus PCI
name "ioh3420", bus PCI, desc "Intel IOH device id 3420 PCIE Root Port"
name "pci-bridge", bus PCI, desc "Standard PCI Bridge"
name "pci-bridge-seat", bus PCI, desc "Standard PCI Bridge (multiseat)"
name "pcie-pci-bridge", bus PCI
name "pcie-root-port", bus PCI, desc "PCI Express Root Port"
name "pxb", bus PCI, desc "PCI Expander Bridge"
name "pxb-cxl", bus PCI, desc "CXL Host Bridge"
name "pxb-pcie", bus PCI, desc "PCI Express Expander Bridge"
name "usb-host", bus usb-bus
name "usb-hub", bus usb-bus
name "x3130-upstream", bus PCI, desc "TI X3130 Upstream Port of PCI Express Switch"
name "xio3130-downstream", bus PCI, desc "TI X3130 Downstream Port of PCI Express Switch"

USB devices:
name "ich9-usb-ehci1", bus PCI
name "ich9-usb-ehci2", bus PCI
name "ich9-usb-uhci1", bus PCI
name "ich9-usb-uhci2", bus PCI
name "ich9-usb-uhci3", bus PCI
name "ich9-usb-uhci4", bus PCI
name "ich9-usb-uhci5", bus PCI
name "ich9-usb-uhci6", bus PCI
name "nec-usb-xhci", bus PCI
name "pci-ohci", bus PCI, desc "Apple USB Controller"
name "piix3-usb-uhci", bus PCI
name "piix4-usb-uhci", bus PCI
name "qemu-xhci", bus PCI
name "usb-ehci", bus PCI

Storage devices:
name "160s33b", bus SSI, desc "Serial Flash"
name "25csm04", bus SSI, desc "Serial Flash"
name "320s33b", bus SSI, desc "Serial Flash"
name "640s33b", bus SSI, desc "Serial Flash"
name "am53c974", bus PCI, desc "AMD Am53c974 PCscsi-PCI SCSI adapter"
name "at25128a-nonjedec", bus SSI, desc "Serial Flash"
name "at25256a-nonjedec", bus SSI, desc "Serial Flash"
name "at25df041a", bus SSI, desc "Serial Flash"
@@ -16,6 +47,9 @@ name "at26df161a", bus SSI, desc "Serial Flash"
name "at26df321", bus SSI, desc "Serial Flash"
name "at26f004", bus SSI, desc "Serial Flash"
name "at45db081d", bus SSI, desc "Serial Flash"
name "cxl-type3", bus PCI, desc "CXL Memory Device (Type 3)"
name "dc390", bus PCI, desc "Tekram DC-390 SCSI adapter"
name "emmc", bus sd-bus, desc "eMMC"
name "en25f32", bus SSI, desc "Serial Flash"
name "en25p32", bus SSI, desc "Serial Flash"
name "en25p64", bus SSI, desc "Serial Flash"
@@ -23,6 +57,10 @@ name "en25q32b", bus SSI, desc "Serial Flash"
name "en25q64", bus SSI, desc "Serial Flash"
name "gd25q32", bus SSI, desc "Serial Flash"
name "gd25q64", bus SSI, desc "Serial Flash"
name "ich9-ahci", bus PCI, alias "ahci"
name "ide-cd", bus IDE, desc "virtual IDE CD-ROM"
name "ide-cf", bus IDE, desc "virtual CompactFlash card"
name "ide-hd", bus IDE, desc "virtual IDE disk"
name "is25lp016d", bus SSI, desc "Serial Flash"
name "is25lp032", bus SSI, desc "Serial Flash"
name "is25lp064", bus SSI, desc "Serial Flash"
@@ -34,6 +72,8 @@ name "is25wp032", bus SSI, desc "Serial Flash"
name "is25wp064", bus SSI, desc "Serial Flash"
name "is25wp128", bus SSI, desc "Serial Flash"
name "is25wp256", bus SSI, desc "Serial Flash"
name "lsi53c810", bus PCI
name "lsi53c895a", bus PCI, alias "lsi"
name "m25p05", bus SSI, desc "Serial Flash"
name "m25p10", bus SSI, desc "Serial Flash"
name "m25p128", bus SSI, desc "Serial Flash"
@@ -53,6 +93,9 @@ name "m25px64", bus SSI, desc "Serial Flash"
name "m45pe10", bus SSI, desc "Serial Flash"
name "m45pe16", bus SSI, desc "Serial Flash"
name "m45pe80", bus SSI, desc "Serial Flash"
name "megasas", bus PCI, desc "LSI MegaRAID SAS 1078"
name "megasas-gen2", bus PCI, desc "LSI MegaRAID SAS 2108"
name "mptsas1068", bus PCI, desc "LSI SAS 1068"
name "mt25ql01g", bus SSI, desc "Serial Flash"
name "mt25ql02g", bus SSI, desc "Serial Flash"
name "mt25ql512ab", bus SSI, desc "Serial Flash"
@@ -93,6 +136,11 @@ name "n25q512a", bus SSI, desc "Serial Flash"
name "n25q512a11", bus SSI, desc "Serial Flash"
name "n25q512a13", bus SSI, desc "Serial Flash"
name "n25q512ax3", bus SSI, desc "Serial Flash"
name "nvdimm", desc "DIMM memory module"
name "nvme", bus PCI, desc "Non-Volatile Memory Express"
name "nvme-ns", bus nvme-bus, desc "Virtual NVMe namespace"
name "nvme-subsys", desc "Virtual NVMe subsystem"
name "pvscsi", bus PCI
name "s25fl016k", bus SSI, desc "Serial Flash"
name "s25fl064k", bus SSI, desc "Serial Flash"
name "s25fl129p0", bus SSI, desc "Serial Flash"
@@ -112,6 +160,13 @@ name "s25sl12800", bus SSI, desc "Serial Flash"
name "s25sl12801", bus SSI, desc "Serial Flash"
name "s70fl01gs", bus SSI, desc "Serial Flash"
name "s70fs01gs", bus SSI, desc "Serial Flash"
name "scsi-block", bus SCSI, desc "SCSI block device passthrough"
name "scsi-cd", bus SCSI, desc "virtual SCSI CD-ROM"
name "scsi-generic", bus SCSI, desc "pass through generic scsi device (/dev/sg*)"
name "scsi-hd", bus SCSI, desc "virtual SCSI disk"
name "sd-card", bus sd-bus
name "sd-card-spi", bus sd-bus, desc "SD SPI"
name "sdhci-pci", bus PCI
name "sst25vf016b", bus SSI, desc "Serial Flash"
name "sst25vf032b", bus SSI, desc "Serial Flash"
name "sst25vf040b", bus SSI, desc "Serial Flash"
@@ -121,6 +176,37 @@ name "sst25wf020", bus SSI, desc "Serial Flash"
name "sst25wf040", bus SSI, desc "Serial Flash"
name "sst25wf080", bus SSI, desc "Serial Flash"
name "sst25wf512", bus SSI, desc "Serial Flash"
name "ufs", bus PCI, desc "Universal Flash Storage"
name "usb-bot", bus usb-bus
name "usb-mtp", bus usb-bus, desc "USB Media Transfer Protocol device"
name "usb-storage", bus usb-bus
name "usb-uas", bus usb-bus
name "vhost-scsi", bus virtio-bus
name "vhost-scsi-pci", bus PCI
name "vhost-scsi-pci-non-transitional", bus PCI
name "vhost-scsi-pci-transitional", bus PCI
name "vhost-user-blk", bus virtio-bus
name "vhost-user-blk-pci", bus PCI
name "vhost-user-blk-pci-non-transitional", bus PCI
name "vhost-user-blk-pci-transitional", bus PCI
name "vhost-user-fs-device", bus virtio-bus
name "vhost-user-fs-pci", bus PCI
name "vhost-user-scsi", bus virtio-bus
name "vhost-user-scsi-pci", bus PCI
name "vhost-user-scsi-pci-non-transitional", bus PCI
name "vhost-user-scsi-pci-transitional", bus PCI
name "virtio-9p-device", bus virtio-bus
name "virtio-9p-pci", bus PCI
name "virtio-9p-pci-non-transitional", bus PCI
name "virtio-9p-pci-transitional", bus PCI
name "virtio-blk-device", bus virtio-bus
name "virtio-blk-pci", bus PCI
name "virtio-blk-pci-non-transitional", bus PCI
name "virtio-blk-pci-transitional", bus PCI
name "virtio-scsi-device", bus virtio-bus
name "virtio-scsi-pci", bus PCI
name "virtio-scsi-pci-non-transitional", bus PCI
name "virtio-scsi-pci-transitional", bus PCI
name "w25q01jvq", bus SSI, desc "Serial Flash"
name "w25q02jvm", bus SSI, desc "Serial Flash"
name "w25q256", bus SSI, desc "Serial Flash"
@@ -138,8 +224,215 @@ name "w25x40", bus SSI, desc "Serial Flash"
name "w25x64", bus SSI, desc "Serial Flash"
name "w25x80", bus SSI, desc "Serial Flash"

Network devices:
name "e1000", bus PCI, alias "e1000-82540em", desc "Intel Gigabit Ethernet"
name "e1000-82544gc", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000-82545em", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000e", bus PCI, desc "Intel 82574L GbE Controller"
name "i82550", bus PCI, desc "Intel i82550 Ethernet"
name "i82551", bus PCI, desc "Intel i82551 Ethernet"
name "i82557a", bus PCI, desc "Intel i82557A Ethernet"
name "i82557b", bus PCI, desc "Intel i82557B Ethernet"
name "i82557c", bus PCI, desc "Intel i82557C Ethernet"
name "i82558a", bus PCI, desc "Intel i82558A Ethernet"
name "i82558b", bus PCI, desc "Intel i82558B Ethernet"
name "i82559a", bus PCI, desc "Intel i82559A Ethernet"
name "i82559b", bus PCI, desc "Intel i82559B Ethernet"
name "i82559c", bus PCI, desc "Intel i82559C Ethernet"
name "i82559er", bus PCI, desc "Intel i82559ER Ethernet"
name "i82562", bus PCI, desc "Intel i82562 Ethernet"
name "i82801", bus PCI, desc "Intel i82801 Ethernet"
name "igb", bus PCI, desc "Intel 82576 Gigabit Ethernet Controller"
name "ne2k_pci", bus PCI
name "pcnet", bus PCI
name "rocker", bus PCI, desc "Rocker Switch"
name "rtl8139", bus PCI
name "tulip", bus PCI
name "usb-net", bus usb-bus
name "virtio-net-device", bus virtio-bus
name "virtio-net-pci", bus PCI
name "virtio-net-pci-non-transitional", bus PCI
name "virtio-net-pci-transitional", bus PCI
name "vmxnet3", bus PCI, desc "VMWare Paravirtualized Ethernet v3"

Input devices:
name "ccid-card-emulated", bus ccid-bus, desc "emulated smartcard"
name "ccid-card-passthru", bus ccid-bus, desc "passthrough smartcard"
name "ipoctal232", bus IndustryPack, desc "GE IP-Octal 232 8-channel RS-232 IndustryPack"
name "pci-serial", bus PCI
name "pci-serial-2x", bus PCI
name "pci-serial-4x", bus PCI
name "tpci200", bus PCI, desc "TEWS TPCI200 IndustryPack carrier"
name "usb-braille", bus usb-bus
name "usb-ccid", bus usb-bus, desc "CCID Rev 1.1 smartcard reader"
name "usb-kbd", bus usb-bus
name "usb-mouse", bus usb-bus
name "usb-serial", bus usb-bus
name "usb-tablet", bus usb-bus
name "usb-wacom-tablet", bus usb-bus, desc "QEMU PenPartner Tablet"
name "vhost-user-gpio-device", bus virtio-bus
name "vhost-user-gpio-pci", bus PCI
name "vhost-user-i2c-device", bus virtio-bus
name "vhost-user-i2c-pci", bus PCI
name "vhost-user-input", bus virtio-bus
name "vhost-user-input-pci", bus PCI
name "vhost-user-rng", bus virtio-bus
name "vhost-user-rng-pci", bus PCI
name "vhost-user-scmi", bus virtio-bus
name "vhost-user-scmi-pci", bus PCI
name "vhost-user-spi-device", bus virtio-bus
name "vhost-user-spi-pci", bus PCI
name "vhost-user-test-device", bus virtio-bus
name "vhost-user-test-device-pci", bus PCI
name "virtconsole", bus virtio-serial-bus
name "virtio-input-host-device", bus virtio-bus
name "virtio-input-host-pci", bus PCI
name "virtio-keyboard-device", bus virtio-bus
name "virtio-keyboard-pci", bus PCI
name "virtio-mouse-device", bus virtio-bus
name "virtio-mouse-pci", bus PCI
name "virtio-multitouch-device", bus virtio-bus
name "virtio-multitouch-pci", bus PCI
name "virtio-serial-device", bus virtio-bus
name "virtio-serial-pci", bus PCI
name "virtio-serial-pci-non-transitional", bus PCI
name "virtio-serial-pci-transitional", bus PCI
name "virtio-tablet-device", bus virtio-bus
name "virtio-tablet-pci", bus PCI
name "virtserialport", bus virtio-serial-bus

Display devices:
name "ati-vga", bus PCI
name "bochs-display", bus PCI
name "cirrus-vga", bus PCI, desc "Cirrus CLGD 54xx VGA"
name "dm163", desc "DM163 8x3-channel constant current LED driver"
name "led", desc "LED"
name "ramfb", bus System, desc "ram framebuffer standalone device"
name "secondary-vga", bus PCI
name "ssd0323", bus SSI
name "VGA", bus PCI
name "vhost-user-gpu", bus virtio-bus
name "vhost-user-gpu-pci", bus PCI
name "virtio-gpu-device", bus virtio-bus
name "virtio-gpu-gl-device", bus virtio-bus
name "virtio-gpu-gl-pci", bus PCI
name "virtio-gpu-pci", bus PCI

Sound devices:
name "AC97", bus PCI, alias "ac97", desc "Intel 82801AA AC97 Audio"
name "ES1370", bus PCI, alias "es1370", desc "ENSONIQ AudioPCI ES1370"
name "hda-duplex", bus HDA, desc "HDA Audio Codec, duplex (line-out, line-in)"
name "hda-micro", bus HDA, desc "HDA Audio Codec, duplex (speaker, microphone)"
name "hda-output", bus HDA, desc "HDA Audio Codec, output-only (line-out)"
name "ich9-intel-hda", bus PCI, desc "Intel HD Audio Controller (ich9)"
name "intel-hda", bus PCI, desc "Intel HD Audio Controller (ich6)"
name "usb-audio", bus usb-bus
name "vhost-user-snd", bus virtio-bus
name "vhost-user-snd-pci", bus PCI
name "virtio-sound-device", bus virtio-bus
name "virtio-sound-pci", bus PCI, desc "Virtio Sound"

Misc devices:
name "acpi-erst", bus PCI, desc "ACPI Error Record Serialization Table (ERST) device"
name "adc128d818", bus i2c-bus
name "adm1266", bus i2c-bus, desc "Analog Devices ADM1266 Hot Swap controller"
name "adm1272", bus i2c-bus, desc "Analog Devices ADM1272 Hot Swap controller"
name "aspeed.i2c.slave", bus i2c-bus, desc "Aspeed I2C Bus Slave"
name "at24c-eeprom", bus i2c-bus
name "axp209_pmu", bus i2c-bus
name "axp221_pmu", bus i2c-bus
name "ctucan_pci", bus PCI, desc "CTU CAN PCI"
name "dps310", bus i2c-bus
name "ds1338", bus i2c-bus
name "edu", bus PCI
name "emc1413", bus i2c-bus
name "emc1414", bus i2c-bus
name "guest-loader", desc "Guest Loader"
name "i2c-ddc", bus i2c-bus
name "i2c-echo", bus i2c-bus
name "iommu-testdev", bus PCI, desc "A test device for IOMMU"
name "isl69259", bus i2c-bus, desc "Renesas ISL69259 Digital Multiphase Voltage Regulator"
name "isl69260", bus i2c-bus, desc "Renesas ISL69260 Digital Multiphase Voltage Regulator"
name "ivshmem-doorbell", bus PCI, desc "Inter-VM shared memory"
name "ivshmem-plain", bus PCI, desc "Inter-VM shared memory"
name "kvaser_pci", bus PCI, desc "Kvaser PCICANx"
name "loader", desc "Generic Loader"
name "lsm303dlhc_mag", bus i2c-bus
name "m41t80", bus i2c-bus
name "max31785", bus i2c-bus, desc "Maxim MAX31785 6-Channel Fan Controller"
name "max34451", bus i2c-bus, desc "Maxim MAX34451 16-Channel V/I monitor"
name "mioe3680_pci", bus PCI, desc "Mioe3680 PCICANx"
name "mock-i3c-target", bus i3c-bus
name "pca9535", bus i2c-bus
name "pca9536", bus i2c-bus
name "pca9546", bus i2c-bus, desc "Pca954x i2c-mux"
name "pca9548", bus i2c-bus, desc "Pca954x i2c-mux"
name "pca9552", bus i2c-bus
name "pca9554", bus i2c-bus
name "pca9555", bus i2c-bus
name "pci-testdev", bus PCI, desc "PCI Test Device"
name "pcm3680_pci", bus PCI, desc "Pcm3680i PCICANx"
name "pvpanic-pci", bus PCI
name "raa228000", bus i2c-bus, desc "Renesas 228000 Digital Multiphase Voltage Regulator"
name "raa229004", bus i2c-bus, desc "Renesas 229004 Digital Multiphase Voltage Regulator"
name "rs5c372", bus i2c-bus
name "sii9022", bus i2c-bus
name "ssd0303", bus i2c-bus
name "tmp105", bus i2c-bus
name "tmp421", bus i2c-bus
name "tmp422", bus i2c-bus
name "tmp423", bus i2c-bus
name "tpm-tis-device", bus System
name "tpm-tis-i2c", bus i2c-bus
name "u2f-passthru", bus usb-bus, desc "QEMU U2F passthrough key"
name "uefi-vars-sysbus", bus System
name "uefi-vars-x64", bus System
name "usb-redir", bus usb-bus
name "vfio-pci", bus PCI, desc "VFIO-based PCI device assignment"
name "vfio-pci-nohotplug", bus PCI, desc "VFIO-based PCI device assignment"
name "vfio-user-pci", bus PCI, desc "VFIO over socket PCI device assignment"
name "vhost-user-rtc", bus virtio-bus
name "vhost-user-rtc-pci", bus PCI
name "vhost-user-vsock-device", bus virtio-bus
name "vhost-user-vsock-pci", bus PCI
name "vhost-user-vsock-pci-non-transitional", bus PCI
name "vhost-vdpa-device", bus virtio-bus, desc "VDPA-based generic device assignment"
name "vhost-vdpa-device-pci", bus PCI
name "vhost-vdpa-device-pci-non-transitional", bus PCI
name "vhost-vdpa-device-pci-transitional", bus PCI
name "vhost-vsock-device", bus virtio-bus
name "vhost-vsock-pci", bus PCI
name "vhost-vsock-pci-non-transitional", bus PCI
name "virtio-balloon-device", bus virtio-bus
name "virtio-balloon-pci", bus PCI
name "virtio-balloon-pci-non-transitional", bus PCI
name "virtio-balloon-pci-transitional", bus PCI
name "virtio-crypto-device", bus virtio-bus
name "virtio-crypto-pci", bus PCI
name "virtio-iommu-device", bus virtio-bus
name "virtio-iommu-pci", bus PCI
name "virtio-mem", bus virtio-bus
name "virtio-mem-pci", bus PCI
name "virtio-rng-device", bus virtio-bus
name "virtio-rng-pci", bus PCI
name "virtio-rng-pci-non-transitional", bus PCI
name "virtio-rng-pci-transitional", bus PCI
name "virtio-rtc-device", bus virtio-bus
name "virtio-rtc-pci", bus PCI
name "vmcoreinfo"
name "wm8750", bus i2c-bus

Watchdog devices:
name "i6300esb", bus PCI, desc "Intel 6300ESB"
name "sbsa-gwdt", bus System, desc "SBSA-compliant generic watchdog device"

Uncategorized devices:
name "arm-smmuv3", bus System
name "aspeed-otp"
name "cfam", bus fsi.bus, desc "FSI Slave"
name "cxl-switch-mailbox-cci", bus PCI, desc "CXL Switch Mailbox CCI"
name "fsi.master", bus opb, desc "FSI Master"
name "fsi.scratchpad", bus fsi.lbus
name "fsi.slave", bus fsi.bus, desc "FSI Slave"
name "pc-dimm", desc "DIMM memory module"
name "ufs-lu", bus ufs-bus, desc "Virtual UFS logical unit"