[PATCH v4 0/6] single-binary: deduplicate target_info()

[PATCH v4 0/6] single-binary: deduplicate target_info()

[Pierrick Bouvier]

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

[PATCH v4 1/6] target/xtensa/core: register types using type_init

[Pierrick Bouvier]

Instead of using a static constructor, delay registering those types
until we call module_init(MODULE_INIT_QOM).

This is not yet a problem, but since we will start initializing
target-info types before any other, without this patch
qemu-system-xtensa* fails with:
Type 'dsp3400-xtensa-cpu' is missing its parent 'xtensa-cpu'

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 target/xtensa/overlay_tool.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/xtensa/overlay_tool.h b/target/xtensa/overlay_tool.h
index 701c00eed20..b9eaffa4871 100644
--- a/target/xtensa/overlay_tool.h
+++ b/target/xtensa/overlay_tool.h
@@ -451,13 +451,14 @@
 
 #if TARGET_BIG_ENDIAN == (XCHAL_HAVE_BE != 0)
 #define REGISTER_CORE(core) \
-    static void __attribute__((constructor)) register_core(void) \
+    static void register_core(void) \
     { \
         static XtensaConfigList node = { \
             .config = &core, \
         }; \
         xtensa_register_core(&node); \
-    }
+    } \
+    type_init(register_core)
 #else
 #define REGISTER_CORE(core)
 #endif
-- 
2.43.0

Re: [PATCH v4 1/6] target/xtensa/core: register types using type_init

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> Instead of using a static constructor, delay registering those types
> until we call module_init(MODULE_INIT_QOM).
> 
> This is not yet a problem, but since we will start initializing
> target-info types before any other, without this patch
> qemu-system-xtensa* fails with:
> Type 'dsp3400-xtensa-cpu' is missing its parent 'xtensa-cpu'
> 
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>   target/xtensa/overlay_tool.h | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/xtensa/overlay_tool.h b/target/xtensa/overlay_tool.h
> index 701c00eed20..b9eaffa4871 100644
> --- a/target/xtensa/overlay_tool.h
> +++ b/target/xtensa/overlay_tool.h
> @@ -451,13 +451,14 @@
>   
>   #if TARGET_BIG_ENDIAN == (XCHAL_HAVE_BE != 0)
>   #define REGISTER_CORE(core) \
> -    static void __attribute__((constructor)) register_core(void) \
> +    static void register_core(void) \
>       { \
>           static XtensaConfigList node = { \
>               .config = &core, \
>           }; \
>           xtensa_register_core(&node); \
> -    }
> +    } \
> +    type_init(register_core)
>   #else
>   #define REGISTER_CORE(core)
>   #endif

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH v4 2/6] qom/object: register OBJECT and INTERFACE QOM types before main

[Pierrick Bouvier]

Those types are special, as they are the base of all other QOM types. In
next commit, we'll introduce an extra step in module initialization for
target-info-* types.

However, those types depend on TYPE_OBJECT, which is only registered
at MODULE_INIT_QOM step.

To avoid having to introduce another step, and modify all code calling
module_call_init(MODULE_INIT_QOM), we simply register those base types
directly in the static constructor, before anything else.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 qom/object.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index f981e270440..a5d268d0722 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -2839,7 +2839,7 @@ static void object_class_init(ObjectClass *klass, const void *data)
                                   NULL);
 }
 
