From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuP3z-0005PV-Dn for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:29:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuP3s-00030r-7C for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:29:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuP3r-00030b-V3 for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:29:08 -0400 Date: Thu, 26 Jul 2012 10:29:00 -0400 From: Eduardo Habkost Message-ID: <20120726142900.GF27859@shell.eng.rdu.redhat.com> References: <1343240323-7402-1-git-send-email-ehabkost@redhat.com> <87boj3v23m.fsf@codemonkey.ws> <20120726135333.GA27859@shell.eng.rdu.redhat.com> <50114ECB.1020609@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <50114ECB.1020609@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , Igor Mammedov , Jiri Denemark On Thu, Jul 26, 2012 at 04:06:03PM +0200, Andreas F=E4rber wrote: > Am 26.07.2012 15:53, schrieb Eduardo Habkost: > > On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote: > >> Eduardo Habkost writes: > >> > >>> Hi, > >>> > >>> This is the first try at a simple system to make the CPU model defi= nitions > >>> versioned (to allow them to get bug fixes while allowing migration = from older > >>> versions and keeping command-line compatibility), and per- machine-= type aliases > >>> for compatibility. > >>> > >>> The lack of CPU model versioning is blocking multiple bug fixes tha= t are > >>> necessary on CPU model definitions, but can't be included today bec= ause they > >>> would break migration. > >>> > >>> Later, after this gets in (or at least gets some feedback), I plan = to send a > >>> proposal for a machine-friendly CPU feature / CPU model probing int= erface that > >>> libvirt could use. > >> > >> This isn't the right approach. The CPU properties should be exposed= as > >> QOM properties which then allows the machine type globals to be used= to > >> control stuff like this. > >=20 > > I would like to use global properties for this, but the obstacles I h= ave > > found were: > >=20 > > - As far as I can see in the code, global properties are usable only = by > > qdev objects, and CPUs were not qdevfied yet >=20 > After Hackweek I plan to put together some compromise or even multiple > alternatives. We definitely need this for multiple open issues. >=20 > > - The per-machine-type properties I need to set are for CPU models, n= ot > > CPUs. > > - For example: if we fix the Nehalem CPU model by changing the "lev= el" > > field, we need to make the pc-1.1 and lower machine-types to keep > > the old "level" value, but only on the Nehalem CPU model >=20 > Is that part crying for CPU subclasses? Or what is the problem there? > (Still have a mail about -cpudef in my drafts folder, need to post RFC.= ) Maybe, yes. If we have the subclasses, then the only problem I see is that global properties currently require qdev. Maybe having a simple interface non-qdev objects can use to query for global properties would solve that? --=20 Eduardo