Patchwork [QEMU,3/3] x86: pc: versioned CPU model names & compatibility aliases

login
register
mail settings
Submitter Eduardo Habkost
Date July 25, 2012, 6:18 p.m.
Message ID <1343240323-7402-4-git-send-email-ehabkost@redhat.com>
Download mbox | patch
Permalink /patch/173238/
State New
Headers show

Comments

Eduardo Habkost - July 25, 2012, 6:18 p.m.
This adds version number to CPU model names on the "pc-<version>"
machine-types, so we can create new models with bug fixes while keeping
compatibility when using older machine-types.

When naming the existing models, I used the last QEMU version where the
model was changed (see summary below), but by coincidence every single
one was changed on QEMU-1.1.

- 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

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 hw/pc_piix.c                       |   56 ++++++++++++++++++++++++++++++++++++
 sysconfigs/target/cpus-x86_64.conf |   18 ++++++------
 2 files changed, 65 insertions(+), 9 deletions(-)
Andreas Färber - July 25, 2012, 10:52 p.m.
Am 25.07.2012 20:18, schrieb Eduardo Habkost:
> This adds version number to CPU model names on the "pc-<version>"
> machine-types, so we can create new models with bug fixes while keeping
> compatibility when using older machine-types.
> 
> When naming the existing models, I used the last QEMU version where the
> model was changed (see summary below), but by coincidence every single
> one was changed on QEMU-1.1.
> 
> - 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
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/pc_piix.c                       |   56 ++++++++++++++++++++++++++++++++++++
>  sysconfigs/target/cpus-x86_64.conf |   18 ++++++------
>  2 files changed, 65 insertions(+), 9 deletions(-)
> 
> 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
>  
> +/* 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 = {
>      .name = "pc-1.2",
>      .alias = "pc",
> @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 = {
>      .init = pc_init_pci,
>      .max_cpus = 255,
>      .is_default = 1,
> +    .cpu_aliases = (CPUModelAlias[]) {
> +        V1_1_CPU_ALIASES
> +        {NULL, NULL},
> +    },
>  };
>  
>  #define PC_COMPAT_1_1 \
[...]
> diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-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
>  
>  [cpudef]
> -   name = "Conroe"
> +   name = "Conroe-1.1"
>     level = "2"
>     vendor = "GenuineIntel"
>     family = "6"
[snip]

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=off" or a nested list of
(property, value) pairs.

As long as there's no concept for actually modelling versioned CPUs, I
consider this RFC stage and not worth merging yet...

Regards,
Andreas
Eduardo Habkost - July 26, 2012, 2:24 p.m.
On Thu, Jul 26, 2012 at 12:52:33AM +0200, Andreas Färber wrote:
> Am 25.07.2012 20:18, schrieb Eduardo Habkost:
> > This adds version number to CPU model names on the "pc-<version>"
> > machine-types, so we can create new models with bug fixes while keeping
> > compatibility when using older machine-types.
> > 
> > When naming the existing models, I used the last QEMU version where the
> > model was changed (see summary below), but by coincidence every single
> > one was changed on QEMU-1.1.
> > 
> > - 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
> > 
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  hw/pc_piix.c                       |   56 ++++++++++++++++++++++++++++++++++++
> >  sysconfigs/target/cpus-x86_64.conf |   18 ++++++------
> >  2 files changed, 65 insertions(+), 9 deletions(-)
> > 
> > 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
> >  
> > +/* 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 = {
> >      .name = "pc-1.2",
> >      .alias = "pc",
> > @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 = {
> >      .init = pc_init_pci,
> >      .max_cpus = 255,
> >      .is_default = 1,
> > +    .cpu_aliases = (CPUModelAlias[]) {
> > +        V1_1_CPU_ALIASES
> > +        {NULL, NULL},
> > +    },
> >  };
> >  
> >  #define PC_COMPAT_1_1 \
> [...]
> > diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-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
> >  
> >  [cpudef]
> > -   name = "Conroe"
> > +   name = "Conroe-1.1"
> >     level = "2"
> >     vendor = "GenuineIntel"
> >     family = "6"
> [snip]
> 
> 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=off" 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".

> 
> 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?
Andreas Färber - July 26, 2012, 2:31 p.m.
Am 26.07.2012 16:24, schrieb Eduardo Habkost:
> On Thu, Jul 26, 2012 at 12:52:33AM +0200, Andreas Färber wrote:
>> Am 25.07.2012 20:18, schrieb Eduardo Habkost:
>>> This adds version number to CPU model names on the "pc-<version>"
>>> machine-types, so we can create new models with bug fixes while keeping
>>> compatibility when using older machine-types.
>>>
>>> When naming the existing models, I used the last QEMU version where the
>>> model was changed (see summary below), but by coincidence every single
>>> one was changed on QEMU-1.1.
>>>
>>> - 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
>>>
>>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>>> ---
>>>  hw/pc_piix.c                       |   56 ++++++++++++++++++++++++++++++++++++
>>>  sysconfigs/target/cpus-x86_64.conf |   18 ++++++------
>>>  2 files changed, 65 insertions(+), 9 deletions(-)
>>>
>>> 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
>>>  
>>> +/* 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 = {
>>>      .name = "pc-1.2",
>>>      .alias = "pc",
>>> @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 = {
>>>      .init = pc_init_pci,
>>>      .max_cpus = 255,
>>>      .is_default = 1,
>>> +    .cpu_aliases = (CPUModelAlias[]) {
>>> +        V1_1_CPU_ALIASES
>>> +        {NULL, NULL},
>>> +    },
>>>  };
>>>  
>>>  #define PC_COMPAT_1_1 \
>> [...]
>>> diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-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
>>>  
>>>  [cpudef]
>>> -   name = "Conroe"
>>> +   name = "Conroe-1.1"
>>>     level = "2"
>>>     vendor = "GenuineIntel"
>>>     family = "6"
>> [snip]
>>
>> 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=off" 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".
> 
>>
>> 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?

I mean, you add infrastructure for remapping Conroe to Conroe-1.1 or
Conroe-x.y, but I am missing something that lets us declare "Conroe-1.1
is Conroe-1.2 with this difference", like we do for machines. We surely
don't want to duplicate everything that stays the same for each new CPU
version.

Andreas
Jiri Denemark - July 26, 2012, 2:33 p.m.
On Wed, Jul 25, 2012 at 15:18:43 -0300, Eduardo Habkost wrote:
> This adds version number to CPU model names on the "pc-<version>"
> machine-types, so we can create new models with bug fixes while keeping
> compatibility when using older machine-types.
> 
> When naming the existing models, I used the last QEMU version where the
> model was changed (see summary below), but by coincidence every single
> one was changed on QEMU-1.1.
> 
> - 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

Hi Eduardo,

What models would be listed by "qemu-system-x86_64 -cpu ?"? Only non-versioned
model aliases or full names with versions or both?

Jirka
Eduardo Habkost - July 26, 2012, 2:48 p.m.
On Thu, Jul 26, 2012 at 04:31:45PM +0200, Andreas Färber wrote:
> Am 26.07.2012 16:24, schrieb Eduardo Habkost:
> > On Thu, Jul 26, 2012 at 12:52:33AM +0200, Andreas Färber wrote:
> >> Am 25.07.2012 20:18, schrieb Eduardo Habkost:
> >>> This adds version number to CPU model names on the "pc-<version>"
> >>> machine-types, so we can create new models with bug fixes while keeping
> >>> compatibility when using older machine-types.
> >>>
> >>> When naming the existing models, I used the last QEMU version where the
> >>> model was changed (see summary below), but by coincidence every single
> >>> one was changed on QEMU-1.1.
> >>>
> >>> - 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
> >>>
> >>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> >>> ---
> >>>  hw/pc_piix.c                       |   56 ++++++++++++++++++++++++++++++++++++
> >>>  sysconfigs/target/cpus-x86_64.conf |   18 ++++++------
> >>>  2 files changed, 65 insertions(+), 9 deletions(-)
> >>>
> >>> 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
> >>>  
> >>> +/* 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 = {
> >>>      .name = "pc-1.2",
> >>>      .alias = "pc",
> >>> @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 = {
> >>>      .init = pc_init_pci,
> >>>      .max_cpus = 255,
> >>>      .is_default = 1,
> >>> +    .cpu_aliases = (CPUModelAlias[]) {
> >>> +        V1_1_CPU_ALIASES
> >>> +        {NULL, NULL},
> >>> +    },
> >>>  };
> >>>  
> >>>  #define PC_COMPAT_1_1 \
> >> [...]
> >>> diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-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
> >>>  
> >>>  [cpudef]
> >>> -   name = "Conroe"
> >>> +   name = "Conroe-1.1"
> >>>     level = "2"
> >>>     vendor = "GenuineIntel"
> >>>     family = "6"
> >> [snip]
> >>
> >> 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=off" 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".
> > 
> >>
> >> 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?
> 
> I mean, you add infrastructure for remapping Conroe to Conroe-1.1 or
> Conroe-x.y, but I am missing something that lets us declare "Conroe-1.1
> is Conroe-1.2 with this difference", like we do for machines. We surely
> don't want to duplicate everything that stays the same for each new CPU
> version.

Oh, that I want too[1], but IMO it's orthogonal to the problem of
actually having the per-machine-type aliases. The per-machine-type
aliases (or properties) are a requirement to allow us to fix bugs while
keeping compatibility an "inheritance" system is something to make the
CPU config files look better and be more maintainable.


[1] There are multiple changes I want to make the cpudef config format:

- Make it based on boolean per-feature flags, not low-level
  feature_<register> bits
- Make it easy to say "model FOO is like model BAR, but with these
  differences"
  - This is useful for versioning but may be useful for cases like
    "SandyBridge has all the features from Westmere, plus these
    additional ones"
Eduardo Habkost - July 26, 2012, 2:54 p.m.
On Thu, Jul 26, 2012 at 04:33:36PM +0200, Jiri Denemark wrote:
> On Wed, Jul 25, 2012 at 15:18:43 -0300, Eduardo Habkost wrote:
> > This adds version number to CPU model names on the "pc-<version>"
> > machine-types, so we can create new models with bug fixes while keeping
> > compatibility when using older machine-types.
> > 
> > When naming the existing models, I used the last QEMU version where the
> > model was changed (see summary below), but by coincidence every single
> > one was changed on QEMU-1.1.
> > 
> > - 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
> 
> Hi Eduardo,
> 
> What models would be listed by "qemu-system-x86_64 -cpu ?"? Only non-versioned
> model aliases or full names with versions or both?

Just the full names. The aliases are machine-type properties, but I
didn't see a good place to list them on the help text. (suggestions are
welcome)

Anyway, "-cpu ?" and "-cpu ?dump" are interfaces for humans. libvirt
will require a new interface that allows it to query the CPU model
versions and the aliases. But defining this interface will be possible
only after we settle on the design of the system inside QEMU. (e.g. if
we implement it based on global properties, there may be no concept of
"versions" and "aliases" at all, and we may have to rethink the way the
QEMU<->libvirt interface will look like).
Igor Mammedov - July 31, 2012, 1:22 p.m.
On Thu, Jul 26, 2012 at 10:48:45AM -0400, Eduardo Habkost wrote:
... 
> 
> [1] There are multiple changes I want to make the cpudef config format:
> 
> - Make it based on boolean per-feature flags, not low-level
>   feature_<register> bits
I'm trying to convert features to properties before looking at global props.
current state is at https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP
Does it represent something you have in mind?

>
... 
> -- 
> Eduardo
>
Eduardo Habkost - July 31, 2012, 1:44 p.m.
On Tue, Jul 31, 2012 at 03:22:59PM +0200, Igor Mammedov wrote:
> On Thu, Jul 26, 2012 at 10:48:45AM -0400, Eduardo Habkost wrote:
> ... 
> > 
> > [1] There are multiple changes I want to make the cpudef config format:
> > 
> > - Make it based on boolean per-feature flags, not low-level
> >   feature_<register> bits
> I'm trying to convert features to properties before looking at global props.
> current state is at https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP
> Does it represent something you have in mind?

Yes, it's like what I have in mind.

But note that cpudefs are not objects, yet. We have lots of people
focusing on the CPU objects themselves, but the cpudefs read from the
config are still plain old structs, with no properties, and there's no
clear plan on how to model them in the code.

Even if we convert the cpudefs to become classes, we still don't have a
simple way to make the cpudef read from the config file set CPU
properties only for specific classes.

Some of the approaches I see:
- Make classes have properties, too;
- Make cpudefs be full-featured objects, that are used as argument when
  creating CPU objects;
- Do it manually: have a feature bitmap (or other data structure) for
  each CPU class, translate the cpudef config options to that bitmap
  manually, and translate it to CPU features manually when creating the
  CPU object;
- Translate all the cpudef sections to global properties, that would
  in turn set CPU properties once the CPU objects are created.

The last option seems to work (once we make the CPU objects really able
to use global properties). But I have the feeling that setting lots of
global properties by default is an abuse of the global property system.

Patch

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
 
+/* 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 = {
     .name = "pc-1.2",
     .alias = "pc",
@@ -356,6 +368,10 @@  static QEMUMachine pc_machine_v1_2 = {
     .init = pc_init_pci,
     .max_cpus = 255,
     .is_default = 1,
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_1_1 \
@@ -386,6 +402,10 @@  static QEMUMachine pc_machine_v1_1 = {
         PC_COMPAT_1_1,
         { /* end of list */ }
     },
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_1_0 \
@@ -422,6 +442,10 @@  static QEMUMachine pc_machine_v1_0 = {
         { /* end of list */ }
     },
     .hw_version = "1.0",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_0_15 \
