[Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Eduardo Habkost]

This makes the change we discussed on the latest KVM conf call[1], moving the
existing cpudefs from cpus-x86_64.conf to the C code.

The config file data was converted to C using a script, available at:
https://gist.github.com/3229602

Except by the extra square brackets around the CPU model names (indicating they
are built-in models), the output of "-cpu ?dump" is exactly the same before and
after applying this series.

[1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328

Eduardo Habkost (3):
  i386: add missing CPUID_* constants
  move CPU models from cpus-x86_64.conf to C
  eliminate cpus-x86_64.conf file

 Makefile                           |   1 -
 arch_init.c                        |   1 -
 sysconfigs/target/cpus-x86_64.conf | 128 ----------------------
 target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
 target-i386/cpu.h                  |  22 ++++
 5 files changed, 241 insertions(+), 130 deletions(-)
 delete mode 100644 sysconfigs/target/cpus-x86_64.conf

-- 
1.7.11.2

[Qemu-devel] [PATCH 1/3] i386: add missing CPUID_* constants

[Eduardo Habkost]

Those constants will be used by new CPU model definitions.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target-i386/cpu.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 2a61c81..c81f7bf 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -382,6 +382,7 @@
 #define CPUID_PBE (1 << 31)
 
 #define CPUID_EXT_SSE3     (1 << 0)
+#define CPUID_EXT_PCLMULQDQ (1 << 1)
 #define CPUID_EXT_DTES64   (1 << 2)
 #define CPUID_EXT_MONITOR  (1 << 3)
 #define CPUID_EXT_DSCPL    (1 << 4)
@@ -401,14 +402,33 @@
 #define CPUID_EXT_MOVBE    (1 << 22)
 #define CPUID_EXT_POPCNT   (1 << 23)
 #define CPUID_EXT_TSC_DEADLINE_TIMER (1 << 24)
+#define CPUID_EXT_AES      (1 << 25)
 #define CPUID_EXT_XSAVE    (1 << 26)
 #define CPUID_EXT_OSXSAVE  (1 << 27)
+#define CPUID_EXT_AVX      (1 << 28)
 #define CPUID_EXT_HYPERVISOR  (1 << 31)
 
+#define CPUID_EXT2_FPU     (1 << 0)
+#define CPUID_EXT2_DE      (1 << 2)
+#define CPUID_EXT2_PSE     (1 << 3)
+#define CPUID_EXT2_TSC     (1 << 4)
+#define CPUID_EXT2_MSR     (1 << 5)
+#define CPUID_EXT2_PAE     (1 << 6)
+#define CPUID_EXT2_MCE     (1 << 7)
+#define CPUID_EXT2_CX8     (1 << 8)
+#define CPUID_EXT2_APIC    (1 << 9)
 #define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MTRR    (1 << 12)
+#define CPUID_EXT2_PGE     (1 << 13)
+#define CPUID_EXT2_MCA     (1 << 14)
+#define CPUID_EXT2_CMOV    (1 << 15)
+#define CPUID_EXT2_PAT     (1 << 16)
+#define CPUID_EXT2_PSE36   (1 << 17)
 #define CPUID_EXT2_MP      (1 << 19)
 #define CPUID_EXT2_NX      (1 << 20)
 #define CPUID_EXT2_MMXEXT  (1 << 22)
+#define CPUID_EXT2_MMX     (1 << 23)
+#define CPUID_EXT2_FXSR    (1 << 24)
 #define CPUID_EXT2_FFXSR   (1 << 25)
 #define CPUID_EXT2_PDPE1GB (1 << 26)
 #define CPUID_EXT2_RDTSCP  (1 << 27)
@@ -427,7 +447,9 @@
 #define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
 #define CPUID_EXT3_OSVW    (1 << 9)
 #define CPUID_EXT3_IBS     (1 << 10)
+#define CPUID_EXT3_XOP     (1 << 11)
 #define CPUID_EXT3_SKINIT  (1 << 12)
+#define CPUID_EXT3_FMA4    (1 << 16)
 
 #define CPUID_SVM_NPT          (1 << 0)
 #define CPUID_SVM_LBRV         (1 << 1)
-- 
1.7.11.2

[Qemu-devel] [PATCH 2/3] move CPU models from cpus-x86_64.conf to C

[Eduardo Habkost]

Those models are maintained by QEMU and may require compatibility code
to be added when making some changes. Keeping the data in the C source
code should make it simpler to handle those details.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 sysconfigs/target/cpus-x86_64.conf | 129 +---------------------
 target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
 2 files changed, 220 insertions(+), 128 deletions(-)

diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
index cee0ea9..3902189 100644
--- a/sysconfigs/target/cpus-x86_64.conf
+++ b/sysconfigs/target/cpus-x86_64.conf
@@ -1,128 +1 @@
-# x86 CPU MODELS
-
-[cpudef]
-   name = "Conroe"
-   level = "2"
-   vendor = "GenuineIntel"
-   family = "6"
-   model = "2"
-   stepping = "3"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "ssse3 sse3"
-   extfeature_edx = "i64 xd syscall"
-   extfeature_ecx = "lahf_lm"
-   xlevel = "0x8000000A"
-   model_id = "Intel Celeron_4x0 (Conroe/Merom Class Core 2)"
-
-[cpudef]
-   name = "Penryn"
-   level = "2"
-   vendor = "GenuineIntel"
-   family = "6"
-   model = "2"
-   stepping = "3"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "sse4.1 cx16 ssse3 sse3"
-   extfeature_edx = "i64 xd syscall"
-   extfeature_ecx = "lahf_lm"
-   xlevel = "0x8000000A"
-   model_id = "Intel Core 2 Duo P9xxx (Penryn Class Core 2)"
-
-[cpudef]
-   name = "Nehalem"
-   level = "2"
-   vendor = "GenuineIntel"
-   family = "6"
-   model = "2"
-   stepping = "3"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "popcnt sse4.2 sse4.1 cx16 ssse3 sse3"
-   extfeature_edx = "i64 syscall xd"
-   extfeature_ecx = "lahf_lm"
-   xlevel = "0x8000000A"
-   model_id = "Intel Core i7 9xx (Nehalem Class Core i7)"
-
-[cpudef]
-   name = "Westmere"
-   level = "11"
-   vendor = "GenuineIntel"
-   family = "6"
-   model = "44"
-   stepping = "1"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3"
-   extfeature_edx = "i64 syscall xd"
-   extfeature_ecx = "lahf_lm"
-   xlevel = "0x8000000A"
-   model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)"
-
-[cpudef]
-   name = "SandyBridge"
-   level = "0xd"
-   vendor = "GenuineIntel"
-   family = "6"
-   model = "42"
-   stepping = "1"
-   feature_edx = " sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "avx xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 cx16 ssse3 pclmulqdq sse3"
-   extfeature_edx = "i64 rdtscp nx syscall "
-   extfeature_ecx = "lahf_lm"
-   xlevel = "0x8000000A"
-   model_id = "Intel Xeon E312xx (Sandy Bridge)"
-
-[cpudef]
-   name = "Opteron_G1"
-   level = "5"
-   vendor = "AuthenticAMD"
-   family = "15"
-   model = "6"
-   stepping = "1"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "sse3"
-   extfeature_edx = "lm fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu"
-   extfeature_ecx = " "
-   xlevel = "0x80000008"
-   model_id = "AMD Opteron 240 (Gen 1 Class Opteron)"
-
-[cpudef]
-   name = "Opteron_G2"
-   level = "5"
-   vendor = "AuthenticAMD"
-   family = "15"
-   model = "6"
-   stepping = "1"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "cx16 sse3"
-   extfeature_edx = "lm rdtscp fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu"
-   extfeature_ecx = "svm lahf_lm"
-   xlevel = "0x80000008"
-   model_id = "AMD Opteron 22xx (Gen 2 Class Opteron)"
-
-[cpudef]
-   name = "Opteron_G3"
-   level = "5"
-   vendor = "AuthenticAMD"
-   family = "15"
-   model = "6"
-   stepping = "1"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "popcnt cx16 monitor sse3"
-   extfeature_edx = "lm rdtscp fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu"
-   extfeature_ecx = "misalignsse sse4a abm svm lahf_lm"
-   xlevel = "0x80000008"
-   model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)"
-
-[cpudef]
-   name = "Opteron_G4"
-   level = "0xd"
-   vendor = "AuthenticAMD"
-   family = "21"
-   model = "1"
-   stepping = "2"
-   feature_edx = "sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu"
-   feature_ecx = "avx xsave aes popcnt sse4.2 sse4.1 cx16 ssse3 pclmulqdq sse3"
-   extfeature_edx = "lm rdtscp pdpe1gb fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu"
-   extfeature_ecx = " fma4 xop 3dnowprefetch misalignsse sse4a abm svm lahf_lm"
-   xlevel = "0x8000001A"
-   model_id = "AMD Opteron 62xx class CPU"
-
+# The CPU models from this file are now built-in in the QEMU source code
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6b9659f..44c5ed2 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -484,6 +484,225 @@ static x86_def_t builtin_x86_defs[] = {
         .xlevel = 0x8000000A,
         .model_id = "Intel(R) Atom(TM) CPU N270   @ 1.60GHz",
     },
