[Qemu-devel] [PATCH for 1.3] target-i386: cpu: add missing flags to Haswell CPU model

[Qemu-devel] [PATCH for 1.3] target-i386: cpu: add missing flags to Haswell CPU model

[Eduardo Habkost]

When adding the Haswell CPU model, I intended to make it a superset of the
features present on the SandyBridge model, but I have removed the SEP and
RDTSCP features from the feature list by mistake. This patch adds the missing
SEP and RDTSCP features (that are present on SandyBridge) to Haswell.

Reported-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target-i386/cpu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 64c3491..4fdd4f7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -657,7 +657,7 @@ static x86_def_t builtin_x86_defs[] = {
         .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_APIC | CPUID_CX8 |
+             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 |
@@ -666,7 +666,8 @@ static x86_def_t builtin_x86_defs[] = {
              CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
              CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
              CPUID_EXT_PCID,
-        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+        .ext2_features = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+             CPUID_EXT2_SYSCALL,
         .ext3_features = CPUID_EXT3_LAHF_LM,
         .cpuid_7_0_ebx_features = CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
             CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_AVX2 | CPUID_7_0_EBX_SMEP |
-- 
1.7.11.7

Re: [Qemu-devel] [PATCH for 1.3] target-i386: cpu: add missing flags to Haswell CPU model

[Andreas Färber]

Am 22.11.2012 16:31, schrieb Eduardo Habkost:
> When adding the Haswell CPU model, I intended to make it a superset of the
> features present on the SandyBridge model, but I have removed the SEP and
> RDTSCP features from the feature list by mistake. This patch adds the missing
> SEP and RDTSCP features (that are present on SandyBridge) to Haswell.
> 
> Reported-by: Martin Kletzander <mkletzan@redhat.com>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

Acked-by: Andreas Färber <afaerber@suse.de>

FWIW this is showing where QOM's imperative approach combined with
inheritance could greatly simplify things beyond your subclasses RFC.
Unfortunately I am not intimately familiar with all these models, so
counting on your help there. :)

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 for 1.3] target-i386: cpu: add missing flags to Haswell CPU model

[Eduardo Habkost]

On Sun, Nov 25, 2012 at 07:33:12PM +0100, Andreas Färber wrote:
> Am 22.11.2012 16:31, schrieb Eduardo Habkost:
> > When adding the Haswell CPU model, I intended to make it a superset of the
> > features present on the SandyBridge model, but I have removed the SEP and
> > RDTSCP features from the feature list by mistake. This patch adds the missing
> > SEP and RDTSCP features (that are present on SandyBridge) to Haswell.
> > 
> > Reported-by: Martin Kletzander <mkletzan@redhat.com>
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> Acked-by: Andreas Färber <afaerber@suse.de>
> 
> FWIW this is showing where QOM's imperative approach combined with
> inheritance could greatly simplify things beyond your subclasses RFC.
> Unfortunately I am not intimately familiar with all these models, so
> counting on your help there. :)

I am now convinced that an imperative approach may be reasonable, if we
make the results of the imperative code introspectable (so we can expose
information about the CPU models to libvirt). This will probably be
possible if we use different class_init functions for each class,
instead of different instance_init functions.

-- 
Eduardo