On Thu, Mar 12, 2026 at 11:39 PM BALATON Zoltan <[email protected]> wrote: > > 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.
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