+    {
+        .name = "Conroe",
+        .level = 2,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,
+        .model = 2,
+        .stepping = 3,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+        .ext3_features = CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000000A,
+        .model_id = "Intel Celeron_4x0 (Conroe/Merom Class Core 2)",
+    },
+    {
+        .name = "Penryn",
+        .level = 2,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,
+        .model = 2,
+        .stepping = 3,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+             CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+        .ext3_features = CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000000A,
+        .model_id = "Intel Core 2 Duo P9xxx (Penryn Class Core 2)",
+    },
+    {
+        .name = "Nehalem",
+        .level = 2,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,
+        .model = 2,
+        .stepping = 3,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+             CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+        .ext3_features = CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000000A,
+        .model_id = "Intel Core i7 9xx (Nehalem Class Core i7)",
+    },
+    {
+        .name = "Westmere",
+        .level = 11,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,
+        .model = 44,
+        .stepping = 1,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
+             CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+             CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+        .ext3_features = CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000000A,
+        .model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)",
+    },
+    {
+        .name = "SandyBridge",
+        .level = 0xd,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,
+        .model = 42,
+        .stepping = 1,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+             CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
+             CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+             CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
+             CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+             CPUID_EXT2_SYSCALL,
+        .ext3_features = CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000000A,
+        .model_id = "Intel Xeon E312xx (Sandy Bridge)",
+    },
+    {
+        .name = "Opteron_G1",
+        .level = 5,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 15,
+        .model = 6,
+        .stepping = 1,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_FXSR | CPUID_EXT2_MMX |
+             CPUID_EXT2_NX | CPUID_EXT2_PSE36 | CPUID_EXT2_PAT |
+             CPUID_EXT2_CMOV | CPUID_EXT2_MCA | CPUID_EXT2_PGE |
+             CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
+             CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE | CPUID_EXT2_MSR |
+             CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE | CPUID_EXT2_FPU,
+        .xlevel = 0x80000008,
+        .model_id = "AMD Opteron 240 (Gen 1 Class Opteron)",
+    },
+    {
+        .name = "Opteron_G2",
+        .level = 5,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 15,
+        .model = 6,
+        .stepping = 1,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_CX16 | CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_FXSR |
+             CPUID_EXT2_MMX | CPUID_EXT2_NX | CPUID_EXT2_PSE36 |
+             CPUID_EXT2_PAT | CPUID_EXT2_CMOV | CPUID_EXT2_MCA |
+             CPUID_EXT2_PGE | CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL |
+             CPUID_EXT2_APIC | CPUID_EXT2_CX8 | CPUID_EXT2_MCE |
+             CPUID_EXT2_PAE | CPUID_EXT2_MSR | CPUID_EXT2_TSC | CPUID_EXT2_PSE |
+             CPUID_EXT2_DE | CPUID_EXT2_FPU,
+        .ext3_features = CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x80000008,
+        .model_id = "AMD Opteron 22xx (Gen 2 Class Opteron)",
+    },
+    {
+        .name = "Opteron_G3",
+        .level = 5,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 15,
+        .model = 6,
+        .stepping = 1,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
+             CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_FXSR |
+             CPUID_EXT2_MMX | CPUID_EXT2_NX | CPUID_EXT2_PSE36 |
+             CPUID_EXT2_PAT | CPUID_EXT2_CMOV | CPUID_EXT2_MCA |
+             CPUID_EXT2_PGE | CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL |
+             CPUID_EXT2_APIC | CPUID_EXT2_CX8 | CPUID_EXT2_MCE |
+             CPUID_EXT2_PAE | CPUID_EXT2_MSR | CPUID_EXT2_TSC | CPUID_EXT2_PSE |
+             CPUID_EXT2_DE | CPUID_EXT2_FPU,
+        .ext3_features = CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
+             CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x80000008,
+        .model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)",
+    },
+    {
+        .name = "Opteron_G4",
+        .level = 0xd,
+        .vendor1 = CPUID_VENDOR_AMD_1,
+        .vendor2 = CPUID_VENDOR_AMD_2,
+        .vendor3 = CPUID_VENDOR_AMD_3,
+        .family = 21,
+        .model = 1,
+        .stepping = 2,
+        .features = CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+             CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+             CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+             CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+             CPUID_DE | CPUID_FP87,
+        .ext_features = CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+             CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+             CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
+             CPUID_EXT_SSE3,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP |
+             CPUID_EXT2_PDPE1GB | CPUID_EXT2_FXSR | CPUID_EXT2_MMX |
+             CPUID_EXT2_NX | CPUID_EXT2_PSE36 | CPUID_EXT2_PAT |
+             CPUID_EXT2_CMOV | CPUID_EXT2_MCA | CPUID_EXT2_PGE |
+             CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
+             CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE | CPUID_EXT2_MSR |
+             CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE | CPUID_EXT2_FPU,
+        .ext3_features = CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
+             CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
+             CPUID_EXT3_SSE4A | CPUID_EXT3_ABM | CPUID_EXT3_SVM |
+             CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x8000001A,
+        .model_id = "AMD Opteron 62xx class CPU",
+    },
 };
 
 static int cpu_x86_fill_model_id(char *str)