-static void register_types(void)
+static void __attribute__((constructor)) register_types(void)
 {
     static const TypeInfo interface_info = {
         .name = TYPE_INTERFACE,
@@ -2857,5 +2857,3 @@ static void register_types(void)
     type_interface = type_register_internal(&interface_info);
     type_register_internal(&object_info);
 }
-
-type_init(register_types)
-- 
2.43.0

Re: [PATCH v4 2/6] qom/object: register OBJECT and INTERFACE QOM types before main

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> Those types are special, as they are the base of all other QOM types. In
> next commit, we'll introduce an extra step in module initialization for
> target-info-* types.
> 
> However, those types depend on TYPE_OBJECT, which is only registered
> at MODULE_INIT_QOM step.
> 
> To avoid having to introduce another step, and modify all code calling
> module_call_init(MODULE_INIT_QOM), we simply register those base types
> directly in the static constructor, before anything else.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>   qom/object.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/qom/object.c b/qom/object.c
> index f981e270440..a5d268d0722 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -2839,7 +2839,7 @@ static void object_class_init(ObjectClass *klass, const void *data)
>                                     NULL);
>   }
>   
> -static void register_types(void)
> +static void __attribute__((constructor)) register_types(void)
>   {
>       static const TypeInfo interface_info = {
>           .name = TYPE_INTERFACE,
> @@ -2857,5 +2857,3 @@ static void register_types(void)
>       type_interface = type_register_internal(&interface_info);
>       type_register_internal(&object_info);
>   }
> -
> -type_init(register_types)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

As a followup QOM improvement, we could use this constructor to explicitly initialize 
type_table, and drop type_table_get() and its continual checking for NULL.


r~

Re: [PATCH v4 2/6] qom/object: register OBJECT and INTERFACE QOM types before main

[Pierrick Bouvier]

On 5/8/2026 11:55 AM, Richard Henderson wrote:
> On 5/5/26 17:48, Pierrick Bouvier wrote:
>> Those types are special, as they are the base of all other QOM types. In
>> next commit, we'll introduce an extra step in module initialization for
>> target-info-* types.
>>
>> However, those types depend on TYPE_OBJECT, which is only registered
>> at MODULE_INIT_QOM step.
>>
>> To avoid having to introduce another step, and modify all code calling
>> module_call_init(MODULE_INIT_QOM), we simply register those base types
>> directly in the static constructor, before anything else.
>>
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>> ---
>>   qom/object.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/qom/object.c b/qom/object.c
>> index f981e270440..a5d268d0722 100644
>> --- a/qom/object.c
>> +++ b/qom/object.c
>> @@ -2839,7 +2839,7 @@ static void object_class_init(ObjectClass
>> *klass, const void *data)
>>                                     NULL);
>>   }
>>   -static void register_types(void)
>> +static void __attribute__((constructor)) register_types(void)
>>   {
>>       static const TypeInfo interface_info = {
>>           .name = TYPE_INTERFACE,
>> @@ -2857,5 +2857,3 @@ static void register_types(void)
>>       type_interface = type_register_internal(&interface_info);
>>       type_register_internal(&object_info);
>>   }
>> -
>> -type_init(register_types)
> 
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> 
> As a followup QOM improvement, we could use this constructor to
> explicitly initialize type_table, and drop type_table_get() and its
> continual checking for NULL.
>

This sounds like a reasonable idea. There should not be any other QOM
type registered with a static constructor (previous patch is the only
occurrence I found after review), so we should be safe regarding non
deterministic call sequence for static ctor.

I'll add this in v5.

> 
> r~

Regards,
Pierrick

[PATCH v4 3/6] target-info: extract target_info() definition in target-info-init.h

[Pierrick Bouvier]

This allows us to prepare next commits, which will introduce qom
registration for system mode.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 configs/targets/aarch64-softmmu.c |  6 ++----
 configs/targets/arm-softmmu.c     |  6 ++----
 include/qemu/target-info-init.h   | 21 +++++++++++++++++++++
 target-info-stub.c                |  6 ++----
 4 files changed, 27 insertions(+), 12 deletions(-)
 create mode 100644 include/qemu/target-info-init.h

diff --git a/configs/targets/aarch64-softmmu.c b/configs/targets/aarch64-softmmu.c
index 82ccb575759..75d95b0e743 100644
--- a/configs/targets/aarch64-softmmu.c
+++ b/configs/targets/aarch64-softmmu.c
@@ -8,6 +8,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/target-info-impl.h"
+#include "qemu/target-info-init.h"
 #include "hw/arm/machines-qom.h"
 #include "target/arm/cpu-qom.h"
 #include "target/arm/cpu-param.h"
@@ -23,7 +24,4 @@ static const TargetInfo target_info_aarch64_system = {
     .page_bits_init = TARGET_PAGE_BITS_LEGACY,
 };
 
-const TargetInfo *target_info(void)
-{
-    return &target_info_aarch64_system;
-}
+target_info_init(target_info_aarch64_system)
diff --git a/configs/targets/arm-softmmu.c b/configs/targets/arm-softmmu.c
index 18940e51e55..73546fa5737 100644
--- a/configs/targets/arm-softmmu.c
+++ b/configs/targets/arm-softmmu.c
@@ -8,6 +8,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/target-info-impl.h"
+#include "qemu/target-info-init.h"
 #include "hw/arm/machines-qom.h"
 #include "target/arm/cpu-qom.h"
 #include "target/arm/cpu-param.h"
@@ -23,7 +24,4 @@ static const TargetInfo target_info_arm_system = {
     .page_bits_init = TARGET_PAGE_BITS_LEGACY,
 };
 
-const TargetInfo *target_info(void)
-{
-    return &target_info_arm_system;
-}
+target_info_init(target_info_arm_system)
diff --git a/include/qemu/target-info-init.h b/include/qemu/target-info-init.h
new file mode 100644
index 00000000000..c781cfc0590
--- /dev/null
+++ b/include/qemu/target-info-init.h
@@ -0,0 +1,21 @@
+/*
+ * QEMU target info initialization
+ *
+ * Copyright (c) Qualcomm
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This file is included by each file defining a TargetInfo structure and is
+ * responsible for registering it.
+ */
+
+#ifndef TARGET_INFO_DEF_H
+#define TARGET_INFO_DEF_H
+
+#define target_info_init(ti_var)        \
+const TargetInfo *target_info(void)     \
+{                                       \
+    return &ti_var;                     \
+}
+
+#endif /* TARGET_INFO_DEF_H */
diff --git a/target-info-stub.c b/target-info-stub.c
index f5896a72621..af7cdc5e67a 100644
--- a/target-info-stub.c
+++ b/target-info-stub.c
@@ -9,6 +9,7 @@
 #include "qemu/osdep.h"
 #include "qemu/target-info.h"
 #include "qemu/target-info-impl.h"
+#include "qemu/target-info-init.h"
 #include "hw/core/boards.h"
 #include "cpu.h"
 #include "exec/page-vary.h"
@@ -40,7 +41,4 @@ static const TargetInfo target_info_stub = {
 #endif
 };
 
-const TargetInfo *target_info(void)
-{
-    return &target_info_stub;
-}
+target_info_init(target_info_stub)
-- 
2.43.0

Re: [PATCH v4 3/6] target-info: extract target_info() definition in target-info-init.h

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> This allows us to prepare next commits, which will introduce qom
> registration for system mode.
> 
> Reviewed-by: Marc-André Lureau<marcandre.lureau@redhat.com>
> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
> ---
>   configs/targets/aarch64-softmmu.c |  6 ++----
>   configs/targets/arm-softmmu.c     |  6 ++----
>   include/qemu/target-info-init.h   | 21 +++++++++++++++++++++
>   target-info-stub.c                |  6 ++----
>   4 files changed, 27 insertions(+), 12 deletions(-)
>   create mode 100644 include/qemu/target-info-init.h

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH v4 4/6] target-info: introduce TargetInfo in QOM

