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

[Eduardo Habkost]

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