On Fri, Jan 31, 2014 at 05:06:21PM +0100, Igor Mammedov wrote: > On Fri, 31 Jan 2014 13:17:53 -0200 > Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > > > On Fri, Jan 31, 2014 at 03:50:23PM +0100, Paolo Bonzini wrote: > > > Il 31/01/2014 15:48, Igor Mammedov ha scritto: > > > >that's abusing of object-add interface and due to recent changes, object-add > > > >won't accept arbitrary objects. > > > > > > I hope that sooner or later device hotplug will be doable with > > > object-add too. But yes, in the meanwhile device_add could work, > > > and this patch series is in the right direction anyway. > > > > In that case, what is holding us from setting > > cannot_instantiate_with_device_add_yet on TYPE_X86_CPU? I don't think we > > can recommend using "-device" for CPUs just yet, but we would need to > > allow it in case object-add doesn't work. > > > > (But I liked the fact that object-add worked and (it looks like) it > > didn't run realize(). All libvirt needs is to be able to create the > > object and get instance_init() run, no need for realize() to run.) > > > > I still need to read the reasoning behind the object-add changes. But is > > there some chance we could allow object-add to work for TYPE_X86_CPU > > subclasses, to avoid the device_add/cannot_instantiate_with_device_add_yet issues? > > you can hack around by inheriting from UserCreatable interface, > but question is what kind of information libvirt would expect from > -object xxx-cpu > > if it's going to read/interpret feature words then CPU.instance_init() > is not sufficient, since properties (read as compat props) and > realize() itself are changing feature words and CPU model guest is going > to see is very different from what -object would create. I am not sure yet, but maybe that's a good thing? I mean: libvirt has no concept of CPU models changing depending on machine-type yet, and this will be addressed later. In this case, not having the global properties set on the CPU object could be useful. > > It looks like only -device would be able to create actual CPU models, > but for -device to work we need as minimum this series and conversion > of CPU features to properties in tree. Then I guess we can override > cannot_instantiate_with_device_add_yet for x86 CPUs. Setting cannot_instantiate_with_device_add_yet=false looks much simpler than implementing UserCreatable. My question is: may we do that, already (once this series gets included), or is there something else holding us from doing it? -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
