On Fri, May 02, 2014 at 04:54:00PM +0200, Paolo Bonzini wrote:
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?
Well, it was extended automatically to all devices for a few days on qemu.git, before TYPE_USER_CREATABLE was introduced. In practice many devices don't like being created without a bus, and/or outside the usual qdev hierarchy, and/or without getting realized=true set, so bad things could happen. Isn't that the reason TYPE_USER_CREATABLE was created? About default values of properties: if all you need is the default value of properties, that data is already present at class_init-time. We could allow class introspection to return that data without creating the objects. It would make sense to me, but I am not sure this would get accepted. See: http://marc.info/?l=qemu-devel&m=139170587709459 In the case of X86CPUs, all attempts to make the data introspectable at compile-time or class_init-time (without requiring CPU instances to be created) didn't work or were rejected in favour of calculating CPUID data at runtime. We are still slowly changing the X86CPU code in a way that would make that data instrospectable without creating the actual objects, but it may take a very long time, and we may never reach that goal.
* 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?
I don't know the answer to that. In my specific use case, I don't care if realized=true is set automatically in the future, as long as QEMU doesn't crash. At least in the case of x86 CPUs, it makes sense to set realized=true only after the CPU is connected to an icc-bus. So, I believe it makes sense to set realized=true only if/when the object is connected/linked to a bus/device that triggers realization, or explicitly using qom-set.
* 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?
How do we handle hotplug of interconnected devices today? -- Eduardo