Paolo Bonzini <pbonz...@redhat.com> writes: > On 04/05/20 16:38, Markus Armbruster wrote: >> makes no progreess because OBJECT(dev)->parent is still null, and >> therefore object_unparent() does nothing. >> >> Possible culprit: qdev_try_create() calls qdev_set_parent_bus(), which >> adds the device to the bus, but leaves ->parent null. If this isn't >> wrong outright, it's at least a dangerous state. >> >> Work-around: call qdev_set_id(dev, NULL) right after qdev_create(). >> This sets ->parent. > > That's a good one, and especially a safe one, since it matches > qdev_device_add. It has the disadvantage of having to touch all > qdev_create() calls.
Also, it moves onboard devices from /machine/unattached/ to /machine/peripheral-anon/. I really regard it as a work-around, not a proper solution. > Even better however would be to move the bus argument (and thus > qdev_set_parent_bus) to qdev_init, and likewise in qdev_device_add move > qdev_set_id after qemu_opt_foreach. I looked at the property setters > and couldn't find anything suspicious (somewhat to my surprise), but I > haven't honestly tried. Thus, we satisfy bus_unparent()'s precondition "bus children have a QOM parent"[*] by moving "add to parent bus" next to the place where we ensure "has QOM parent" by putting orphans under /machine/unattached/. Makes sense. If we add to the bus first, the precondition ceases to hold until we realize. Ugly, but harmless unless we manage to actually call the function then. I suspect we can't realize first, because the realize method may want to use the parent bus. We could lift putting orphans under /machine/unattached from device_set_realized() into those callers that don't already assign a QOM parent. Possibly hundreds of places, hmm. We could factor it out into a helper, and call it right before we add to the parent bus. Orphans with a parent bus would get adopted ealier, orphans without one would still get adopted at realize time. I'll play with it. [*] Confusing terminology; two separate parent-child relationships