On Thu, Oct 15, 2026 at 1:35 AM Pierrick Bouvier <[email protected]> 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/[email protected]/ > > > > 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/[email protected]/ 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/[email protected]/ 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
