|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing |
Date: | Fri, 02 May 2014 16:54:00 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
The first thing I considered was making icc-bus user-creatable. Then I noticed it wouldn't work because object-add always add objects to /objects, not inside the qdev hierarchy (that's where device_add looks for the bus). So, allowing device_add could be possible, but would require changing more basic infrastructure: either allowing bus-less devices on device_add, or allowing device_add to add devices outside the qdev hierarchy, or allowing object-add to create objects outside /objects. Simply making CPU objects work with object-add was much simpler and less intrusive. And it had the interesting side-effect of _not_ doing things that are not required for CPU model probing (like creating an actual VCPU thread).
I like this series in general. I have only some doubts about making the code somewhat future-proof, hence the three questions I have are really variations of this same doubt:
* is it worthwhile to extend this to other devices, for management to query default values of the properties?
* how does this interact with future QOMification of device hotplug where devices will be hotplugged with object-add? Should Device::UserCreatable::complete set realized to true in this case in the future? How will Device::UserCreatable::complete distinguish the two cases?
* Related to this, if Device::UserCreatable::complete will set realized to true, how will we handle hotplug of interconnected devices where device 1 needs a link to device 2 and device 2 needs a link to device 1?
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |