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(a)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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg