[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7 |
Date: |
Fri, 31 Jan 2014 14:42:07 -0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jan 31, 2014 at 05:06:21PM +0100, Igor Mammedov wrote:
> On Fri, 31 Jan 2014 13:17:53 -0200
> Eduardo Habkost <address@hidden> 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
Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Igor Mammedov, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Paolo Bonzini, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Igor Mammedov, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7,
Eduardo Habkost <=
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Paolo Bonzini, 2014/01/31
- Re: [Qemu-devel] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eric Blake, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Igor Mammedov, 2014/01/31
- Re: [Qemu-devel] [libvirt] [uq/master PATCH 0/7] x86 CPU subclasses, take 7, Eduardo Habkost, 2014/01/31