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 <[email protected]> >> Signed-off-by: Pierrick Bouvier <[email protected]> >> --- >> 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 <[email protected]> > > 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
