Re: [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> > ---
> >  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?

-- 
Eduardo

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]