@@ -437,6 +461,10 @@  static QEMUMachine pc_machine_v0_15 = {
         { /* end of list */ }
     },
     .hw_version = "0.15",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_0_14 \
@@ -478,6 +506,10 @@  static QEMUMachine pc_machine_v0_14 = {
         { /* end of list */ }
     },
     .hw_version = "0.14",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_0_13 \
@@ -515,6 +547,10 @@  static QEMUMachine pc_machine_v0_13 = {
         { /* end of list */ }
     },
     .hw_version = "0.13",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_0_12 \
@@ -548,6 +584,10 @@  static QEMUMachine pc_machine_v0_12 = {
         { /* end of list */ }
     },
     .hw_version = "0.12",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #define PC_COMPAT_0_11 \
@@ -581,6 +621,10 @@  static QEMUMachine pc_machine_v0_11 = {
         { /* end of list */ }
     },
     .hw_version = "0.11",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 static QEMUMachine pc_machine_v0_10 = {
@@ -614,6 +658,10 @@  static QEMUMachine pc_machine_v0_10 = {
         { /* end of list */ }
     },
     .hw_version = "0.10",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 static QEMUMachine isapc_machine = {
@@ -629,6 +677,10 @@  static QEMUMachine isapc_machine = {
         },
         { /* end of list */ }
     },
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 
 #ifdef CONFIG_XEN
@@ -638,6 +690,10 @@  static QEMUMachine xenfv_machine = {
     .init = pc_xen_hvm_init,
     .max_cpus = HVM_MAX_VCPUS,
     .default_machine_opts = "accel=xen",
+    .cpu_aliases = (CPUModelAlias[]) {
+        V1_1_CPU_ALIASES
+        {NULL, NULL},
+    },
 };
 #endif
 
diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-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
 
 [cpudef]
-   name = "Conroe"
+   name = "Conroe-1.1"
    level = "2"
    vendor = "GenuineIntel"
    family = "6"
@@ -15,7 +15,7 @@ 
    model_id = "Intel Celeron_4x0 (Conroe/Merom Class Core 2)"
 
 [cpudef]
-   name = "Penryn"
+   name = "Penryn-1.1"
    level = "2"
    vendor = "GenuineIntel"
    family = "6"
@@ -29,7 +29,7 @@ 
    model_id = "Intel Core 2 Duo P9xxx (Penryn Class Core 2)"
 
 [cpudef]
-   name = "Nehalem"
+   name = "Nehalem-1.1"
    level = "2"
    vendor = "GenuineIntel"
    family = "6"
@@ -43,7 +43,7 @@ 
    model_id = "Intel Core i7 9xx (Nehalem Class Core i7)"
 
 [cpudef]
-   name = "Westmere"
+   name = "Westmere-1.1"
    level = "11"
    vendor = "GenuineIntel"
    family = "6"
@@ -57,7 +57,7 @@ 
    model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)"
 
 [cpudef]
