From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvPx-0005JE-Pt for qemu-devel@nongnu.org; Thu, 15 May 2014 09:09:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkvPr-0001zl-Nk for qemu-devel@nongnu.org; Thu, 15 May 2014 09:09:49 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43881 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvPr-0001zh-Do for qemu-devel@nongnu.org; Thu, 15 May 2014 09:09:43 -0400 Message-ID: <5374BC95.2010607@suse.de> Date: Thu, 15 May 2014 15:09:41 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1398889773-14652-1-git-send-email-ehabkost@redhat.com> <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> In-Reply-To: <20140515130751.GN3302@otherpad.lan.raisama.net> 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 , Igor Mammedov Cc: libvir-list@redhat.com, Paolo Bonzini , Jiri Denemark , Peter Krempa , qemu-devel@nongnu.org Am 15.05.2014 15:07, schrieb Eduardo Habkost: > 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: >> >>> 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 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. >>>>>> "-cpu host" doesn't depend on machine, and is the most important t= hing >>>>>> 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 without >>>>> any of this patches. >>>> >>>> device_add can't be used with "-machine none". >>> >>> I see no reason why we couldn't *make* CPUs work on -machine none. Th= e >>> ICC bus and bridge were a hack to make APIC(?) hot-add work in face o= f >>> SysBus; if that prohibits other valid uses now, then evaluating Igor'= 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 since >> in addition to hotpluggable BUS, BUS provides address-space for APIC M= MIO. >> With that resolved, x86-cpu shouldn't depend on any bus and if there i= sn't >> any current user that uses QOM path to CPU for introspecting (Eduardo'= 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? No, we don't. That question is intertwined with topology modeling. :/ Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg