On Wed, 29 Oct 2025 at 07:53, Philippe Mathieu-Daudé <[email protected]> wrote: > > QOM .instance_init() handler can not fail. QDev DeviceRealize > can. > > The device-introspect QTest enumerates all QDev types and > instantiate each one, without realizing it, then introspects > the instance properties. > > When switching to a single QEMU binary, all QDev types are > available in the binary, but only a filtered subset might be > available, depending on which previous target the binary is > trying to mimic. > > In particular with the Raspi machines, the TYPE_RASPI4B_MACHINE > and ARM_CPU_TYPE_NAME("cortex-a72") will be built in the > qemu-system-arm binary, while not available (because filtered > as being 64-bit, for the qemu-system-aarch64 binary). > > However the TYPE_BCM2838 SoC is not filtered out, and will > abort when being initialized, because the "cortex-a72" CPU type > is filtered out, leading to device-introspect failure: > > 1/1 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test ERROR > 2.46s killed by signal 6 SIGABRT > stderr: > unknown type 'cortex-a72-arm-cpu' > Broken pipe > ../../tests/qtest/libqtest.c:199: kill_qemu() tried to terminate QEMU > process but encountered exit status 1 (expected 0) > (test program exited with status code -6) > TAP parsing error: Too few tests run (expected 167, got 5) > > In order to avoid that, move the CPU *initialization* in the > SoC DeviceRealize handler, so the SoC initialization won't > fail, while realization still will. > > Signed-off-by: Philippe Mathieu-Daudé <[email protected]> > --- > hw/arm/bcm2836.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c > index cd61ba15054..6e4066f137d 100644 > --- a/hw/arm/bcm2836.c > +++ b/hw/arm/bcm2836.c > @@ -25,12 +25,7 @@ static void bcm283x_base_init(Object *obj) > { > BCM283XBaseState *s = BCM283X_BASE(obj); > BCM283XBaseClass *bc = BCM283X_BASE_GET_CLASS(obj); > - int n; > > - for (n = 0; n < bc->core_count; n++) { > - object_initialize_child(obj, "cpu[*]", &s->cpu[n].core, > - bc->cpu_type); > - } > if (bc->core_count > 1) { > qdev_property_add_static(DEVICE(obj), > &bcm2836_enabled_cores_property); > qdev_prop_set_uint32(DEVICE(obj), "enabled-cpus", bc->core_count); > @@ -65,6 +60,11 @@ bool bcm283x_common_realize(DeviceState *dev, > BCMSocPeripheralBaseState *ps, > BCM283XBaseClass *bc = BCM283X_BASE_GET_CLASS(dev); > Object *obj; > > + for (int n = 0; n < bc->core_count; n++) { > + object_initialize_child(OBJECT(dev), "cpu[*]", &s->cpu[n].core, > + bc->cpu_type); > + } > +
This seems a bit odd to me. Yes, object instance_init isn't allowed to fail. But it's OK for one object to init another in its own init method, exactly because of this. And even if we do move this, the failure won't cause the realize method to fail cleanly, because object_initialize_child() doesn't return a failure message. The problem as described in the commit message seems to be fairly general: we have effectively blacklisted some types as "not really creatable", but we haven't got a mechanism for propagating that to other types that unconditionally use those. Working around this problem by moving child init from init to realize in parent classes is going to result in a lot of weird parent classes that do work in realize that ought to be in init. I think we should either: (1) find a way to propagate the "this type doesn't really exist for this binary" downwards (2) allow the "shouldn't really exist types" to be created programmatically, but just don't advertise them to the user. thanks -- PMM