-   name = "SandyBridge"
+   name = "SandyBridge-1.1"
    level = "0xd"
    vendor = "GenuineIntel"
    family = "6"
@@ -71,7 +71,7 @@ 
    model_id = "Intel Xeon E312xx (Sandy Bridge)"
 
 [cpudef]
-   name = "Opteron_G1"
+   name = "Opteron_G1-1.1"
    level = "5"
    vendor = "AuthenticAMD"
    family = "15"
@@ -85,7 +85,7 @@ 
    model_id = "AMD Opteron 240 (Gen 1 Class Opteron)"
 
 [cpudef]
-   name = "Opteron_G2"
+   name = "Opteron_G2-1.1"
    level = "5"
    vendor = "AuthenticAMD"
    family = "15"
@@ -99,7 +99,7 @@ 
    model_id = "AMD Opteron 22xx (Gen 2 Class Opteron)"
 
 [cpudef]
-   name = "Opteron_G3"
+   name = "Opteron_G3-1.1"
    level = "5"
    vendor = "AuthenticAMD"
    family = "15"
@@ -113,7 +113,7 @@ 
    model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)"
 
 [cpudef]
-   name = "Opteron_G4"
+   name = "Opteron_G4-1.1"
    level = "0xd"
    vendor = "AuthenticAMD"
    family = "21"