[PATCH 0/7] Fix some -device T,help crashes

[PATCH 0/7] Fix some -device T,help crashes

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Markus reported the following

"""
Watch this:

    $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
    qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

A number of devices crash this way:

* acpi-ged (aarch64 arm i386 loongarch64 x86_64)
* fsl-imx6 (aarch64 arm)
* fsl-imx7 (aarch64 arm)
* fsl-imx8mp (aarch64)
* microchip.pfsoc (riscv64)
* riscv.sifive.e.soc (riscv32 riscv64)
* xlnx-zynqmp (aarch64)
"""

This series fixes the crashes

Alistair Francis (7):
  hw/riscv: sifive_e: Don't call qdev_get_machine in soc init
  hw/riscv: microchip_pfsoc: Don't call qdev_get_machine in soc init
  hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init
  hw/arm: fsl-imx7: Don't call qdev_get_machine in soc init
  hw/arm: fsl-imx8mp: Don't call qdev_get_machine in soc init
  hw/arm: fsl-imx6: Don't call qdev_get_machine in soc init
  hw/acpi: generic_event_device: Don't call qdev_get_machine in soc init

 hw/acpi/generic_event_device.c |  5 ++--
 hw/arm/fsl-imx6.c              | 14 ++++++------
 hw/arm/fsl-imx7.c              | 19 ++++++++-------
 hw/arm/fsl-imx8mp.c            | 13 +++++------
 hw/arm/xlnx-zynqmp.c           | 42 +++++++++++++++-------------------
 hw/riscv/microchip_pfsoc.c     |  6 +++--
 hw/riscv/sifive_e.c            |  8 ++++---
 7 files changed, 52 insertions(+), 55 deletions(-)

-- 
2.53.0

[PATCH 1/7] hw/riscv: sifive_e: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-riscv64 -S -display none -M virt -device riscv.sifive.e.soc,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of setting the CPU
num-harts in the init function let's set it in realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/riscv/sifive_e.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 4cb9c07ffb..e41f4f99e9 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -178,12 +178,12 @@ type_init(sifive_e_machine_init_register_types)
 
 static void sifive_e_soc_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     SiFiveESoCState *s = RISCV_E_SOC(obj);
 
     object_initialize_child(obj, "cpus", &s->cpus, TYPE_RISCV_HART_ARRAY);
-    object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
-                            &error_abort);
+    /* Set the `num-harts` property later as the machine is potentially not
+     * created yet.
+     */
     object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x1004, &error_abort);
     object_initialize_child(obj, "riscv.sifive.e.gpio0", &s->gpio,
                             TYPE_SIFIVE_GPIO);
@@ -200,6 +200,8 @@ static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
 
     object_property_set_str(OBJECT(&s->cpus), "cpu-type", ms->cpu_type,
                             &error_abort);
+    object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
+                            &error_abort);
     sysbus_realize(SYS_BUS_DEVICE(&s->cpus), &error_fatal);
 
     /* Mask ROM */
-- 
2.53.0

[PATCH 2/7] hw/riscv: microchip_pfsoc: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-riscv64 -S -display none -M virt -device microchip.pfsoc,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of setting the CPU
num-harts in the init function let's set it in realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/riscv/microchip_pfsoc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 4ff83e4940..73cc229c54 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -143,7 +143,6 @@ static const MemMapEntry microchip_pfsoc_memmap[] = {
 
 static void microchip_pfsoc_soc_instance_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     MicrochipPFSoCState *s = MICROCHIP_PFSOC(obj);
 
     object_initialize_child(obj, "e-cluster", &s->e_cluster, TYPE_CPU_CLUSTER);
@@ -162,7 +161,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
 
     object_initialize_child(OBJECT(&s->u_cluster), "u-cpus", &s->u_cpus,
                             TYPE_RISCV_HART_ARRAY);
