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

-- 
2.43.0

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/20260509005453.3984184-1-pierrick.bouvier@oss.qualcomm.com/T/#

Regards,
Pierrick

On Tue, May 05, 2026 at 03:48:20PM -0700, 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.

Sorry for  not responding to that, other things got in the way
this week.

For clarity, I withdraw my objections from v2. Having seen how
my suggested approadch in v3 looked, I think you were correct
all along.

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 5/8/2026 9:10 AM, Daniel P. Berrangé wrote:
> On Tue, May 05, 2026 at 03:48:20PM -0700, 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.
> 
> Sorry for  not responding to that, other things got in the way
> this week.
>

No worries, that's a good lesson for me about not interpreting not
having answer as a lack of interest when someone is active on other threads.

> For clarity, I withdraw my objections from v2. Having seen how
> my suggested approadch in v3 looked, I think you were correct
> all along.
>

The important is that we explored this path and its limitations.

> With regards,
> Daniel

Thanks Daniel,
Pierrick

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
> 

Patches 2 and 4 still need review.

Regards,
Pierrick