qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infinite loop in bus_unparent(), qdev bug or qdev misuse?


From: Paolo Bonzini
Subject: Re: Infinite loop in bus_unparent(), qdev bug or qdev misuse?
Date: Tue, 5 May 2020 18:26:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 05/05/20 18:03, Markus Armbruster wrote:
>> 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/.

Uh indeed.  No that's too ugly.

>> 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.

Shouldn't be a big deal, since users should call either qdev_set_id or
object_property_add_child before device_set_realized.

> I suspect we can't realize first, because the realize method may want to
> use the parent bus.

Right.

Moving the bus to qdev_init would be quite large but hopefully scriptable.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]