From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlJUx-0000hl-Ov for qemu-devel@nongnu.org; Fri, 16 May 2014 10:52:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlJUq-0008By-Va for qemu-devel@nongnu.org; Fri, 16 May 2014 10:52:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlJUq-0008BQ-Oc for qemu-devel@nongnu.org; Fri, 16 May 2014 10:52:28 -0400 Date: Fri, 16 May 2014 16:52:21 +0200 From: Igor Mammedov Message-ID: <20140516165221.7cd6ee1e@thinkpad> In-Reply-To: <20140515140349.GQ3302@otherpad.lan.raisama.net> References: <20140502154503.72465f99@nial.usersys.redhat.com> <20140502144305.GJ3363@otherpad.lan.raisama.net> <20140506092238.570534a8@nial.usersys.redhat.com> <20140506144256.GU3363@otherpad.lan.raisama.net> <20140506220111.45aa0692@thinkpad> <20140506201957.GW3363@otherpad.lan.raisama.net> <53694624.7050603@suse.de> <20140515143501.5208dd49@nial.usersys.redhat.com> <20140515130751.GN3302@otherpad.lan.raisama.net> <20140515154816.4eb9f775@nial.usersys.redhat.com> <20140515140349.GQ3302@otherpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Thu, 15 May 2014 11:03:49 -0300 Eduardo Habkost wrote: > On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote: > > On Thu, 15 May 2014 10:07:51 -0300 > > Eduardo Habkost wrote: > >=20 > > > On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote: > > > > On Tue, 06 May 2014 22:29:24 +0200 > > > > Andreas F=E4rber wrote: > > > >=20 > > > > > Am 06.05.2014 22:19, schrieb Eduardo Habkost: > > > > > > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote: > > > > > >> On Tue, 6 May 2014 11:42:56 -0300 > > > > > >> Eduardo Habkost wrote: > > > > > >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote: > > > > > >>>> On Fri, 2 May 2014 11:43:05 -0300 > > > > > >>>> Eduardo Habkost wrote: > > > > > >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wro= te: > > > > > >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300 > > > > > >>>>>> Eduardo Habkost wrote: > > > > > >>>>>>> This series allows management code to use object-add on X= 86CPU 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 dat= a. > > > > > >>>> I'm not sure that retrieved possibly not accurate data are u= seful > > > > > >>>> for libvirt. > > > > > >>> "-cpu host" doesn't depend on machine, and is the most import= ant thing > > > > > >>> right now (because libvirt's checks for host QEMU/kernel/CPU > > > > > >>> capabilities is completely broken). > > > > > >> true, but device-add/-cpu host could be used right now to get = the > > > > > >> same CPUID data wile using any machine type or default one wit= hout > > > > > >> any of this patches. > > > > > >=20 > > > > > > device_add can't be used with "-machine none". > > > > >=20 > > > > > I see no reason why we couldn't *make* CPUs work on -machine none= . The > > > > > ICC bus and bridge were a hack to make APIC(?) hot-add work in fa= ce of > > > > > SysBus; if that prohibits other valid uses now, then evaluating I= gor's > > > > > memory work for CPU might be an option. > > > > Yep, if CPU is hot-plugged as bus-less device. > > > > There is a little concern of APIC device if we go that direction si= nce > > > > in addition to hotpluggable BUS, BUS provides address-space for API= C MMIO. > > > > With that resolved, x86-cpu shouldn't depend on any bus and if ther= e isn't > > > > any current user that uses QOM path to CPU for introspecting (Eduar= do's > > > > ABI concern), then it could be done in time for 2.1. > > >=20 > > > Maybe there are no users of the current QOM path, but we do need a > > > stable path to allow management to locate the CPU objects. Do we have > > > one, already? > > >=20 > >=20 > > Can't we add query-cpus QMP command or something like this to hide path > > from user. >=20 > That would work, too. But why is a dedicated "query-cpus" command better > than something like "qom-list path=3D/machine/cpus" (that could simply > return a list of links to the actual CPU objects)? So that not to stall the work on deciding on - if exposing not yet stables QOM paths as stable ABI is a good thing, I recall Andreas objecting to using QOM paths with device hotplug - what paths to CPUs should be wrt stalled topology discussion >=20 > --=20 > Eduardo >=20 --=20 Regards, Igor