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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2 May 2014 11:43:05 -0300
Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote:

> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > On Wed, 30 Apr 2014 17:29:28 -0300
> > Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote:
> > 
> > > This series allows management code to use object-add on X86CPU subclasses, so it
> > Is there any reason why "device-add" couldn't be used?
> 
> It needs to work with "-machine none", device_add requires a bus to
> exist, and there is no icc-bus on machine_none.
The thing is that CPUID is a function of machine so using
"-machine none" will provide only approximately accurate data.
I'm not sure that retrieved possibly not accurate data are useful
for libvirt.

> 
> 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).
> 
> > 
> > 
> > > can use it to probe for CPU model information without re-running QEMU. The main
> > > use case for this is to allow management code to create CPU objects and query
> > > the "feature-words" and "filtered-features" properties on the new objects, to
> > > find out which features each CPU model needs, and to do the same using the
> > > "host" CPU model to check which features can be enabled in a given host.
> > > 
> > > There's experimental libvirt code to use the new command at:
> > >     https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > > The experimental code just create the CPU objects to query for feature
> > > information, but doesn't do anything with that data.
> > > 
> > > Eduardo Habkost (5):
> > >   cpu: Initialize cpu->stopped=true earlier
> > >   cpu: Don't try to pause CPUs if they are already stopped
> > >   pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
> > >   target-i386: Make CPU objects user-creatable
> > >   target-i386: Report QOM class name for CPU definitions
> > > 
> > >  cpus.c            | 13 ++++++++++---
> > >  exec.c            |  1 +
> > >  hw/i386/pc.c      |  2 +-
> > >  qapi-schema.json  |  6 +++++-
> > >  target-i386/cpu.c |  7 +++++++
> > >  5 files changed, 24 insertions(+), 5 deletions(-)
> > > 
> > 
> 

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]