From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZiC-0005ep-7y for qemu-devel@nongnu.org; Tue, 06 May 2014 03:22:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhZi7-00043g-CI for qemu-devel@nongnu.org; Tue, 06 May 2014 03:22:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZi7-00043B-4N for qemu-devel@nongnu.org; Tue, 06 May 2014 03:22:43 -0400 Date: Tue, 6 May 2014 09:22:38 +0200 From: Igor Mammedov Message-ID: <20140506092238.570534a8@nial.usersys.redhat.com> In-Reply-To: <20140502144305.GJ3363@otherpad.lan.raisama.net> References: <1398889773-14652-1-git-send-email-ehabkost@redhat.com> <20140502154503.72465f99@nial.usersys.redhat.com> <20140502144305.GJ3363@otherpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Peter Krempa , libvir-list@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Jiri Denemark , Andreas =?ISO-8859-1?B?RuRyYmVy?= On Fri, 2 May 2014 11:43:05 -0300 Eduardo Habkost 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 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(-) > > > > > >