On Thu, Oct 15, 2026 at 1:35 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 10/14/2026 2:31 AM, Yonggang Luo wrote:
> > MachineClass::targets declares each machine's supported targets as a
> > uint64_t QEMU_ARCH_* mask.
> >
> > In the combined executable, a machine can be selected from
> > <target>-<machine-name> when <machine-name> is ambitious.
> > Otherwise we can use <machine-name> to directly select a target.
> >
> > Renaming SysEmuTarget to EmuTarget prepares the enum for both system and
> > user-mode targets before introducing more usage of it.
> > Rationale:
> > https://lore.kernel.org/qemu-devel/d6217459-1e55-4da0-a49f-bde8215d8c0e@oss.qualcomm.com/
> >
> > The "virt" machines need distinct QOM names to coexist in a combined binary
> > or test. Their existing CLI names and aliases are preserved.
> >
> > Other indirect call of target_info() in class_init/type_init is removed by
> > serveral commits, this is a prepare for select <target> by -machine $type.
> > As target_info() will be NULL till the target is selected under machine_select.
> >
> > The commits through "hw: add MachineClass::targets with a usage and test"
> > add a minimal demo/test for introduce MachineClass::targets
> >
> > The next group, through
> > "meson: build combined qemu-system for multi-target configurations",
> > enabled the test guard to prevent introduce future calling
> > target_info() in type_init or class_init
> >
> > These two boundaries provide possible merge points.
> >
> > "targets" be exported along with MachineInfo in commit
> > "qmp: Expose supported targets in query-machines", so that the qmp know
> > how to set proper $<target>-<machine-name>.
> >
> > The rest commits is the introduce of support of <target> select from
> > `-machine $type`.
> >
> > Yonggang Luo (34):
> > qemu/base-arch-defs: extract QEMU_ARCH_BIT for QEMU_ARCH_* enums
> > qemu: Use SYS_EMU_TARGET__MAX to define QEMU_ARCH_ALL
> > qemu: increase width of QEMU_ARCH_* masks enums to be 64 bits
> > qapi: rename SysEmuTarget to EmuTarget
> > qapi: add missing Linux user-mode targets to EmuTarget
> > meson: define TARGET_ARCH_VARIANT to target_name only
> > target-info: prepare the QOM target list before
> > module_call_init(MODULE_INIT_QOM)
> > hw: add MachineClass::targets with a usage and test
> > accel: register CPU parent for each target
> > meson: collect Rust crates for combined system target
> > module: Add module_allow_all_arch for allow all modules be loaded
> > target/arm: defer max-v8 initializer selection until CPU creation
> > hw/microblaze: defer PetaLogix endianness default until init
> > hw/pci: Avoid guard loadparm with target_s390x() for s390x in
> > class_init
> > hw/scsi: Avoid guard loadparm with target_s390x() for s390x in
> > class_init
> > hw/virtio/virtio-mem: Avoid call to target_info() in class_init
> > target-info: add a combined-binary query stub
> > machine: allow -M name to differ from QOM type
> > hw/riscv/virt: use unique QOM name
> > hw/arm/virt: use unique QOM name
> > hw/or1k/virt: use unique QOM name
> > hw/hexagon/virt: use unique QOM name
> > hw/loongarch/virt: use unique QOM name
> > hw/m68k/virt: use unique QOM name
> > hw/xtensa/virt: use unique QOM name
> > qapi: return MachineInfo typename from query-machines
> > machine: match the versioned virt example to arm virt
> > hw: Add MachineClass.targets for all "virt" machines for all possible
> > targets
> > system/arch_init: update qemu_arch_available to handle non-target
> > select condition
> > meson: build combined qemu-system for multi-target configurations
> > qmp: Expose supported targets in query-machines
> > system/vl: select target from machine name in combined binaries
> > system/vl: handle cpu/device help properly for multi-target qemu
> > qdev: Handle device alias ambiguous under multi-target qemu
> >
> > MAINTAINERS | 2 +
> > accel/accel-common.c | 6 +-
> > accel/accel-internal.h | 1 +
> > accel/accel-system.c | 24 +++
> > accel/accel-user.c | 7 +
> > backends/igvm.c | 4 +-
> > hw/alpha/dp264.c | 2 +
> > hw/arm/virt.c | 56 +++----
> > hw/core/machine-qmp-cmds.c | 19 ++-
> > hw/core/machine.c | 9 ++
> > hw/hexagon/virt.c | 25 +++-
> > hw/loongarch/virt.c | 47 +++---
> > hw/m68k/virt.c | 39 +++--
> > hw/microblaze/petalogix_s3adsp1800_mmu.c | 11 +-
> > hw/misc/vmlaunchupdate.c | 6 +-
> > hw/or1k/virt.c | 22 +--
> > hw/pci/pci.c | 18 ++-
> > hw/riscv/virt.c | 28 ++--
> > hw/scsi/scsi-disk.c | 18 ++-
> > hw/uefi/ovmf-log.c | 4 +-
> > hw/virtio/virtio-mem.c | 26 ++--
> > hw/xtensa/virt.c | 24 ++-
> > include/hw/arm/virt.h | 5 +-
> > include/hw/core/boards.h | 45 ++++--
> > include/hw/hexagon/virt.h | 5 +-
> > include/hw/loongarch/virt.h | 5 +-
> > include/hw/riscv/virt.h | 5 +-
> > include/monitor/qdev.h | 7 +
> > include/qemu/base-arch-defs.h | 80 ++++++----
> > include/qemu/module.h | 2 +
> > include/qemu/target-info-def.h | 2 +-
> > include/qemu/target-info-qapi.h | 4 +-
> > include/qemu/target-info-qom.h | 4 +
> > include/qemu/target-info.h | 7 +
> > meson.build | 82 +++++++++-
> > monitor/monitor-hmp-internal.h | 2 +-
> > qapi/machine.json | 44 +++---
> > qapi/pragma.json | 4 +-
> > qom/object.c | 4 +-
> > stubs/meson.build | 1 +
> > stubs/target-info.c | 10 ++
> > system/arch_init.c | 12 +-
> > system/qdev-monitor.c | 54 ++++++-
> > system/target-info.c | 10 ++
> > system/vl.c | 181 ++++++++++++++++++++---
> > target-info-def.c | 2 +-
> > target-info-qom.c | 26 +++-
> > target-info.c | 38 ++---
> > target/arm/tcg/cpu-max-v8.c | 17 ++-
> > tests/qtest/fuzz/fuzz.c | 2 +-
> > tests/qtest/qom-test.c | 65 +++++++-
> > tests/unit/meson.build | 4 +-
> > tests/unit/test-multi-target.c | 67 ++++++++-
> > util/module.c | 10 +-
> > 54 files changed, 915 insertions(+), 289 deletions(-)
> > create mode 100644 stubs/target-info.c
> > create mode 100644 system/target-info.c
> >
>
> Hi Yonggang,
>
> in a previous thread, we had a long discussion about which direction we
> want to go, and what needs to be implemented. I politely suggested to
> focus first on simply removing dependency in class_init to target_info,
The removing dependency in class_init to target_info is at:
https://lore.kernel.org/qemu-devel/20261013200525.1340-1-luoyonggang@gmail.com/
I think it's easy to avoid target_info in class_init , there is no need to rely
on is_available for this.
> and rely on is_available only. The idea was to convince you that small
> iteration steps are better than throw-all-in series. I thought we were
> on the same page.
Sorry, I should add the DRAFT in the title, it is just a post for
experiment(means
testing locally) and tells us our direction is correct.
And also I can use it locally. Sorry for the burden.
>
> Now, yet another mega series mixing cleanup, code and even going as far
> as introducing the qemu-system binary.
>
> I feel like spending time to give advice didn't lead to a concrete
Your advice I am hearing and done at
https://lore.kernel.org/qemu-devel/20261013200525.1340-1-luoyonggang@gmail.com/
And I explained no need to introduce is_available to avoid
target_info() in class_init.
Because I can not get a usable qemu-system that includes all QOM names.
> change in behavior. As a result, I'm stopping to review all those
> series, and will let others drive this.
I am fine with that, thanks. Others drive(coding) will give more
agreement. Things/Design
sometimes needed in conjunction with code.
>
> Regards,
> Pierrick
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo