From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuOhk-0001hr-OR for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:06:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuOhb-0003GK-7f for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:06:16 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45727 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuOha-0003GD-Td for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:06:07 -0400 Message-ID: <50114ECB.1020609@suse.de> Date: Thu, 26 Jul 2012 16:06:03 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1343240323-7402-1-git-send-email-ehabkost@redhat.com> <87boj3v23m.fsf@codemonkey.ws> <20120726135333.GA27859@shell.eng.rdu.redhat.com> In-Reply-To: <20120726135333.GA27859@shell.eng.rdu.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Eduardo Habkost Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , Igor Mammedov , Jiri Denemark 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 defini= tions >>> versioned (to allow them to get bug fixes while allowing migration fr= om older >>> versions and keeping command-line compatibility), and per- machine-ty= pe aliases >>> for compatibility. >>> >>> The lack of CPU model versioning is blocking multiple bug fixes that = are >>> necessary on CPU model definitions, but can't be included today becau= se 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 inter= face that >>> libvirt could use. >> >> This isn't the right approach. The CPU properties should be exposed a= s >> QOM properties which then allows the machine type globals to be used t= o >> control stuff like this. >=20 > I would like to use global properties for this, but the obstacles I hav= e > 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 After Hackweek I plan to put together some compromise or even multiple alternatives. We definitely need this for multiple open issues. > - The per-machine-type properties I need to set are for CPU models, not > CPUs. > - For example: if we fix the Nehalem CPU model by changing the "level= " > 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 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.) 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