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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list