Re: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
On Fri, 2 May 2014 11:43:05 -0300
Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
"-cpu host" doesn't depend on machine, and is the most important thing
right now (because libvirt's checks for host QEMU/kernel/CPU
capabilities is completely broken).
About machine-type data: currently libvirt has no concept of
per-machine-type CPU model data, anyway. We (and libvirt) will need to
address this eventually, but considering our track record, I bet the
QEMU community will take a few years to finally provide that info to
libvirt.
In the meantime, we have a partial solution that fits the current
libvirt data model and is better than the current state (where libvirt
has to duplicate the CPU model data).
Maybe they will use this only for "host", maybe they will use this for
all the other CPU models, we are just providing the mechanism, it's
their decision to use it or not.
>
> 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(-)
> > >
> >
>
--
Eduardo