-    qdev_prop_set_uint32(DEVICE(&s->u_cpus), "num-harts", ms->smp.cpus - 1);
+    /* Set the `num-harts` property later as the machine is potentially not
+     * created yet.
+     */
     qdev_prop_set_uint32(DEVICE(&s->u_cpus), "hartid-base", 1);
     qdev_prop_set_string(DEVICE(&s->u_cpus), "cpu-type",
                          TYPE_RISCV_CPU_SIFIVE_U54);
@@ -204,6 +205,7 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
     int i;
 
     sysbus_realize(SYS_BUS_DEVICE(&s->e_cpus), &error_abort);
+    qdev_prop_set_uint32(DEVICE(&s->u_cpus), "num-harts", ms->smp.cpus - 1);
     sysbus_realize(SYS_BUS_DEVICE(&s->u_cpus), &error_abort);
     /*
      * The cluster must be realized after the RISC-V hart array container,
-- 
2.53.0

[PATCH 3/7] hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/arm/xlnx-zynqmp.c | 42 ++++++++++++++++++------------------------
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 5f0e34ccec..979e55e305 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -380,30 +380,15 @@ static void xlnx_zynqmp_create_unimp_mmio(XlnxZynqMPState *s)
 
 static void xlnx_zynqmp_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     XlnxZynqMPState *s = XLNX_ZYNQMP(obj);
     int i;
-    int num_apus = MIN(ms->smp.cpus, XLNX_ZYNQMP_NUM_APU_CPUS);
-    int num_rpus = xlnx_zynqmp_get_rpu_number(ms);
 
     object_initialize_child(obj, "apu-cluster", &s->apu_cluster,
                             TYPE_CPU_CLUSTER);
     qdev_prop_set_uint32(DEVICE(&s->apu_cluster), "cluster-id", 0);
 
-    for (i = 0; i < num_apus; i++) {
-        object_initialize_child(OBJECT(&s->apu_cluster), "apu-cpu[*]",
-                                &s->apu_cpu[i],
-                                ARM_CPU_TYPE_NAME("cortex-a53"));
-    }
-
     object_initialize_child(obj, "gic", &s->gic, gic_class_name());
 
-    if (num_rpus) {
-        /* Do not create the rpu_gic if we don't have rpus */
-        object_initialize_child(obj, "rpu_gic", &s->rpu_gic,
-                                gic_class_name());
-    }
-
     for (i = 0; i < XLNX_ZYNQMP_NUM_GEMS; i++) {
         object_initialize_child(obj, "gem[*]", &s->gem[i], TYPE_CADENCE_GEM);
         object_initialize_child(obj, "gem-irq-orgate[*]",
@@ -453,15 +438,6 @@ static void xlnx_zynqmp_init(Object *obj)
     object_initialize_child(obj, "qspi-irq-orgate",
                             &s->qspi_irq_orgate, TYPE_OR_IRQ);
 
-    if (num_rpus) {
-        for (i = 0; i < ARRAY_SIZE(s->splitter); i++) {
-            g_autofree char *name = g_strdup_printf("irq-splitter%d", i);
-            object_initialize_child(obj, name, &s->splitter[i], TYPE_SPLIT_IRQ);
-        }
-    }
-
-
-
     for (i = 0; i < XLNX_ZYNQMP_NUM_USB; i++) {
         object_initialize_child(obj, "usb[*]", &s->usb[i], TYPE_USB_DWC3);
     }
@@ -483,6 +459,24 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
 
     ram_size = memory_region_size(s->ddr_ram);
 
+    for (i = 0; i < num_apus; i++) {
+        object_initialize_child(OBJECT(&s->apu_cluster), "apu-cpu[*]",
+                                &s->apu_cpu[i],
+                                ARM_CPU_TYPE_NAME("cortex-a53"));
+    }
+
+    if (num_rpus) {
+        /* Do not create the rpu_gic if we don't have rpus */
+        object_initialize_child(OBJECT(dev), "rpu_gic", &s->rpu_gic,
+                                gic_class_name());
+
+        for (i = 0; i < ARRAY_SIZE(s->splitter); i++) {
+            g_autofree char *name = g_strdup_printf("irq-splitter%d", i);
+            object_initialize_child(OBJECT(dev), name, &s->splitter[i], TYPE_SPLIT_IRQ);
+        }
+    }
+
+
     /*
      * Create the DDR Memory Regions. User friendly checks should happen at
      * the board level
-- 
2.53.0

[PATCH 4/7] hw/arm: fsl-imx7: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-aarch64 -S -display none -M virt -device fsl-imx7,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/arm/fsl-imx7.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c
index 9a230d222f..2defa498d3 100644
--- a/hw/arm/fsl-imx7.c
+++ b/hw/arm/fsl-imx7.c
@@ -32,20 +32,10 @@
 
 static void fsl_imx7_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     FslIMX7State *s = FSL_IMX7(obj);
     char name[NAME_SIZE];
     int i;
 
-    /*
-     * CPUs
-     */
-    for (i = 0; i < MIN(ms->smp.cpus, FSL_IMX7_NUM_CPUS); i++) {
-        snprintf(name, NAME_SIZE, "cpu%d", i);
-        object_initialize_child(obj, name, &s->cpu[i],
-                                ARM_CPU_TYPE_NAME("cortex-a7"));
-    }
-
     /*
      * A7MPCORE
      */
@@ -179,6 +169,15 @@ static void fsl_imx7_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    /*
+     * CPUs
+     */
+    for (i = 0; i < smp_cpus; i++) {
+        snprintf(name, NAME_SIZE, "cpu%d", i);
+        object_initialize_child(OBJECT(dev), name, &s->cpu[i],
+                                ARM_CPU_TYPE_NAME("cortex-a7"));
+    }
+
     /*
      * CPUs
      */
-- 
2.53.0

[PATCH 5/7] hw/arm: fsl-imx8mp: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-aarch64 -S -display none -M virt -device fsl-imx8mp,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/arm/fsl-imx8mp.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/arm/fsl-imx8mp.c b/hw/arm/fsl-imx8mp.c
index 79f9142777..b36df82971 100644
--- a/hw/arm/fsl-imx8mp.c
+++ b/hw/arm/fsl-imx8mp.c
@@ -193,16 +193,9 @@ static const struct {
 
 static void fsl_imx8mp_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     FslImx8mpState *s = FSL_IMX8MP(obj);
-    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
     int i;
 
-    for (i = 0; i < MIN(ms->smp.cpus, FSL_IMX8MP_NUM_CPUS); i++) {
-        g_autofree char *name = g_strdup_printf("cpu%d", i);
-        object_initialize_child(obj, name, &s->cpu[i], cpu_type);
-    }
-
     object_initialize_child(obj, "gic", &s->gic, gicv3_class_name());
 
     object_initialize_child(obj, "ccm", &s->ccm, TYPE_IMX8MP_CCM);
@@ -265,6 +258,7 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
     MachineState *ms = MACHINE(qdev_get_machine());
     FslImx8mpState *s = FSL_IMX8MP(dev);
     DeviceState *gicdev = DEVICE(&s->gic);
+    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
     int i;
 
     if (ms->smp.cpus > FSL_IMX8MP_NUM_CPUS) {
@@ -273,6 +267,11 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    for (i = 0; i < ms->smp.cpus; i++) {
+        g_autofree char *name = g_strdup_printf("cpu%d", i);
+        object_initialize_child(OBJECT(dev), name, &s->cpu[i], cpu_type);
+    }
+
     /* CPUs */
     for (i = 0; i < ms->smp.cpus; i++) {
         /* On uniprocessor, the CBAR is set to 0 */
-- 
2.53.0

[PATCH 6/7] hw/arm: fsl-imx6: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-aarch64 -S -display none -M virt -device fsl-imx6,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/arm/fsl-imx6.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/arm/fsl-imx6.c b/hw/arm/fsl-imx6.c
index 39667c4a49..f663ddbf0a 100644
--- a/hw/arm/fsl-imx6.c
+++ b/hw/arm/fsl-imx6.c
@@ -38,17 +38,10 @@
 
 static void fsl_imx6_init(Object *obj)
 {
-    MachineState *ms = MACHINE(qdev_get_machine());
     FslIMX6State *s = FSL_IMX6(obj);
     char name[NAME_SIZE];
     int i;
 
-    for (i = 0; i < MIN(ms->smp.cpus, FSL_IMX6_NUM_CPUS); i++) {
-        snprintf(name, NAME_SIZE, "cpu%d", i);
-        object_initialize_child(obj, name, &s->cpu[i],
-                                ARM_CPU_TYPE_NAME("cortex-a9"));
-    }
-
     object_initialize_child(obj, "a9mpcore", &s->a9mpcore, TYPE_A9MPCORE_PRIV);
 
     object_initialize_child(obj, "ccm", &s->ccm, TYPE_IMX6_CCM);
@@ -119,6 +112,7 @@ static void fsl_imx6_realize(DeviceState *dev, Error **errp)
     unsigned int smp_cpus = ms->smp.cpus;
     DeviceState *mpcore = DEVICE(&s->a9mpcore);
     DeviceState *gic;
+    char name[NAME_SIZE];
 
     if (smp_cpus > FSL_IMX6_NUM_CPUS) {
         error_setg(errp, "%s: Only %d CPUs are supported (%d requested)",
@@ -126,6 +120,12 @@ static void fsl_imx6_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    for (i = 0; i < smp_cpus; i++) {
+        snprintf(name, NAME_SIZE, "cpu%d", i);
+        object_initialize_child(OBJECT(dev), name, &s->cpu[i],
+                                ARM_CPU_TYPE_NAME("cortex-a9"));
+    }
+
     for (i = 0; i < smp_cpus; i++) {
 
         /* On uniprocessor, the CBAR is set to 0 */
-- 
2.53.0

[PATCH 7/7] hw/acpi: generic_event_device: Don't call qdev_get_machine in soc init

[alistair23]

From: Alistair Francis <alistair.francis@wdc.com>

Calling qdev_get_machine() in the soc_init function would result in
the following assert

    ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

when trying to run

    ./qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help

as the machine wasn't created yet. We call qdev_get_machine() to obtain
the ram slots of the machine. So instead of initialising the GED in
the init let's instead do it in the realise where the machine
will exist.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/acpi/generic_event_device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 30dab43a00..9e9416d406 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -506,6 +506,9 @@ static void acpi_ged_realize(DeviceState *dev, Error **errp)
     uint32_t ged_events;
     int i;
 
+    acpi_memory_hotplug_init(&s->container_memhp, OBJECT(dev),
+                             &s->memhp_state, 0);
+
     if (pcihp_state->use_acpi_hotplug_bridge) {
         s->ged_event_bitmap |= ACPI_GED_PCI_HOTPLUG_EVT;
     }
@@ -568,8 +571,6 @@ static void acpi_ged_initfn(Object *obj)
     memory_region_init(&s->container_memhp, OBJECT(dev), "memhp container",
                        MEMORY_HOTPLUG_IO_LEN);
     sysbus_init_mmio(sbd, &s->container_memhp);
-    acpi_memory_hotplug_init(&s->container_memhp, OBJECT(dev),
-                             &s->memhp_state, 0);
 
     memory_region_init_io(&ged_st->regs, obj, &ged_regs_ops, ged_st,
                           TYPE_ACPI_GED "-regs", ACPI_GED_REG_COUNT);
-- 
2.53.0

Re: [PATCH 0/7] Fix some -device T,help crashes

[Markus Armbruster]

alistair23@gmail.com writes:

> From: Alistair Francis <alistair.francis@wdc.com>
>
> Markus reported the following
>
> """
> Watch this:
>
>     $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>     qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

The comment right before the assertion explains:

        /*
         * Any call to this function before machine is created is treated
         * as a programming error as of now.
         */

i.e. we're talking about straightforward programming errors.

> A number of devices crash this way:
>
> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
> * fsl-imx6 (aarch64 arm)
> * fsl-imx7 (aarch64 arm)
> * fsl-imx8mp (aarch64)
> * microchip.pfsoc (riscv64)
> * riscv.sifive.e.soc (riscv32 riscv64)
> * xlnx-zynqmp (aarch64)
> """
>
> This series fixes the crashes

Series
Tested-by: Markus Armbruster <armbru@redhat.com>

Re: [PATCH 1/7] hw/riscv: sifive_e: Don't call qdev_get_machine in soc init

[Peter Maydell]

On Thu, 12 Mar 2026 at 04:33, <alistair23@gmail.com> wrote:
>
> From: Alistair Francis <alistair.francis@wdc.com>
>
> Calling qdev_get_machine() in the soc_init function would result in
> the following assert
>
>     ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>
> when trying to run
>
>     ./qemu-system-riscv64 -S -display none -M virt -device riscv.sifive.e.soc,help
>
> as the machine wasn't created yet. We call qdev_get_machine() to obtain
> the number of CPUs in the machine. So instead of setting the CPU
> num-harts in the init function let's set it in realise where the machine
> will exist.
>
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

I think our general intended pattern is:
 * init the child in init
 * configure and realize the child in realize

So unless there's a specific reason to be setting properties on
the child in init, moving them to realize is the right thing.

thanks
-- PMM

Re: [PATCH 3/7] hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init

[Peter Maydell]

On Thu, 12 Mar 2026 at 04:32, <alistair23@gmail.com> wrote:
>
> From: Alistair Francis <alistair.francis@wdc.com>
>
> Calling qdev_get_machine() in the soc_init function would result in
> the following assert
>
>     ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>
> when trying to run
>
>     ./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help
>
> as the machine wasn't created yet. We call qdev_get_machine() to obtain
> the number of CPUs in the machine. So instead of initialising the CPUs in
> the SoC init let's instead do it in the realise where the machine
> will exist.

Here I'm not sure I agree. We should init child objects in init, not in
realize, unless there's a strong reason we need to not do that.
Working around "we crash if the user does something pointless
on the command line" isn't a strong enough reason IMHO.

The problem here, though, is of the kind "what child objects we
need depends on the configuration of this device", which kind of
pushes "init children" into "realize". We do that in some places
already. But I don't like that -- it makes us inconsistent about
how we handle child init. If we're OK doing some child init in
the parent's realize method, why not do all child init in realize?

thanks
-- PMM

Re: [PATCH 7/7] hw/acpi: generic_event_device: Don't call qdev_get_machine in soc init

[Thomas Huth]

On 12/03/2026 05.31, alistair23@gmail.com wrote:
> From: Alistair Francis <alistair.francis@wdc.com>
> 
> Calling qdev_get_machine() in the soc_init function would result in

soc_init sounds wrong for this device?

Maybe replace this with:

Calling qdev_get_machine() in acpi_ged_initfn() (via 
acpi_memory_hotplug_init()) results in the following assert

?

With that fixed:
Reviewed-by: Thomas Huth <thuth@redhat.com>


> the following assert
> 
>      ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
> 
> when trying to run
> 
>      ./qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
> 
> as the machine wasn't created yet. We call qdev_get_machine() to obtain
> the ram slots of the machine. So instead of initialising the GED in
> the init let's instead do it in the realise where the machine
> will exist.
> 
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> ---
>   hw/acpi/generic_event_device.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> index 30dab43a00..9e9416d406 100644
> --- a/hw/acpi/generic_event_device.c
> +++ b/hw/acpi/generic_event_device.c
> @@ -506,6 +506,9 @@ static void acpi_ged_realize(DeviceState *dev, Error **errp)
>       uint32_t ged_events;
>       int i;
>   
> +    acpi_memory_hotplug_init(&s->container_memhp, OBJECT(dev),
> +                             &s->memhp_state, 0);
> +
>       if (pcihp_state->use_acpi_hotplug_bridge) {
>           s->ged_event_bitmap |= ACPI_GED_PCI_HOTPLUG_EVT;
>       }
> @@ -568,8 +571,6 @@ static void acpi_ged_initfn(Object *obj)
>       memory_region_init(&s->container_memhp, OBJECT(dev), "memhp container",
>                          MEMORY_HOTPLUG_IO_LEN);
>       sysbus_init_mmio(sbd, &s->container_memhp);
> -    acpi_memory_hotplug_init(&s->container_memhp, OBJECT(dev),
> -                             &s->memhp_state, 0);
>   
>       memory_region_init_io(&ged_st->regs, obj, &ged_regs_ops, ged_st,
>                             TYPE_ACPI_GED "-regs", ACPI_GED_REG_COUNT);

Re: [PATCH 3/7] hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init

[BALATON Zoltan]

On Thu, 12 Mar 2026, Peter Maydell wrote:
> On Thu, 12 Mar 2026 at 04:32, <alistair23@gmail.com> wrote:
>>
>> From: Alistair Francis <alistair.francis@wdc.com>
>>
>> Calling qdev_get_machine() in the soc_init function would result in
>> the following assert
>>
>>     ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>>
>> when trying to run
>>
>>     ./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help
>>
>> as the machine wasn't created yet. We call qdev_get_machine() to obtain
>> the number of CPUs in the machine. So instead of initialising the CPUs in
>> the SoC init let's instead do it in the realise where the machine
>> will exist.
>
> Here I'm not sure I agree. We should init child objects in init, not in
> realize, unless there's a strong reason we need to not do that.
> Working around "we crash if the user does something pointless
> on the command line" isn't a strong enough reason IMHO.
>
> The problem here, though, is of the kind "what child objects we
> need depends on the configuration of this device", which kind of
> pushes "init children" into "realize". We do that in some places
> already. But I don't like that -- it makes us inconsistent about
> how we handle child init. If we're OK doing some child init in
> the parent's realize method, why not do all child init in realize?

How about saying that we do most things in realize (so simple devices 
don't even need an init method) and do in init those that need to be done 
before realize such as things exposing properties that can be set before 
realize. I think that's better than always splitting init and realize for 
all children that's most of the time would just add complexity without 
reason.

This is similar to what I asked about in
https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg03945.html

Regards,
BALATON Zoltan

Re: [PATCH 3/7] hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init

[Alistair Francis]

On Thu, Mar 12, 2026 at 11:39 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Thu, 12 Mar 2026, Peter Maydell wrote:
> > On Thu, 12 Mar 2026 at 04:32, <alistair23@gmail.com> wrote:
> >>
> >> From: Alistair Francis <alistair.francis@wdc.com>
> >>
> >> Calling qdev_get_machine() in the soc_init function would result in
> >> the following assert
> >>
> >>     ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
> >>
> >> when trying to run
> >>
> >>     ./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help
> >>
> >> as the machine wasn't created yet. We call qdev_get_machine() to obtain
> >> the number of CPUs in the machine. So instead of initialising the CPUs in
> >> the SoC init let's instead do it in the realise where the machine
> >> will exist.
> >
> > Here I'm not sure I agree. We should init child objects in init, not in
> > realize, unless there's a strong reason we need to not do that.
> > Working around "we crash if the user does something pointless
> > on the command line" isn't a strong enough reason IMHO.

Agreed, but there is an actual reason (maybe I should have been
clearer in the commit message). At SoC init the configuration for the
machine might not have been completed. So we don't have enough
information to init some child objects.

> >
> > The problem here, though, is of the kind "what child objects we
> > need depends on the configuration of this device", which kind of
> > pushes "init children" into "realize". We do that in some places

Exactly

> > already. But I don't like that -- it makes us inconsistent about
> > how we handle child init. If we're OK doing some child init in
> > the parent's realize method, why not do all child init in realize?

I agree it's not ideal. I think of it as we init children in the
parent init unless we can't because we depend on some configuration
data. At that point then we just have to do it in realise. We don't
really have much of an option. Maybe in the future things change and
we can revert this back, but for the time being I don't think there is
a better option

>
> How about saying that we do most things in realize (so simple devices
> don't even need an init method) and do in init those that need to be done
> before realize such as things exposing properties that can be set before
> realize. I think that's better than always splitting init and realize for
> all children that's most of the time would just add complexity without
> reason.

I do think we should strive to do all children init in the parent init
function, just sometimes we can't if we depend no certain config
information

Alistair

>
> This is similar to what I asked about in
> https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg03945.html
>
> Regards,
> BALATON Zoltan

Re: [PATCH 3/7] hw/arm: xlnx-zynqmp: Don't call qdev_get_machine in soc init

[Thomas Huth]

On 13/03/2026 01.18, Alistair Francis wrote:
> On Thu, Mar 12, 2026 at 11:39 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Thu, 12 Mar 2026, Peter Maydell wrote:
>>> On Thu, 12 Mar 2026 at 04:32, <alistair23@gmail.com> wrote:
>>>>
>>>> From: Alistair Francis <alistair.francis@wdc.com>
>>>>
>>>> Calling qdev_get_machine() in the soc_init function would result in
>>>> the following assert
>>>>
>>>>      ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>>>>
>>>> when trying to run
>>>>
>>>>      ./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help
>>>>
>>>> as the machine wasn't created yet. We call qdev_get_machine() to obtain
>>>> the number of CPUs in the machine. So instead of initialising the CPUs in
>>>> the SoC init let's instead do it in the realise where the machine
>>>> will exist.
>>>
>>> Here I'm not sure I agree. We should init child objects in init, not in
>>> realize, unless there's a strong reason we need to not do that.
>>> Working around "we crash if the user does something pointless
>>> on the command line" isn't a strong enough reason IMHO.
> 
> Agreed, but there is an actual reason (maybe I should have been
> clearer in the commit message). At SoC init the configuration for the
> machine might not have been completed. So we don't have enough
> information to init some child objects.
> 
>>>
>>> The problem here, though, is of the kind "what child objects we
>>> need depends on the configuration of this device", which kind of
>>> pushes "init children" into "realize". We do that in some places
> 
> Exactly
> 
>>> already. But I don't like that -- it makes us inconsistent about
>>> how we handle child init. If we're OK doing some child init in
>>> the parent's realize method, why not do all child init in realize?
> 
> I agree it's not ideal. I think of it as we init children in the
> parent init unless we can't because we depend on some configuration
> data. At that point then we just have to do it in realise. We don't
> really have much of an option. Maybe in the future things change and
> we can revert this back, but for the time being I don't think there is
> a better option

I think I agree with Alistair here. First, let's state that ideally, the SoC 
device should not query the amount of CPUs, but have a property that 
specifies this configuration, and it is then up to the machine init code to 
set that configuration when creating the devices of the machine. But we then 
still have the problem that the instance_init function of the device is 
called before the machine code can set the property. Or is there a way to 
set properties before the instance of a device has been created? (global 
properties maybe, but that's ugly, too?)

So I think for the time being, let's use Alistair's patches to fix the 
crashes. We can still rework the code later in case we find a better 
solution. Thus I'll add the series to my next pull request if there are no 
objections.

  Thomas