Re: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
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