[Pierrick Bouvier]

For the single-binary, we want to be able to retrieve at runtime the
current target among the different ones available.
A consequence is that we can't rely on existing target_info() definition
since it will create a conflict once more than one target is available.

To solve this, we add TargetInfo in QOM, with this hierarchy.
We define one class "target-info-X" per target, that inherits from
abstract class "target-info". Using concrete vs abstract class ensure we
can easily filter "target-info-X" from all QOM types.
Associated TargetInfo is directly set through class initialization,
without relying on any instance.

For user mode, we simply define target_info() like it was done
previously. In this patch, we keep the same definition for system-mode
also, and it will be replaced in next commits.

We will introduce detection of target from QOM, so we need to make sure
those types are registered early.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 include/qemu/module.h           |  1 +
 include/qemu/target-info-init.h | 57 +++++++++++++++++++++++++++++++++
 include/qemu/target-info-qom.h  | 28 ++++++++++++++++
 system/vl.c                     |  2 ++
 target-info-qom.c               | 14 ++++++++
 5 files changed, 102 insertions(+)
 create mode 100644 include/qemu/target-info-qom.h

diff --git a/include/qemu/module.h b/include/qemu/module.h
index 9885ac9afb3..fccf017bf9e 100644
--- a/include/qemu/module.h
+++ b/include/qemu/module.h
@@ -43,6 +43,7 @@ typedef enum {
     MODULE_INIT_MIGRATION,
     MODULE_INIT_BLOCK,
     MODULE_INIT_OPTS,
+    MODULE_INIT_TARGET_INFO,
     MODULE_INIT_QOM,
     MODULE_INIT_TRACE,
     MODULE_INIT_XEN_BACKEND,
diff --git a/include/qemu/target-info-init.h b/include/qemu/target-info-init.h
index c781cfc0590..859451c672e 100644
--- a/include/qemu/target-info-init.h
+++ b/include/qemu/target-info-init.h
@@ -12,10 +12,67 @@
 #ifndef TARGET_INFO_DEF_H
 #define TARGET_INFO_DEF_H
 
+#define DEFINE_TARGET_INFO_TYPE(info)                                       \
+static void do_qemu_init_target_info(void)                                  \
+{                                                                           \
+    type_register_static(&info);                                            \
+}                                                                           \
+module_init(do_qemu_init_target_info, MODULE_INIT_TARGET_INFO)
+
+#ifdef COMPILING_PER_TARGET
+#ifdef CONFIG_USER_ONLY
+
+/*
+ * User mode does not support multiple targets in the same binary, so just
+ * define target_info().
+ */
 #define target_info_init(ti_var)        \
 const TargetInfo *target_info(void)     \
 {                                       \
     return &ti_var;                     \
 }
 
+#else /* CONFIG_USER_ONLY */
+
+#include "qemu/target-info-qom.h"
+#include "qom/object.h"
+
+#define TYPE_TARGET_INFO_TARGET TYPE_TARGET_INFO"-"TARGET_NAME
+
+typedef struct TargetInfoQomTarget {
+    TargetInfoQom parent;
+} TargetInfoQomTarget;
+
+typedef struct TargetInfoQomTargetClass {
+    TargetInfoQomClass parent_class;
+} TargetInfoQomTargetClass;
+
+OBJECT_DECLARE_TYPE(TargetInfoQomTarget, TargetInfoQomTargetClass, TARGET_INFO_TARGET)
+
+#define target_info_init(ti_var)                                            \
+const TargetInfo *target_info(void)                                         \
+{                                                                           \
+    return &ti_var;                                                         \
+}                                                                           \
+                                                                            \
+static void target_info_qom_class_init(ObjectClass *oc, const void * data)  \
+{                                                                           \
+    TargetInfoQomTargetClass *klass = TARGET_INFO_TARGET_CLASS(oc);         \
+    klass->parent_class.target_info = &ti_var;                              \
+}                                                                           \
+                                                                            \
+static const TypeInfo target_info_qom_target_type_info = {                  \
+    .name = TYPE_TARGET_INFO_TARGET,                                        \
+    .parent = TYPE_TARGET_INFO,                                             \
+    .instance_size = sizeof(TargetInfoQomTarget),                           \
+    .class_size = sizeof(TargetInfoQomTargetClass),                         \
+    .class_init = target_info_qom_class_init,                               \
+    .abstract = false,                                                      \
+};                                                                          \
+                                                                            \
+DEFINE_TARGET_INFO_TYPE(target_info_qom_target_type_info)
+
+#endif /* CONFIG_USER_ONLY */
+#endif /* COMPILING_PER_TARGET */
+
 #endif /* TARGET_INFO_DEF_H */
diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h
new file mode 100644
index 00000000000..585995c7ad0
--- /dev/null
+++ b/include/qemu/target-info-qom.h
@@ -0,0 +1,28 @@
+/*
+ * QEMU target info QOM types
+ *
+ * Copyright (c) Qualcomm
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef QEMU_TARGET_INFO_QOM_H
+#define QEMU_TARGET_INFO_QOM_H
+
+#include "qemu/target-info-impl.h"
+#include "qom/object.h"
+
+#define TYPE_TARGET_INFO "target-info"
+
+typedef struct TargetInfoQom {
+    Object parent_obj;
+} TargetInfoQom;
+
+typedef struct TargetInfoQomClass {
+    ObjectClass parent_class;
+    const TargetInfo *target_info;
+} TargetInfoQomClass;
+
+OBJECT_DECLARE_TYPE(TargetInfoQom, TargetInfoQomClass, TARGET_INFO)
+
+#endif /* QEMU_TARGET_INFO_QOM_H */
diff --git a/system/vl.c b/system/vl.c
index 516ed7890b4..2b6739271ba 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -2890,6 +2890,8 @@ void qemu_init(int argc, char **argv)
 
     os_setup_limits();
 
+    module_call_init(MODULE_INIT_TARGET_INFO);
+
     module_init_info(qemu_modinfo);
     module_allow_arch(target_name());
 
diff --git a/target-info-qom.c b/target-info-qom.c
index 7fd58d24818..ba2c7923760 100644
--- a/target-info-qom.c
+++ b/target-info-qom.c
@@ -7,7 +7,11 @@
  */
 
 #include "qemu/osdep.h"
+#include "qapi/error.h"
 #include "qom/object.h"
+#include "qemu/target-info-impl.h"
+#include "qemu/target-info-init.h"
+#include "qemu/target-info-qom.h"
 #include "hw/arm/machines-qom.h"
 
 static const TypeInfo target_info_types[] = {
@@ -22,3 +26,13 @@ static const TypeInfo target_info_types[] = {
 };
 
 DEFINE_TYPES(target_info_types)
+
+static const TypeInfo target_info_parent_type = {
+    .name = TYPE_TARGET_INFO,
+    .parent = TYPE_OBJECT,
+    .instance_size = sizeof(TargetInfoQom),
+    .class_size = sizeof(TargetInfoQomClass),
+    .abstract = true,
+};
+
+DEFINE_TARGET_INFO_TYPE(target_info_parent_type)
-- 
2.43.0

Re: [PATCH v4 4/6] target-info: introduce TargetInfo in QOM

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> diff --git a/include/qemu/target-info-init.h b/include/qemu/target-info-init.h
> index c781cfc0590..859451c672e 100644
> --- a/include/qemu/target-info-init.h
> +++ b/include/qemu/target-info-init.h
> @@ -12,10 +12,67 @@
>   #ifndef TARGET_INFO_DEF_H
>   #define TARGET_INFO_DEF_H
>   
> +#define DEFINE_TARGET_INFO_TYPE(info)                                       \
> +static void do_qemu_init_target_info(void)                                  \
> +{                                                                           \
> +    type_register_static(&info);                                            \
> +}                                                                           \
> +module_init(do_qemu_init_target_info, MODULE_INIT_TARGET_INFO)
> +
> +#ifdef COMPILING_PER_TARGET
> +#ifdef CONFIG_USER_ONLY
> +
> +/*
> + * User mode does not support multiple targets in the same binary, so just
> + * define target_info().
> + */
>   #define target_info_init(ti_var)        \
>   const TargetInfo *target_info(void)     \
>   {                                       \
>       return &ti_var;                     \
>   }
>   
> +#else /* CONFIG_USER_ONLY */
> +
> +#include "qemu/target-info-qom.h"
> +#include "qom/object.h"
> +
> +#define TYPE_TARGET_INFO_TARGET TYPE_TARGET_INFO"-"TARGET_NAME
> +
> +typedef struct TargetInfoQomTarget {
> +    TargetInfoQom parent;
> +} TargetInfoQomTarget;
> +
> +typedef struct TargetInfoQomTargetClass {
> +    TargetInfoQomClass parent_class;
> +} TargetInfoQomTargetClass;
> +
> +OBJECT_DECLARE_TYPE(TargetInfoQomTarget, TargetInfoQomTargetClass, TARGET_INFO_TARGET)
> +
> +#define target_info_init(ti_var)                                            \
> +const TargetInfo *target_info(void)                                         \
> +{                                                                           \
> +    return &ti_var;                                                         \
> +}                                                                           \
> +                                                                            \
> +static void target_info_qom_class_init(ObjectClass *oc, const void * data)  \
> +{                                                                           \
> +    TargetInfoQomTargetClass *klass = TARGET_INFO_TARGET_CLASS(oc);         \
> +    klass->parent_class.target_info = &ti_var;                              \
> +}                                                                           \
> +                                                                            \
> +static const TypeInfo target_info_qom_target_type_info = {                  \
> +    .name = TYPE_TARGET_INFO_TARGET,                                        \
> +    .parent = TYPE_TARGET_INFO,                                             \
> +    .instance_size = sizeof(TargetInfoQomTarget),                           \
> +    .class_size = sizeof(TargetInfoQomTargetClass),                         \
> +    .class_init = target_info_qom_class_init,                               \
> +    .abstract = false,                                                      \
> +};                                                                          \
> +                                                                            \
> +DEFINE_TARGET_INFO_TYPE(target_info_qom_target_type_info)
> +
> +#endif /* CONFIG_USER_ONLY */
> +#endif /* COMPILING_PER_TARGET */
> +
>   #endif /* TARGET_INFO_DEF_H */

If I understand this correctly, you're getting one symbol passed down as the argument to 
target_info_init, and you're getting another symbol implicitly from TARGET_NAME.

AFAICS, this is incorrect for the configs/targets/*.c versions.
Or at minimum really confusing.

I'm trying to work out how target-info-stub.c and the configs/targets/*.c files can be 
unified.  Perhaps we have one large macro like

#define DEF_TARGET(NAME, ARCH, BITS, ...) \
static const TargetInfo ti = {            \
     .target_name = NAME,                  \
     ...                                   \
}                                         \
static const TypeInfo type_info = {       \
     .name = TYPE_TARGET_INFO "-" NAME,    \
     .class_data = &ti,                    \
}

Note as well that we can use .class_data and .class_base_init to avoid having lots of 
those trivial class_init functions.

Another option might be a .c.inc file which uses TARGET_NAME etc, which we then locally 
#define for the {arm,aarch64}-softmmu.c files prior to the #include.  I can see that might 
have to jump through hoops to avoid poisoned identifiers, but perhaps

---
/* Avoid poisoning identifiers we will supply locally. */
#define COMPILING_PER_TARGET
#include "qemu/osdep.h"
...

#define TARGET_NAME "arm"
...

#include "target-info.c.inc"
---

isn't too horrible, and in the end more readable than a mega macro.


r~

Re: [PATCH v4 4/6] target-info: introduce TargetInfo in QOM

[Pierrick Bouvier]

On 5/8/2026 1:14 PM, Richard Henderson wrote:
> On 5/5/26 17:48, Pierrick Bouvier wrote:
>> diff --git a/include/qemu/target-info-init.h b/include/qemu/target-
>> info-init.h
>> index c781cfc0590..859451c672e 100644
>> --- a/include/qemu/target-info-init.h
>> +++ b/include/qemu/target-info-init.h
>> @@ -12,10 +12,67 @@
>>   #ifndef TARGET_INFO_DEF_H
>>   #define TARGET_INFO_DEF_H
>>   +#define
>> DEFINE_TARGET_INFO_TYPE(info)                                       \
>> +static void
>> do_qemu_init_target_info(void)                                  \
>> +{                                                                           \
>> +   
>> type_register_static(&info);                                            \
>> +}                                                                           \
>> +module_init(do_qemu_init_target_info, MODULE_INIT_TARGET_INFO)
>> +
>> +#ifdef COMPILING_PER_TARGET
>> +#ifdef CONFIG_USER_ONLY
>> +
>> +/*
>> + * User mode does not support multiple targets in the same binary, so
>> just
>> + * define target_info().
>> + */
>>   #define target_info_init(ti_var)        \
>>   const TargetInfo *target_info(void)     \
>>   {                                       \
>>       return &ti_var;                     \
>>   }
>>   +#else /* CONFIG_USER_ONLY */
>> +
>> +#include "qemu/target-info-qom.h"
>> +#include "qom/object.h"
>> +
>> +#define TYPE_TARGET_INFO_TARGET TYPE_TARGET_INFO"-"TARGET_NAME
>> +
>> +typedef struct TargetInfoQomTarget {
>> +    TargetInfoQom parent;
>> +} TargetInfoQomTarget;
>> +
>> +typedef struct TargetInfoQomTargetClass {
>> +    TargetInfoQomClass parent_class;
>> +} TargetInfoQomTargetClass;
>> +
>> +OBJECT_DECLARE_TYPE(TargetInfoQomTarget, TargetInfoQomTargetClass,
>> TARGET_INFO_TARGET)
>> +
>> +#define
>> target_info_init(ti_var)                                            \
>> +const TargetInfo
>> *target_info(void)                                         \
>> +{                                                                           \
>> +    return
>> &ti_var;                                                         \
>> +}                                                                           \
>> +                                                                            \
>> +static void target_info_qom_class_init(ObjectClass *oc, const void *
>> data)  \
>> +{                                                                           \
>> +    TargetInfoQomTargetClass *klass =
>> TARGET_INFO_TARGET_CLASS(oc);         \
>> +    klass->parent_class.target_info =
>> &ti_var;                              \
>> +}                                                                           \
>> +                                                                            \
>> +static const TypeInfo target_info_qom_target_type_info =
>> {                  \
>> +    .name =
>> TYPE_TARGET_INFO_TARGET,                                        \
>> +    .parent =
>> TYPE_TARGET_INFO,                                             \
>> +    .instance_size =
>> sizeof(TargetInfoQomTarget),                           \
>> +    .class_size =
>> sizeof(TargetInfoQomTargetClass),                         \
>> +    .class_init =
>> target_info_qom_class_init,                               \
>> +    .abstract =
>> false,                                                      \
>> +};                                                                          \
>> +                                                                            \
>> +DEFINE_TARGET_INFO_TYPE(target_info_qom_target_type_info)
>> +
>> +#endif /* CONFIG_USER_ONLY */
>> +#endif /* COMPILING_PER_TARGET */
>> +
>>   #endif /* TARGET_INFO_DEF_H */
> 
> If I understand this correctly, you're getting one symbol passed down as
> the argument to target_info_init, and you're getting another symbol
> implicitly from TARGET_NAME.
>

We have the top target-info class, and children classes (one per
target-info-$target). I first relied on QOM instance, but realized we
could simply embed the info we need in class, so everything is available
without needing to instantiate anything.
> AFAICS, this is incorrect for the configs/targets/*.c versions.
> Or at minimum really confusing.
>

I appreciate it can be confusing.
For every configs/targets/*.c, we get a unique QOM type out of this,
with its static class_init and static type_info struct. (1 func + 1
static struct).

From what I understand, the static struct is mandatory (we really need a
proper type per target), but maybe we could factorize the class_init,
and rely on data parameter, as you suggest later in this email.
I thought it was mandatory to have a custom class_init to perform the
cast to child class, but we can as well cast it directly to parent class
and call it a day.

It's my first adventure in QOM territory, and mostly relied on my C++
muscle memory, so it's totally possible I missed a point in how to
design things within QOM constraints.

> I'm trying to work out how target-info-stub.c and the configs/targets/
> *.c files can be unified.  Perhaps we have one large macro like
> 
> #define DEF_TARGET(NAME, ARCH, BITS, ...) \
> static const TargetInfo ti = {            \
>     .target_name = NAME,                  \
>     ...                                   \
> }                                         \
> static const TypeInfo type_info = {       \
>     .name = TYPE_TARGET_INFO "-" NAME,    \
>     .class_data = &ti,                    \
> }
> 
> Note as well that we can use .class_data and .class_base_init to avoid
> having lots of those trivial class_init functions.
>

Yes, will try that.

> Another option might be a .c.inc file which uses TARGET_NAME etc, which
> we then locally #define for the {arm,aarch64}-softmmu.c files prior to
> the #include.  I can see that might have to jump through hoops to avoid
> poisoned identifiers, but perhaps
>
> ---> /* Avoid poisoning identifiers we will supply locally. */
> #define COMPILING_PER_TARGET
> #include "qemu/osdep.h"
> ...
> 
> #define TARGET_NAME "arm"
> ...
> 
> #include "target-info.c.inc"
> ---
> 
> isn't too horrible, and in the end more readable than a mega macro.
>

It came through my mind, but remembered also the times I struggled with
(some) .c.inc files, and wanted to save time for other people that might
have to deal with that part in the future.

With the class_init deduplication, our big scary macro should turn into
a gentle one.

> 
> r~

Thanks for the feedback,
Pierrick

[PATCH v4 5/6] target-info-qom: detect target from QOM

[Pierrick Bouvier]

For now, we expect only one target to be available at runtime. This will
change with the single-binary and we'll detect which one to use
dynamically.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 include/qemu/target-info-qom.h |  2 ++
 system/vl.c                    |  2 ++
 target-info-qom.c              | 16 ++++++++++++++++
 3 files changed, 20 insertions(+)

diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h
index 585995c7ad0..91be415ed33 100644
--- a/include/qemu/target-info-qom.h
+++ b/include/qemu/target-info-qom.h
@@ -25,4 +25,6 @@ typedef struct TargetInfoQomClass {
 
 OBJECT_DECLARE_TYPE(TargetInfoQom, TargetInfoQomClass, TARGET_INFO)
 
+void target_info_qom_set_target(void);
+
 #endif /* QEMU_TARGET_INFO_QOM_H */
diff --git a/system/vl.c b/system/vl.c
index 2b6739271ba..77b2b4e673d 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -28,6 +28,7 @@
 #include "qemu/units.h"
 #include "qemu/module.h"
 #include "qemu/target-info.h"
+#include "qemu/target-info-qom.h"
 #include "exec/cpu-common.h"
 #include "exec/page-vary.h"
 #include "hw/core/qdev-properties.h"
@@ -2891,6 +2892,7 @@ void qemu_init(int argc, char **argv)
     os_setup_limits();
 
     module_call_init(MODULE_INIT_TARGET_INFO);
+    target_info_qom_set_target();
 
     module_init_info(qemu_modinfo);
     module_allow_arch(target_name());
diff --git a/target-info-qom.c b/target-info-qom.c
index ba2c7923760..9d1f50ffcab 100644
--- a/target-info-qom.c
+++ b/target-info-qom.c
@@ -36,3 +36,19 @@ static const TypeInfo target_info_parent_type = {
 };
 
 DEFINE_TARGET_INFO_TYPE(target_info_parent_type)
+
+static const TargetInfo *target_info_ptr;
+
+void target_info_qom_set_target(void)
+{
+    g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false);
+
+    size_t num_found = g_slist_length(targets);
+    if (num_found != 1) {
+        error_setg(&error_fatal, num_found == 0 ?
+                                 "no target-info is available" :
+                                 "more than one target-info is available");
+    }
+
+    target_info_ptr = TARGET_INFO_CLASS(targets->data)->target_info;
+}
-- 
2.43.0

Re: [PATCH v4 5/6] target-info-qom: detect target from QOM

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> For now, we expect only one target to be available at runtime. This will
> change with the single-binary and we'll detect which one to use
> dynamically.
> 
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>   include/qemu/target-info-qom.h |  2 ++
>   system/vl.c                    |  2 ++
>   target-info-qom.c              | 16 ++++++++++++++++
>   3 files changed, 20 insertions(+)
> 
> diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h
> index 585995c7ad0..91be415ed33 100644
> --- a/include/qemu/target-info-qom.h
> +++ b/include/qemu/target-info-qom.h
> @@ -25,4 +25,6 @@ typedef struct TargetInfoQomClass {
>   
>   OBJECT_DECLARE_TYPE(TargetInfoQom, TargetInfoQomClass, TARGET_INFO)
>   
> +void target_info_qom_set_target(void);
> +
>   #endif /* QEMU_TARGET_INFO_QOM_H */
> diff --git a/system/vl.c b/system/vl.c
> index 2b6739271ba..77b2b4e673d 100644
> --- a/system/vl.c
> +++ b/system/vl.c
> @@ -28,6 +28,7 @@
>   #include "qemu/units.h"
>   #include "qemu/module.h"
>   #include "qemu/target-info.h"
> +#include "qemu/target-info-qom.h"
>   #include "exec/cpu-common.h"
>   #include "exec/page-vary.h"
>   #include "hw/core/qdev-properties.h"
> @@ -2891,6 +2892,7 @@ void qemu_init(int argc, char **argv)
>       os_setup_limits();
>   
>       module_call_init(MODULE_INIT_TARGET_INFO);
> +    target_info_qom_set_target();
>   
>       module_init_info(qemu_modinfo);
>       module_allow_arch(target_name());
> diff --git a/target-info-qom.c b/target-info-qom.c
> index ba2c7923760..9d1f50ffcab 100644
> --- a/target-info-qom.c
> +++ b/target-info-qom.c
> @@ -36,3 +36,19 @@ static const TypeInfo target_info_parent_type = {
>   };
>   
>   DEFINE_TARGET_INFO_TYPE(target_info_parent_type)
> +
> +static const TargetInfo *target_info_ptr;
> +
> +void target_info_qom_set_target(void)
> +{
> +    g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false);
> +
> +    size_t num_found = g_slist_length(targets);
> +    if (num_found != 1) {
> +        error_setg(&error_fatal, num_found == 0 ?
> +                                 "no target-info is available" :
> +                                 "more than one target-info is available");
> +    }
> +
> +    target_info_ptr = TARGET_INFO_CLASS(targets->data)->target_info;
> +}

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

For future improvement, I suggest structuring the code more like page-vary-common.c, where 
exactly one compilation unit sees a non-const "TargetInfo target_info", all others see a 
"const TargetInfo target_info", and target_info() the function is eliminated.

One could even plausibly unify page-vary with target-info, rather than duplicating some of 
the page_bits information between the two structures.

Most pieces of target_info are really only referenced at startup, but target_big_endian() 
and target_long_bits() are the big exceptions to that, and it would be really nice for 
them not to require an out-of-line function call.


r~

Re: [PATCH v4 5/6] target-info-qom: detect target from QOM

[Pierrick Bouvier]

On 5/8/2026 1:29 PM, Richard Henderson wrote:
> On 5/5/26 17:48, Pierrick Bouvier wrote:
>> For now, we expect only one target to be available at runtime. This will
>> change with the single-binary and we'll detect which one to use
>> dynamically.
>>
>> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>> ---
>>   include/qemu/target-info-qom.h |  2 ++
>>   system/vl.c                    |  2 ++
>>   target-info-qom.c              | 16 ++++++++++++++++
>>   3 files changed, 20 insertions(+)
>>
>> diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-
>> info-qom.h
>> index 585995c7ad0..91be415ed33 100644
>> --- a/include/qemu/target-info-qom.h
>> +++ b/include/qemu/target-info-qom.h
>> @@ -25,4 +25,6 @@ typedef struct TargetInfoQomClass {
>>     OBJECT_DECLARE_TYPE(TargetInfoQom, TargetInfoQomClass, TARGET_INFO)
>>   +void target_info_qom_set_target(void);
>> +
>>   #endif /* QEMU_TARGET_INFO_QOM_H */
>> diff --git a/system/vl.c b/system/vl.c
>> index 2b6739271ba..77b2b4e673d 100644
>> --- a/system/vl.c
>> +++ b/system/vl.c
>> @@ -28,6 +28,7 @@
>>   #include "qemu/units.h"
>>   #include "qemu/module.h"
>>   #include "qemu/target-info.h"
>> +#include "qemu/target-info-qom.h"
>>   #include "exec/cpu-common.h"
>>   #include "exec/page-vary.h"
>>   #include "hw/core/qdev-properties.h"
>> @@ -2891,6 +2892,7 @@ void qemu_init(int argc, char **argv)
>>       os_setup_limits();
>>         module_call_init(MODULE_INIT_TARGET_INFO);
>> +    target_info_qom_set_target();
>>         module_init_info(qemu_modinfo);
>>       module_allow_arch(target_name());
>> diff --git a/target-info-qom.c b/target-info-qom.c
>> index ba2c7923760..9d1f50ffcab 100644
>> --- a/target-info-qom.c
>> +++ b/target-info-qom.c
>> @@ -36,3 +36,19 @@ static const TypeInfo target_info_parent_type = {
>>   };
>>     DEFINE_TARGET_INFO_TYPE(target_info_parent_type)
>> +
>> +static const TargetInfo *target_info_ptr;
>> +
>> +void target_info_qom_set_target(void)
>> +{
>> +    g_autoptr(GSList) targets =
>> object_class_get_list(TYPE_TARGET_INFO, false);
>> +
>> +    size_t num_found = g_slist_length(targets);
>> +    if (num_found != 1) {
>> +        error_setg(&error_fatal, num_found == 0 ?
>> +                                 "no target-info is available" :
>> +                                 "more than one target-info is
>> available");
>> +    }
>> +
>> +    target_info_ptr = TARGET_INFO_CLASS(targets->data)->target_info;
>> +}
> 
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> 
> For future improvement, I suggest structuring the code more like page-
> vary-common.c, where exactly one compilation unit sees a non-const
> "TargetInfo target_info", all others see a "const TargetInfo
> target_info", and target_info() the function is eliminated.
> 
> One could even plausibly unify page-vary with target-info, rather than
> duplicating some of the page_bits information between the two structures.
> 
> Most pieces of target_info are really only referenced at startup, but
> target_big_endian() and target_long_bits() are the big exceptions to
> that, and it would be really nice for them not to require an out-of-line
> function call.
>

The only point we are still discussing with Philippe is how we'll model
having several targets, especially at the startup, where we create
machines and types. Once you're in a vcpu thread, things are easier as
there is only one context possible.

It does not mean we can't eliminate the function now, and using indirect
struct access instead, but I think we'll need to have something else to
answer the startup phase. And we don't have a clear answer yet.
 >
> r~

Regards,
Pierrick

[PATCH v4 6/6] target-info: replace target_info() in system-mode

[Pierrick Bouvier]

We now can use TargetInfo information available from QOM, and remove
duplicated target_info() symbol.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 include/qemu/target-info-init.h | 5 -----
 target-info-qom.c               | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/qemu/target-info-init.h b/include/qemu/target-info-init.h
index 859451c672e..a9efd8a1e40 100644
--- a/include/qemu/target-info-init.h
+++ b/include/qemu/target-info-init.h
@@ -50,11 +50,6 @@ typedef struct TargetInfoQomTargetClass {
 OBJECT_DECLARE_TYPE(TargetInfoQomTarget, TargetInfoQomTargetClass, TARGET_INFO_TARGET)
 
 #define target_info_init(ti_var)                                            \
-const TargetInfo *target_info(void)                                         \
-{                                                                           \
-    return &ti_var;                                                         \
-}                                                                           \
-                                                                            \
 static void target_info_qom_class_init(ObjectClass *oc, const void * data)  \
 {                                                                           \
     TargetInfoQomTargetClass *klass = TARGET_INFO_TARGET_CLASS(oc);         \
diff --git a/target-info-qom.c b/target-info-qom.c
index 9d1f50ffcab..cc470b3b4d6 100644
--- a/target-info-qom.c
+++ b/target-info-qom.c
@@ -39,6 +39,11 @@ DEFINE_TARGET_INFO_TYPE(target_info_parent_type)
 
 static const TargetInfo *target_info_ptr;
 
+const TargetInfo *target_info(void)
+{
+    return target_info_ptr;
+}
+
 void target_info_qom_set_target(void)
 {
     g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false);
-- 
2.43.0

Re: [PATCH v4 6/6] target-info: replace target_info() in system-mode

[Richard Henderson]

On 5/5/26 17:48, Pierrick Bouvier wrote:
> We now can use TargetInfo information available from QOM, and remove
> duplicated target_info() symbol.
> 
> Reviewed-by: Marc-André Lureau<marcandre.lureau@redhat.com>
> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
> ---
>   include/qemu/target-info-init.h | 5 -----
>   target-info-qom.c               | 5 +++++
>   2 files changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH v4 0/6] single-binary: deduplicate target_info()

[Pierrick Bouvier]

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

Re: [PATCH v4 0/6] single-binary: deduplicate target_info()

[Daniel P. Berrangé]

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

Re: [PATCH v4 0/6] single-binary: deduplicate target_info()

[Pierrick Bouvier]

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

Re: [PATCH v4 0/6] single-binary: deduplicate target_info()

[Pierrick Bouvier]

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