Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 31 Jan 2014 13:17:53 -0200
Eduardo Habkost <ehabkost@redhat.com> 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.

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.
 
> 
> -- 
> Eduardo


-- 
Regards,
  Igor