-- 
1.7.11.2

[Qemu-devel] [PATCH 3/3] eliminate cpus-x86_64.conf file

[Eduardo Habkost]

This file is not needed anymore, as QEMU won't ship any config-based
cpudefs out of the box, relying only on the builtin CPU models.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 Makefile                           | 1 -
 arch_init.c                        | 1 -
 sysconfigs/target/cpus-x86_64.conf | 1 -
 3 files changed, 3 deletions(-)
 delete mode 100644 sysconfigs/target/cpus-x86_64.conf

diff --git a/Makefile b/Makefile
index 621cb86..3722320 100644
--- a/Makefile
+++ b/Makefile
@@ -298,7 +298,6 @@ install-confdir:
 
 install-sysconfig: install-datadir install-confdir
 	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf "$(DESTDIR)$(qemu_confdir)"
-	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf "$(DESTDIR)$(qemu_datadir)"
 
 install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
 	$(INSTALL_DIR) "$(DESTDIR)$(bindir)"
diff --git a/arch_init.c b/arch_init.c
index 26f30ef..a8399e5 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -131,7 +131,6 @@ static struct defconfig_file {
     /* Indicates it is an user config file (disabled by -no-user-config) */
     bool userconfig;
 } default_config_files[] = {
-    { CONFIG_QEMU_DATADIR "/cpus-" TARGET_ARCH ".conf",  false },
     { CONFIG_QEMU_CONFDIR "/qemu.conf",                   true },
     { CONFIG_QEMU_CONFDIR "/target-" TARGET_ARCH ".conf", true },
     { NULL }, /* end of list */
diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
deleted file mode 100644
index 3902189..0000000
--- a/sysconfigs/target/cpus-x86_64.conf
+++ /dev/null
@@ -1 +0,0 @@
-# The CPU models from this file are now built-in in the QEMU source code
-- 
1.7.11.2

Re: [Qemu-devel] [PATCH 3/3] eliminate cpus-x86_64.conf file

[Lluís Vilanova]

Eduardo Habkost writes:

> This file is not needed anymore, as QEMU won't ship any config-based
> cpudefs out of the box, relying only on the builtin CPU models.

> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  Makefile                           | 1 -
>  arch_init.c                        | 1 -
>  sysconfigs/target/cpus-x86_64.conf | 1 -
>  3 files changed, 3 deletions(-)
>  delete mode 100644 sysconfigs/target/cpus-x86_64.conf

> diff --git a/Makefile b/Makefile
> index 621cb86..3722320 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -298,7 +298,6 @@ install-confdir:
 
>  install-sysconfig: install-datadir install-confdir
>  	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf "$(DESTDIR)$(qemu_confdir)"
> -	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf "$(DESTDIR)$(qemu_datadir)"
 
>  install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
>  	$(INSTALL_DIR) "$(DESTDIR)$(bindir)"
> diff --git a/arch_init.c b/arch_init.c
> index 26f30ef..a8399e5 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -131,7 +131,6 @@ static struct defconfig_file {
>      /* Indicates it is an user config file (disabled by -no-user-config) */
>      bool userconfig;
>  } default_config_files[] = {
> -    { CONFIG_QEMU_DATADIR "/cpus-" TARGET_ARCH ".conf",  false },
>      { CONFIG_QEMU_CONFDIR "/qemu.conf",                   true },
>      { CONFIG_QEMU_CONFDIR "/target-" TARGET_ARCH ".conf", true },
>      { NULL }, /* end of list */
> diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
> deleted file mode 100644
> index 3902189..0000000
> --- a/sysconfigs/target/cpus-x86_64.conf
> +++ /dev/null
> @@ -1 +0,0 @@
> -# The CPU models from this file are now built-in in the QEMU source code
> -- 
> 1.7.11.2

Without actually having looked at it, shouldn't the code handling its parsing be
also removed?


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] [PATCH 3/3] eliminate cpus-x86_64.conf file

[Eduardo Habkost]

On Wed, Aug 01, 2012 at 10:37:04PM +0300, Lluís Vilanova wrote:
> Eduardo Habkost writes:
> 
> > This file is not needed anymore, as QEMU won't ship any config-based
> > cpudefs out of the box, relying only on the builtin CPU models.
> 
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  Makefile                           | 1 -
> >  arch_init.c                        | 1 -
> >  sysconfigs/target/cpus-x86_64.conf | 1 -
> >  3 files changed, 3 deletions(-)
> >  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
> 
> > diff --git a/Makefile b/Makefile
> > index 621cb86..3722320 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -298,7 +298,6 @@ install-confdir:
>  
> >  install-sysconfig: install-datadir install-confdir
> >  	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf "$(DESTDIR)$(qemu_confdir)"
> > -	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf "$(DESTDIR)$(qemu_datadir)"
>  
> >  install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
> >  	$(INSTALL_DIR) "$(DESTDIR)$(bindir)"
> > diff --git a/arch_init.c b/arch_init.c
> > index 26f30ef..a8399e5 100644
> > --- a/arch_init.c
> > +++ b/arch_init.c
> > @@ -131,7 +131,6 @@ static struct defconfig_file {
> >      /* Indicates it is an user config file (disabled by -no-user-config) */
> >      bool userconfig;
> >  } default_config_files[] = {
> > -    { CONFIG_QEMU_DATADIR "/cpus-" TARGET_ARCH ".conf",  false },
> >      { CONFIG_QEMU_CONFDIR "/qemu.conf",                   true },
> >      { CONFIG_QEMU_CONFDIR "/target-" TARGET_ARCH ".conf", true },
> >      { NULL }, /* end of list */
> > diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
> > deleted file mode 100644
> > index 3902189..0000000
> > --- a/sysconfigs/target/cpus-x86_64.conf
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -# The CPU models from this file are now built-in in the QEMU source code
> > -- 
> > 1.7.11.2
> 
> Without actually having looked at it, shouldn't the code handling its parsing be
> also removed?

What's being removed is just the file for QEMU-provided cpudefs. The
user may still add their own cpudef sections to the config files on
/etc, or using -readconfig.

(We can consider removing completely the support for [cpudef] config
sections. If we do that, we will break compatibility with existing user
configurations that use the feature).

-- 
Eduardo

Re: [Qemu-devel] [PATCH 3/3] eliminate cpus-x86_64.conf file

[Lluís Vilanova]

Eduardo Habkost writes:

> On Wed, Aug 01, 2012 at 10:37:04PM +0300, Lluís Vilanova wrote:
>> Eduardo Habkost writes:
>> 
>> > This file is not needed anymore, as QEMU won't ship any config-based
>> > cpudefs out of the box, relying only on the builtin CPU models.
>> 
>> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>> > ---
>> >  Makefile                           | 1 -
>> >  arch_init.c                        | 1 -
>> >  sysconfigs/target/cpus-x86_64.conf | 1 -
>> >  3 files changed, 3 deletions(-)
>> >  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
>> 
>> > diff --git a/Makefile b/Makefile
>> > index 621cb86..3722320 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -298,7 +298,6 @@ install-confdir:
>> 
>> >  install-sysconfig: install-datadir install-confdir
>> >  	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf "$(DESTDIR)$(qemu_confdir)"
>> > -	$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf "$(DESTDIR)$(qemu_datadir)"
>> 
>> >  install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
>> >  	$(INSTALL_DIR) "$(DESTDIR)$(bindir)"
>> > diff --git a/arch_init.c b/arch_init.c
>> > index 26f30ef..a8399e5 100644
>> > --- a/arch_init.c
>> > +++ b/arch_init.c
>> > @@ -131,7 +131,6 @@ static struct defconfig_file {
>> >      /* Indicates it is an user config file (disabled by -no-user-config) */
>> >      bool userconfig;
>> >  } default_config_files[] = {
>> > -    { CONFIG_QEMU_DATADIR "/cpus-" TARGET_ARCH ".conf",  false },
>> >      { CONFIG_QEMU_CONFDIR "/qemu.conf",                   true },
>> >      { CONFIG_QEMU_CONFDIR "/target-" TARGET_ARCH ".conf", true },
>> >      { NULL }, /* end of list */
>> > diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
>> > deleted file mode 100644
>> > index 3902189..0000000
>> > --- a/sysconfigs/target/cpus-x86_64.conf
>> > +++ /dev/null
>> > @@ -1 +0,0 @@
>> > -# The CPU models from this file are now built-in in the QEMU source code
>> > -- 
>> > 1.7.11.2
>> 
>> Without actually having looked at it, shouldn't the code handling its parsing be
>> also removed?

> What's being removed is just the file for QEMU-provided cpudefs. The
> user may still add their own cpudef sections to the config files on
> /etc, or using -readconfig.

> (We can consider removing completely the support for [cpudef] config
> sections. If we do that, we will break compatibility with existing user
> configurations that use the feature).

True. Sorry for the confusion.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Anthony Liguori]

Eduardo Habkost <ehabkost@redhat.com> writes:

> This makes the change we discussed on the latest KVM conf call[1], moving the
> existing cpudefs from cpus-x86_64.conf to the C code.
>
> The config file data was converted to C using a script, available at:
> https://gist.github.com/3229602
>
> Except by the extra square brackets around the CPU model names (indicating they
> are built-in models), the output of "-cpu ?dump" is exactly the same before and
> after applying this series.
>
> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328

Whole series:

Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>

I'll wait a little bit for others to look and then apply.

Regards,

Anthony Liguori

>
> Eduardo Habkost (3):
>   i386: add missing CPUID_* constants
>   move CPU models from cpus-x86_64.conf to C
>   eliminate cpus-x86_64.conf file
>
>  Makefile                           |   1 -
>  arch_init.c                        |   1 -
>  sysconfigs/target/cpus-x86_64.conf | 128 ----------------------
>  target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
>  target-i386/cpu.h                  |  22 ++++
>  5 files changed, 241 insertions(+), 130 deletions(-)
>  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
>
> -- 
> 1.7.11.2

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Eduardo Habkost]

On Wed, Aug 01, 2012 at 01:53:51PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > This makes the change we discussed on the latest KVM conf call[1], moving the
> > existing cpudefs from cpus-x86_64.conf to the C code.
> >
> > The config file data was converted to C using a script, available at:
> > https://gist.github.com/3229602
> >
> > Except by the extra square brackets around the CPU model names (indicating they
> > are built-in models), the output of "-cpu ?dump" is exactly the same before and
> > after applying this series.
> >
> > [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> 
> Whole series:
> 
> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> I'll wait a little bit for others to look and then apply.

Just checking: you still plan to include this on 1.2, right?

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Eduardo Habkost (3):
> >   i386: add missing CPUID_* constants
> >   move CPU models from cpus-x86_64.conf to C
> >   eliminate cpus-x86_64.conf file
> >
> >  Makefile                           |   1 -
> >  arch_init.c                        |   1 -
> >  sysconfigs/target/cpus-x86_64.conf | 128 ----------------------
> >  target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
> >  target-i386/cpu.h                  |  22 ++++
> >  5 files changed, 241 insertions(+), 130 deletions(-)
> >  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
> >
> > -- 
> > 1.7.11.2
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Andreas Färber]

Am 01.08.2012 20:45, schrieb Eduardo Habkost:
> This makes the change we discussed on the latest KVM conf call[1], moving the
> existing cpudefs from cpus-x86_64.conf to the C code.
> 
> The config file data was converted to C using a script, available at:
> https://gist.github.com/3229602
> 
> Except by the extra square brackets around the CPU model names (indicating they
> are built-in models), the output of "-cpu ?dump" is exactly the same before and
> after applying this series.
> 
> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> 
> Eduardo Habkost (3):
>   i386: add missing CPUID_* constants
>   move CPU models from cpus-x86_64.conf to C
>   eliminate cpus-x86_64.conf file

If we do this, we will need to refactor the C code again for CPU
subclasses. Can't we (you) do that in one go then? :-)

I thought there was a broad consensus not to go my declarative
X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
That would mean transforming your

+    {
+        .family = 6,
+        .model = 2,
...

into an initfn doing

-    {
+static void conroe_initfn(Object *obj)
+{
+    X86CPU *cpu = X86_CPU(obj);
+    CPUX86State *env = &cpu->env;
+
-        .family = 6,
+    env->family = 6;
-        .model = 2,
+    env->model = 2;
...

or so (not all being as nicely aligned).

Unfortunately the move of the CPU definitions from config file to C does
not eliminate the issue that users can still specify CPU models in their
own config files or from the command line, right? Doesn't that mean that
either we need to keep all CPU definitions declarative as done here and
live with any field duplication between X86CPUInfo and X86CPUClass, or
have a special intermediate subclass UserX86CPUClass with such fields
for user-specified -cpudef models?
Assuming, dropping -cpudef for 1.2 is still not an option.

Regards,
Andreas

> 
>  Makefile                           |   1 -
>  arch_init.c                        |   1 -
>  sysconfigs/target/cpus-x86_64.conf | 128 ----------------------
>  target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
>  target-i386/cpu.h                  |  22 ++++
>  5 files changed, 241 insertions(+), 130 deletions(-)
>  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Eduardo Habkost]

On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
> > This makes the change we discussed on the latest KVM conf call[1], moving the
> > existing cpudefs from cpus-x86_64.conf to the C code.
> > 
> > The config file data was converted to C using a script, available at:
> > https://gist.github.com/3229602
> > 
> > Except by the extra square brackets around the CPU model names (indicating they
> > are built-in models), the output of "-cpu ?dump" is exactly the same before and
> > after applying this series.
> > 
> > [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> > 
> > Eduardo Habkost (3):
> >   i386: add missing CPUID_* constants
> >   move CPU models from cpus-x86_64.conf to C
> >   eliminate cpus-x86_64.conf file
> 
> If we do this, we will need to refactor the C code again for CPU
> subclasses. Can't we (you) do that in one go then? :-)

Why again? The refactor for classes would be a one-time mechanical
process, won't it?

Anyway, I wouldn't do it in a single step. I prefer doing things one
small step at a time.


> 
> I thought there was a broad consensus not to go my declarative
> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
> That would mean transforming your
> 
> +    {
> +        .family = 6,
> +        .model = 2,
> ...
> 
> into an initfn doing
> 
> -    {
> +static void conroe_initfn(Object *obj)
> +{
> +    X86CPU *cpu = X86_CPU(obj);
> +    CPUX86State *env = &cpu->env;
> +
> -        .family = 6,
> +    env->family = 6;
> -        .model = 2,
> +    env->model = 2;
> ...
> 
> or so (not all being as nicely aligned).

Really? I am surprised that this is the consensus. Why would one want to
transform machine-friendly data into a large set of opaque functions
that look all the same and contains exactly the same data inside it, but
in a too verbose, machine-unfriendly and refactor-unfriendly way? It
doesn't make sense to me.

I will look for previous discussions to try to understand the reason for
that (was this discussed on qemu-devel?). Do you have any pointers
handy?


> 
> Unfortunately the move of the CPU definitions from config file to C does
> not eliminate the issue that users can still specify CPU models in their
> own config files or from the command line, right? Doesn't that mean that
> either we need to keep all CPU definitions declarative as done here and
> live with any field duplication between X86CPUInfo and X86CPUClass, or
> have a special intermediate subclass UserX86CPUClass with such fields
> for user-specified -cpudef models?
> Assuming, dropping -cpudef for 1.2 is still not an option.

I would be happy to drop support for cpudef config sections completely.
The only problem is compatibility, but personally I wouldn't mind
breaking it (I don't think many users have been writing their own
cpudefs).

Anyway, if we keep supporting it for compatibility (it could be simply
one separated CPU subclass that uses the config file data), at least we
don't have the need for versioning/compatibility mechanisms for
user-provided cpudefs.

> 
> Regards,
> Andreas
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Anthony Liguori]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
>> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
>> > This makes the change we discussed on the latest KVM conf call[1], moving the
>> > existing cpudefs from cpus-x86_64.conf to the C code.
>> > 
>> > The config file data was converted to C using a script, available at:
>> > https://gist.github.com/3229602
>> > 
>> > Except by the extra square brackets around the CPU model names (indicating they
>> > are built-in models), the output of "-cpu ?dump" is exactly the same before and
>> > after applying this series.
>> > 
>> > [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
>> > 
>> > Eduardo Habkost (3):
>> >   i386: add missing CPUID_* constants
>> >   move CPU models from cpus-x86_64.conf to C
>> >   eliminate cpus-x86_64.conf file
>> 
>> If we do this, we will need to refactor the C code again for CPU
>> subclasses. Can't we (you) do that in one go then? :-)
>
> Why again? The refactor for classes would be a one-time mechanical
> process, won't it?
>
> Anyway, I wouldn't do it in a single step. I prefer doing things one
> small step at a time.

I tend to agree.

>> I thought there was a broad consensus not to go my declarative
>> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
>> That would mean transforming your
>> 
>> +    {
>> +        .family = 6,
>> +        .model = 2,
>> ...
>> 
>> into an initfn doing
>> 
>> -    {
>> +static void conroe_initfn(Object *obj)
>> +{
>> +    X86CPU *cpu = X86_CPU(obj);
>> +    CPUX86State *env = &cpu->env;
>> +
>> -        .family = 6,
>> +    env->family = 6;
>> -        .model = 2,
>> +    env->model = 2;
>> ...
>> 
>> or so (not all being as nicely aligned).
>
> Really? I am surprised that this is the consensus.

Andreas is absolutely correct here.  Obviously, it's always better to
represent things as data instead of code.  The basic problem is that
this can't be easily represented as data (particularly when you start
getting into compat properties).

> Why would one want to
> transform machine-friendly data into a large set of opaque functions
> that look all the same and contains exactly the same data inside it, but
> in a too verbose, machine-unfriendly and refactor-unfriendly way? It
> doesn't make sense to me.
>
> I will look for previous discussions to try to understand the reason for
> that (was this discussed on qemu-devel?). Do you have any pointers
> handy?
>
>
>> 
>> Unfortunately the move of the CPU definitions from config file to C does
>> not eliminate the issue that users can still specify CPU models in their
>> own config files or from the command line, right? Doesn't that mean that
>> either we need to keep all CPU definitions declarative as done here and
>> live with any field duplication between X86CPUInfo and X86CPUClass, or
>> have a special intermediate subclass UserX86CPUClass with such fields
>> for user-specified -cpudef models?
>> Assuming, dropping -cpudef for 1.2 is still not an option.
>
> I would be happy to drop support for cpudef config sections
> completely.

Please add docs to your patch about -cpudef being deprecated.  We'll remove
it for 1.3 provided no one screams.

I'll include something in the 1.2 release notes and ask anyone to
contact qemu-devel if they depend on this feature.

We haven't really done this in the past, but I don't see a reasonable
way to keep supporting -cpudef moving forward.

Regards,

Anthony Liguori

> The only problem is compatibility, but personally I wouldn't mind
> breaking it (I don't think many users have been writing their own
> cpudefs).
>
> Anyway, if we keep supporting it for compatibility (it could be simply
> one separated CPU subclass that uses the config file data), at least we
> don't have the need for versioning/compatibility mechanisms for
> user-provided cpudefs.
>
>> 
>> Regards,
>> Andreas
>> 
>
> -- 
> Eduardo

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Eduardo Habkost]

On Wed, Aug 01, 2012 at 03:41:56PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
> >> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
> >> > This makes the change we discussed on the latest KVM conf call[1], moving the
> >> > existing cpudefs from cpus-x86_64.conf to the C code.
> >> > 
> >> > The config file data was converted to C using a script, available at:
> >> > https://gist.github.com/3229602
> >> > 
> >> > Except by the extra square brackets around the CPU model names (indicating they
> >> > are built-in models), the output of "-cpu ?dump" is exactly the same before and
> >> > after applying this series.
> >> > 
> >> > [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> >> > 
> >> > Eduardo Habkost (3):
> >> >   i386: add missing CPUID_* constants
> >> >   move CPU models from cpus-x86_64.conf to C
> >> >   eliminate cpus-x86_64.conf file
> >> 
> >> If we do this, we will need to refactor the C code again for CPU
> >> subclasses. Can't we (you) do that in one go then? :-)
> >
> > Why again? The refactor for classes would be a one-time mechanical
> > process, won't it?
> >
> > Anyway, I wouldn't do it in a single step. I prefer doing things one
> > small step at a time.
> 
> I tend to agree.
> 
> >> I thought there was a broad consensus not to go my declarative
> >> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
> >> That would mean transforming your
> >> 
> >> +    {
> >> +        .family = 6,
> >> +        .model = 2,
> >> ...
> >> 
> >> into an initfn doing
> >> 
> >> -    {
> >> +static void conroe_initfn(Object *obj)
> >> +{
> >> +    X86CPU *cpu = X86_CPU(obj);
> >> +    CPUX86State *env = &cpu->env;
> >> +
> >> -        .family = 6,
> >> +    env->family = 6;
> >> -        .model = 2,
> >> +    env->model = 2;
> >> ...
> >> 
> >> or so (not all being as nicely aligned).
> >
> > Really? I am surprised that this is the consensus.
> 
> Andreas is absolutely correct here.  Obviously, it's always better to
> represent things as data instead of code.  The basic problem is that
> this can't be easily represented as data (particularly when you start
> getting into compat properties).

I agree that sometimes we can't represent everything easily as data and
some code is required. I just don't see yet why that would be the case
for the CPU model data. The fact that we're insisting in using global
properties to implement the compat code is a demonstration that it can
be completely data-driven, isn't it?

We also need to expose some of the CPU model information to libvirt, so
we will surely need to keep some of that information available as data.

> 
> > Why would one want to
> > transform machine-friendly data into a large set of opaque functions
> > that look all the same and contains exactly the same data inside it, but
> > in a too verbose, machine-unfriendly and refactor-unfriendly way? It
> > doesn't make sense to me.
> >
> > I will look for previous discussions to try to understand the reason for
> > that (was this discussed on qemu-devel?). Do you have any pointers
> > handy?
> >
> >
> >> 
> >> Unfortunately the move of the CPU definitions from config file to C does
> >> not eliminate the issue that users can still specify CPU models in their
> >> own config files or from the command line, right? Doesn't that mean that
> >> either we need to keep all CPU definitions declarative as done here and
> >> live with any field duplication between X86CPUInfo and X86CPUClass, or
> >> have a special intermediate subclass UserX86CPUClass with such fields
> >> for user-specified -cpudef models?
> >> Assuming, dropping -cpudef for 1.2 is still not an option.
> >
> > I would be happy to drop support for cpudef config sections
> > completely.
> 
> Please add docs to your patch about -cpudef being deprecated.  We'll remove
> it for 1.3 provided no one screams.

I'll do.

> 
> I'll include something in the 1.2 release notes and ask anyone to
> contact qemu-devel if they depend on this feature.
> 
> We haven't really done this in the past, but I don't see a reasonable
> way to keep supporting -cpudef moving forward.
> 
> Regards,
> 
> Anthony Liguori
> 
> > The only problem is compatibility, but personally I wouldn't mind
> > breaking it (I don't think many users have been writing their own
> > cpudefs).
> >
> > Anyway, if we keep supporting it for compatibility (it could be simply
> > one separated CPU subclass that uses the config file data), at least we
> > don't have the need for versioning/compatibility mechanisms for
> > user-provided cpudefs.
> >
> >> 
> >> Regards,
> >> Andreas
> >> 
> >
> > -- 
> > Eduardo

-- 
Eduardo

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Andreas Färber]

Am 01.08.2012 22:27, schrieb Eduardo Habkost:
> On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
>> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
>>> This makes the change we discussed on the latest KVM conf call[1], moving the
>>> existing cpudefs from cpus-x86_64.conf to the C code.
>>>
>>> The config file data was converted to C using a script, available at:
>>> https://gist.github.com/3229602
>>>
>>> Except by the extra square brackets around the CPU model names (indicating they
>>> are built-in models), the output of "-cpu ?dump" is exactly the same before and
>>> after applying this series.
>>>
>>> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
>>>
>>> Eduardo Habkost (3):
>>>   i386: add missing CPUID_* constants
>>>   move CPU models from cpus-x86_64.conf to C
>>>   eliminate cpus-x86_64.conf file
>>
>> If we do this, we will need to refactor the C code again for CPU
>> subclasses. Can't we (you) do that in one go then? :-)
> 
> Why again? The refactor for classes would be a one-time mechanical
> process, won't it?

Because of the resulting second movement sketched below. Like I told you
some time ago I am seriously scared of loosing some tiny feature bit or
mixing up some TLAs and breaking things if I had to do that
touch-all-CPU-definitions refactoring myself. So I'd rather either avoid
it or have someone who knows that code and/or CPU better do it. So if
you touch it here that would've been a perfect fit. ;)

> Anyway, I wouldn't do it in a single step. I prefer doing things one
> small step at a time.

Just raising awareness. If that's what people want to do and there's
volunteers for refactoring and reviewing then fine with me. :-)

>> I thought there was a broad consensus not to go my declarative
>> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
>> That would mean transforming your
>>
>> +    {
>> +        .family = 6,
>> +        .model = 2,
>> ...
>>
>> into an initfn doing
>>
>> -    {
>> +static void conroe_initfn(Object *obj)
>> +{
>> +    X86CPU *cpu = X86_CPU(obj);
>> +    CPUX86State *env = &cpu->env;
>> +
>> -        .family = 6,
>> +    env->family = 6;
>> -        .model = 2,
>> +    env->model = 2;
>> ...
>>
>> or so (not all being as nicely aligned).
> 
> Really? I am surprised that this is the consensus. Why would one want to
> transform machine-friendly data into a large set of opaque functions
> that look all the same and contains exactly the same data inside it, but
> in a too verbose, machine-unfriendly and refactor-unfriendly way? It
> doesn't make sense to me.
> 
> I will look for previous discussions to try to understand the reason for
> that (was this discussed on qemu-devel?). Do you have any pointers
> handy?

http://patchwork.ozlabs.org/patch/146704/ ;-)
and the surrounding couple of series back then (Blue for sparc and Paul
for arm come to mind, cc'ed).

The key isssue is that class_init gets the class_data pointer (e.g.,
x86_def_t aka X86CPUInfo) but the initfn doesn't. Thus all data initfn
needs must either be stored into X86CPUClass (then there's two copies of
the data) or hardcoded per type in an initfn. For the -cpudef we get
arbitrary data so we'd need the former solution.

(To add to the confusion, for -cpu ...,x=y we will need to set QOM
properties on the QOM instance in the future, that's what my setters are
for that you have helped to review. Disappointing how little progress
we've made since then...)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Igor Mammedov]

On 08/01/2012 11:53 PM, Andreas Färber wrote:
> Am 01.08.2012 22:27, schrieb Eduardo Habkost:
>> On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
>>> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
>>>> This makes the change we discussed on the latest KVM conf call[1], moving the
>>>> existing cpudefs from cpus-x86_64.conf to the C code.
>>>>
>>>> The config file data was converted to C using a script, available at:
>>>> https://gist.github.com/3229602
>>>>
>>>> Except by the extra square brackets around the CPU model names (indicating they
>>>> are built-in models), the output of "-cpu ?dump" is exactly the same before and
>>>> after applying this series.
>>>>
>>>> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
>>>>
>>>> Eduardo Habkost (3):
>>>>    i386: add missing CPUID_* constants
>>>>    move CPU models from cpus-x86_64.conf to C
>>>>    eliminate cpus-x86_64.conf file
>>>
>>> If we do this, we will need to refactor the C code again for CPU
>>> subclasses. Can't we (you) do that in one go then? :-)
>>
>> Why again? The refactor for classes would be a one-time mechanical
>> process, won't it?
>
> Because of the resulting second movement sketched below. Like I told you
> some time ago I am seriously scared of loosing some tiny feature bit or
> mixing up some TLAs and breaking things if I had to do that
> touch-all-CPU-definitions refactoring myself. So I'd rather either avoid
> it or have someone who knows that code and/or CPU better do it. So if
> you touch it here that would've been a perfect fit. ;)
I could do this conversion later after as follow up series for 1.3

>
>> Anyway, I wouldn't do it in a single step. I prefer doing things one
>> small step at a time.
>
> Just raising awareness. If that's what people want to do and there's
> volunteers for refactoring and reviewing then fine with me. :-)
>
>>> I thought there was a broad consensus not to go my declarative
>>> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
>>> That would mean transforming your
>>>
>>> +    {
>>> +        .family = 6,
>>> +        .model = 2,
>>> ...
>>>
>>> into an initfn doing
>>>
>>> -    {
>>> +static void conroe_initfn(Object *obj)
>>> +{
>>> +    X86CPU *cpu = X86_CPU(obj);
>>> +    CPUX86State *env = &cpu->env;
>>> +
>>> -        .family = 6,
>>> +    env->family = 6;
>>> -        .model = 2,
>>> +    env->model = 2;
>>> ...
>>>
>>> or so (not all being as nicely aligned).
>>
>> Really? I am surprised that this is the consensus. Why would one want to
>> transform machine-friendly data into a large set of opaque functions
>> that look all the same and contains exactly the same data inside it, but
>> in a too verbose, machine-unfriendly and refactor-unfriendly way? It
>> doesn't make sense to me.
>>
>> I will look for previous discussions to try to understand the reason for
>> that (was this discussed on qemu-devel?). Do you have any pointers
>> handy?
>
> http://patchwork.ozlabs.org/patch/146704/ ;-)
> and the surrounding couple of series back then (Blue for sparc and Paul
> for arm come to mind, cc'ed).
>
> The key isssue is that class_init gets the class_data pointer (e.g.,
> x86_def_t aka X86CPUInfo) but the initfn doesn't. Thus all data initfn
> needs must either be stored into X86CPUClass (then there's two copies of
> the data) or hardcoded per type in an initfn. For the -cpudef we get
> arbitrary data so we'd need the former solution.
>
> (To add to the confusion, for -cpu ...,x=y we will need to set QOM
> properties on the QOM instance in the future, that's what my setters are
> for that you have helped to review. Disappointing how little progress
> we've made since then...)
That is thing I am working on lately, a 3 days stale state you could see 
at https://github.com/imammedo/qemu/tree/x86-cpu-properties.WIP
I'm going to post completed series next week. I guess it's not candidate 
for 1.3 so no rush.

BTW: Are you going to host qom-next like last time while qemu is in 
freeze for 1.2?
>
> Andreas
>

Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C

[Eduardo Habkost]

On Wed, Aug 01, 2012 at 11:53:51PM +0200, Andreas Färber wrote:
> Am 01.08.2012 22:27, schrieb Eduardo Habkost:
> > On Wed, Aug 01, 2012 at 10:04:50PM +0200, Andreas Färber wrote:
> >> Am 01.08.2012 20:45, schrieb Eduardo Habkost:
> >>> This makes the change we discussed on the latest KVM conf call[1], moving the
> >>> existing cpudefs from cpus-x86_64.conf to the C code.
> >>>
> >>> The config file data was converted to C using a script, available at:
> >>> https://gist.github.com/3229602
> >>>
> >>> Except by the extra square brackets around the CPU model names (indicating they
> >>> are built-in models), the output of "-cpu ?dump" is exactly the same before and
> >>> after applying this series.
> >>>
> >>> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> >>>
> >>> Eduardo Habkost (3):
> >>>   i386: add missing CPUID_* constants
> >>>   move CPU models from cpus-x86_64.conf to C
> >>>   eliminate cpus-x86_64.conf file
> >>
> >> If we do this, we will need to refactor the C code again for CPU
> >> subclasses. Can't we (you) do that in one go then? :-)
> > 
> > Why again? The refactor for classes would be a one-time mechanical
> > process, won't it?
> 
> Because of the resulting second movement sketched below. Like I told you
> some time ago I am seriously scared of loosing some tiny feature bit or
> mixing up some TLAs and breaking things if I had to do that
> touch-all-CPU-definitions refactoring myself. So I'd rather either avoid
> it or have someone who knows that code and/or CPU better do it. So if
> you touch it here that would've been a perfect fit. ;)
> 
> > Anyway, I wouldn't do it in a single step. I prefer doing things one
> > small step at a time.
> 
> Just raising awareness. If that's what people want to do and there's
> volunteers for refactoring and reviewing then fine with me. :-)

I volunteer to help on that. Whatever approach we use, we can make it as
mechanically as possible (thus helping to avoid human errors in the
conversaion).

> 
> >> I thought there was a broad consensus not to go my declarative
> >> X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
> >> That would mean transforming your
> >>
> >> +    {
> >> +        .family = 6,
> >> +        .model = 2,
> >> ...
> >>
> >> into an initfn doing
> >>
> >> -    {
> >> +static void conroe_initfn(Object *obj)
> >> +{
> >> +    X86CPU *cpu = X86_CPU(obj);
> >> +    CPUX86State *env = &cpu->env;
> >> +
> >> -        .family = 6,
> >> +    env->family = 6;
> >> -        .model = 2,
> >> +    env->model = 2;
> >> ...
> >>
> >> or so (not all being as nicely aligned).
> > 
> > Really? I am surprised that this is the consensus. Why would one want to
> > transform machine-friendly data into a large set of opaque functions
> > that look all the same and contains exactly the same data inside it, but
> > in a too verbose, machine-unfriendly and refactor-unfriendly way? It
> > doesn't make sense to me.
> > 
> > I will look for previous discussions to try to understand the reason for
> > that (was this discussed on qemu-devel?). Do you have any pointers
> > handy?
> 
> http://patchwork.ozlabs.org/patch/146704/ ;-)
> and the surrounding couple of series back then (Blue for sparc and Paul
> for arm come to mind, cc'ed).
> 
> The key isssue is that class_init gets the class_data pointer (e.g.,
> x86_def_t aka X86CPUInfo) but the initfn doesn't. Thus all data initfn
> needs must either be stored into X86CPUClass (then there's two copies of
> the data) or hardcoded per type in an initfn. For the -cpudef we get
> arbitrary data so we'd need the former solution.

Well, we can simply just store everything in the X86CPUClass.

I don't see the existence of two copies of the data as a problem, as
long as the first copy is used only once (while creating the second
copy). But I think we can still avoid that and keep the implementation
data-driven.

Anyway, now we're talking about 1.3, right? Doing this will be much
easier once we eliminate the support for cpudef config sections, and we
won't eliminate it on 1.2 yet.

> 
> (To add to the confusion, for -cpu ...,x=y we will need to set QOM
> properties on the QOM instance in the future, that's what my setters are
> for that you have helped to review. Disappointing how little progress
> we've made since then...)

I have been avoiding touching that code by now to avoid conflicts, as we
already have 2 people working at exactly the same code.

-- 
Eduardo