On 5/5/2026 3:48 PM, Pierrick Bouvier wrote: > We are getting close to be able to link several targets in a single QEMU > system > binary, and the last obstacle on the road is to embed several TargetInfo in > the > same binary. The end result of this series is to have a single definition for > target_info symbol. > > This series adds TargetInfo types in QOM, and retrieve them dynamically(). At > the moment, we don't deal yet with multiple TargetInfo selection, but install > all that is needed to be able to do it easily. > > Because TargetInfo data is set through class_init, it creates an issue at > startup, where we may try to instantiate additional (unrelated) types just to > retrieve the list of "target-info-X" types. Those other types class_init may > be > using target information, to add target specific properties for instance. > This issue has been fixed by adding a new object_class_get_list_by_name_prefix > that does not force instantiation of all QOM types, but only those matching a > specific pattern. This way, we first initialize and retrieve target-info types > before others. > > An alternative would be to leave all this out of QOM, and use startup > initializer to add them in a single list. However, because all the > single-binary > work has been using QOM where possible, it would be really sad to not use it > for > this final step. Comments are welcome! > > Finally, sticking to our promise not create a special "single-binary > configuration", the goal is to use the *exact* same codepath for normal > binaries > also. It means that even for existing system binaries, the goal will be to use > QOM to retrieve current target, even if there is only one. > > v4 > -- > > - Revert to v2 MODULE_INIT_TARGET_INFO as Daniel didn't comment on issues > about > about MODULE_INIT_QOM_EARLY. > > v3 > -- > > - fix rebase mistake for one header guard > - remove MODULE_INIT_TARGET_INFO and introduce MODULE_INIT_QOM_EARLY, as > requested by Daniel > > v2 > -- > > - fix header guards > - introduce new module init step (MODULE_INIT_TARGET_INFO) > - as a consequence of item above, we need to register TYPE_OBJECT before > startup > - fix xtensa core type registration using type_init instead of static ctor > > Pierrick Bouvier (6): > target/xtensa/core: register types using type_init > qom/object: register OBJECT and INTERFACE QOM types before main > target-info: extract target_info() definition in target-info-init.h > target-info: introduce TargetInfo in QOM > target-info-qom: detect target from QOM > target-info: replace target_info() in system-mode > > configs/targets/aarch64-softmmu.c | 6 +-- > configs/targets/arm-softmmu.c | 6 +-- > include/qemu/module.h | 1 + > include/qemu/target-info-init.h | 73 +++++++++++++++++++++++++++++++ > include/qemu/target-info-qom.h | 30 +++++++++++++ > qom/object.c | 4 +- > system/vl.c | 4 ++ > target-info-qom.c | 35 +++++++++++++++ > target-info-stub.c | 6 +-- > target/xtensa/overlay_tool.h | 5 ++- > 10 files changed, 153 insertions(+), 17 deletions(-) > create mode 100644 include/qemu/target-info-init.h > create mode 100644 include/qemu/target-info-qom.h >
sent v5: https://lore.kernel.org/qemu-devel/[email protected]/T/# Regards, Pierrick
