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.
As long as there's no concept for actually modelling versioned CPUs, I
consider this RFC stage and not worth merging yet...
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg