[libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing

[Paolo Bonzini]

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