From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuP07-0003rH-SA for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:25:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuOzw-0001bZ-VA for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:25:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuOzw-0001Zz-NU for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:25:04 -0400 Date: Thu, 26 Jul 2012 10:24:56 -0400 From: Eduardo Habkost Message-ID: <20120726142456.GE27859@shell.eng.rdu.redhat.com> References: <1343240323-7402-1-git-send-email-ehabkost@redhat.com> <1343240323-7402-4-git-send-email-ehabkost@redhat.com> <501078B1.8080103@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <501078B1.8080103@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: libvir-list@redhat.com, Jiri Denemark , Anthony Liguori , qemu-devel@nongnu.org, Gleb Natapov On Thu, Jul 26, 2012 at 12:52:33AM +0200, Andreas F=E4rber wrote: > Am 25.07.2012 20:18, schrieb Eduardo Habkost: > > This adds version number to CPU model names on the "pc-" > > machine-types, so we can create new models with bug fixes while keepi= ng > > compatibility when using older machine-types. > >=20 > > When naming the existing models, I used the last QEMU version where t= he > > model was changed (see summary below), but by coincidence every singl= e > > one was changed on QEMU-1.1. > >=20 > > - Conroe, Penryn, Nehalem, Opteron_G1, Opteron_G2, Opteron_G3: > > added on 0.13, changed on 1.1 > > - Westmere, SandyBridge, Opteron_G4: added on 1.1 > >=20 > > Signed-off-by: Eduardo Habkost > > --- > > hw/pc_piix.c | 56 ++++++++++++++++++++++++++= ++++++++++ > > sysconfigs/target/cpus-x86_64.conf | 18 ++++++------ > > 2 files changed, 65 insertions(+), 9 deletions(-) > >=20 > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > > index 0c0096f..ef3840f 100644 > > --- a/hw/pc_piix.c > > +++ b/hw/pc_piix.c > > @@ -349,6 +349,18 @@ static void pc_xen_hvm_init(ram_addr_t ram_size, > > } > > #endif > > =20 > > +/* CPU aliases for pre-1.2 CPU models */ > > +#define V1_1_CPU_ALIASES \ > > + { "Conroe", "Conroe-1.1" }, \ > > + { "Penryn", "Penryn-1.1" }, \ > > + { "Nehalem", "Nehalem-1.1" }, \ > > + { "Westmere", "Westmere-1.1" }, \ > > + { "SandyBridge", "SandyBridge-1.1" }, \ > > + { "Opteron_G1", "Opteron_G1-1.1" }, \ > > + { "Opteron_G2", "Opteron_G2-1.1" }, \ > > + { "Opteron_G3", "Opteron_G3-1.1" }, \ > > + { "Opteron_G4", "Opteron_G4-1.1" }, > > + > > static QEMUMachine pc_machine_v1_2 =3D { > > .name =3D "pc-1.2", > > .alias =3D "pc", > > @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 =3D { > > .init =3D pc_init_pci, > > .max_cpus =3D 255, > > .is_default =3D 1, > > + .cpu_aliases =3D (CPUModelAlias[]) { > > + V1_1_CPU_ALIASES > > + {NULL, NULL}, > > + }, > > }; > > =20 > > #define PC_COMPAT_1_1 \ > [...] > > diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/c= pus-x86_64.conf > > index cee0ea9..14c7891 100644 > > --- a/sysconfigs/target/cpus-x86_64.conf > > +++ b/sysconfigs/target/cpus-x86_64.conf > > @@ -1,7 +1,7 @@ > > # x86 CPU MODELS > > =20 > > [cpudef] > > - name =3D "Conroe" > > + name =3D "Conroe-1.1" > > level =3D "2" > > vendor =3D "GenuineIntel" > > family =3D "6" > [snip] >=20 > So where are the actual differences between, e.g., Conroe-1.1 and > Conroe? I'd expect we need either an additional string applying > parameter presets such as maybe "x2apic=3Doff" or a nested list of > (property, value) pairs. There are no differences yet, until we make updates in the Conroe model. If we have to make any change (to fix a bug, for example), we would create a "Conroe-1.2" CPU model, and make the "pc-1.2" machine-type alias "Conroe" to "Conroe-1.2" while keeping the older machine-types using "Conroe-1.1". >=20 > As long as there's no concept for actually modelling versioned CPUs, I > consider this RFC stage and not worth merging yet... What do you mean by "no concept for actually modelling versioned CPUs"? You mean there's no use-case or reason for versioning them, or that the series don't model the versioning properly? --=20 Eduardo