On Thu, 12 Mar 2026, Peter Maydell wrote:
On Thu, 12 Mar 2026 at 04:32, <[email protected]> wrote:
From: Alistair Francis <[email protected]>
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
