[Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Eduardo Habkost]

The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/x86-pull-request

for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:

  i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)

----------------------------------------------------------------
x86 queue, 2018-01-17

Highlight: new CPU models that expose CPU features that guests
can use to mitigate CVE-2017-5715 (Spectre variant #2).

----------------------------------------------------------------

Eduardo Habkost (5):
  i386: Change X86CPUDefinition::model_id to const char*
  i386: Add spec-ctrl CPUID bit
  i386: Add FEAT_8000_0008_EBX CPUID feature word
  i386: Add new -IBRS versions of Intel CPU models
  i386: Add EPYC-IBPB CPU model

Haozhong Zhang (2):
  pc: add 2.12 machine types
  target/i386: add clflushopt to "Skylake-Server" cpu model

Paolo Bonzini (1):
  i386: Add support for SPEC_CTRL MSR

 include/hw/i386/pc.h  |   8 +
 target/i386/cpu.h     |   7 +
 hw/i386/pc_piix.c     |  15 +-
 hw/i386/pc_q35.c      |  13 +-
 target/i386/cpu.c     | 457 +++++++++++++++++++++++++++++++++++++++++++++++++-
 target/i386/kvm.c     |  14 ++
 target/i386/machine.c |  20 +++
 7 files changed, 524 insertions(+), 10 deletions(-)

-- 
2.14.3

[Qemu-devel] [PULL 1/8] pc: add 2.12 machine types

[Eduardo Habkost]

From: Haozhong Zhang <haozhong.zhang@intel.com>

Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Message-Id: <20171219033730.12748-2-haozhong.zhang@intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 include/hw/i386/pc.h |  3 +++
 hw/i386/pc_piix.c    | 15 ++++++++++++---
 hw/i386/pc_q35.c     | 13 +++++++++++--
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6f77eb0665..83d825e896 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -321,6 +321,9 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_COMPAT_2_11 \
+    HW_COMPAT_2_11 \
+
 #define PC_COMPAT_2_10 \
     HW_COMPAT_2_10 \
     {\
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 2febd0e136..a25619dfbf 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -426,21 +426,30 @@ static void pc_i440fx_machine_options(MachineClass *m)
     m->default_display = "std";
 }
 
-static void pc_i440fx_2_11_machine_options(MachineClass *m)
+static void pc_i440fx_2_12_machine_options(MachineClass *m)
 {
     pc_i440fx_machine_options(m);
     m->alias = "pc";
     m->is_default = 1;
 }
 
+DEFINE_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
+                      pc_i440fx_2_12_machine_options);
+
+static void pc_i440fx_2_11_machine_options(MachineClass *m)
+{
+    pc_i440fx_2_12_machine_options(m);
+    m->is_default = 0;
+    m->alias = NULL;
+    SET_MACHINE_COMPAT(m, PC_COMPAT_2_11);
+}
+
 DEFINE_I440FX_MACHINE(v2_11, "pc-i440fx-2.11", NULL,
                       pc_i440fx_2_11_machine_options);
 
 static void pc_i440fx_2_10_machine_options(MachineClass *m)
 {
     pc_i440fx_2_11_machine_options(m);
-    m->is_default = 0;
-    m->alias = NULL;
     SET_MACHINE_COMPAT(m, PC_COMPAT_2_10);
     m->auto_enable_numa_with_memhp = false;
 }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d6060043ac..5c6c608fcb 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -303,19 +303,28 @@ static void pc_q35_machine_options(MachineClass *m)
     m->max_cpus = 288;
 }
 
-static void pc_q35_2_11_machine_options(MachineClass *m)
+static void pc_q35_2_12_machine_options(MachineClass *m)
 {
     pc_q35_machine_options(m);
     m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v2_12, "pc-q35-2.12", NULL,
+                   pc_q35_2_12_machine_options);
+
+static void pc_q35_2_11_machine_options(MachineClass *m)
+{
+    pc_q35_2_12_machine_options(m);
+    m->alias = NULL;
+    SET_MACHINE_COMPAT(m, PC_COMPAT_2_11);
+}
+
 DEFINE_Q35_MACHINE(v2_11, "pc-q35-2.11", NULL,
                    pc_q35_2_11_machine_options);
 
 static void pc_q35_2_10_machine_options(MachineClass *m)
 {
     pc_q35_2_11_machine_options(m);
-    m->alias = NULL;
     SET_MACHINE_COMPAT(m, PC_COMPAT_2_10);
     m->numa_auto_assign_ram = numa_legacy_auto_assign_ram;
     m->auto_enable_numa_with_memhp = false;
-- 
2.14.3

[Qemu-devel] [PULL 2/8] target/i386: add clflushopt to "Skylake-Server" cpu model

[Eduardo Habkost]

From: Haozhong Zhang <haozhong.zhang@intel.com>

CPUID_7_0_EBX_CLFLUSHOPT is missed in current "Skylake-Server" cpu
model. Add it to "Skylake-Server" cpu model on pc-i440fx-2.12 and
pc-q35-2.12. Keep it disabled in "Skylake-Server" cpu model on older
machine types.

Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Message-Id: <20171219033730.12748-3-haozhong.zhang@intel.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 include/hw/i386/pc.h | 5 +++++
 target/i386/cpu.c    | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 83d825e896..bb49165fe0 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -323,6 +323,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_11 \
     HW_COMPAT_2_11 \
+    {\
+        .driver   = "Skylake-Server" "-" TYPE_X86_CPU,\
+        .property = "clflushopt",\
+        .value    = "off",\
+    },
 
 #define PC_COMPAT_2_10 \
     HW_COMPAT_2_10 \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ad8196b166..4385853646 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1382,7 +1382,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
             CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_CLWB |
             CPUID_7_0_EBX_AVX512F | CPUID_7_0_EBX_AVX512DQ |
             CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512CD |
-            CPUID_7_0_EBX_AVX512VL,
+            CPUID_7_0_EBX_AVX512VL | CPUID_7_0_EBX_CLFLUSHOPT,
         /* Missing: XSAVES (not supported by some Linux versions,
          * including v4.1 to v4.12).
          * KVM doesn't yet expose any XSAVES state save component,
-- 
2.14.3

[Qemu-devel] [PULL 3/8] i386: Change X86CPUDefinition::model_id to const char*

[Eduardo Habkost]

It is valid to have a 48-character model ID on CPUID, however the
definition of X86CPUDefinition::model_id is char[48], which can
make the compiler drop the null terminator from the string.

If a CPU model happens to have 48 bytes on model_id, "-cpu help"
will print garbage and the object_property_set_str() call at
x86_cpu_load_def() will read data outside the model_id array.

We could increase the array size to 49, but this would mean the
compiler would not issue a warning if a 49-char string is used by
mistake for model_id.

To make things simpler, simply change model_id to be const char*,
and validate the string length using an assert() on
x86_register_cpudef_type().

Reported-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-2-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4385853646..0e26fa4ea7 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -754,7 +754,7 @@ struct X86CPUDefinition {
     int model;
     int stepping;
     FeatureWordArray features;
-    char model_id[48];
+    const char *model_id;
 };
 
 static X86CPUDefinition builtin_x86_defs[] = {
@@ -923,6 +923,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .features[FEAT_1_EDX] =
             I486_FEATURES,
         .xlevel = 0,
+        .model_id = "",
     },
     {
         .name = "pentium",
@@ -934,6 +935,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .features[FEAT_1_EDX] =
             PENTIUM_FEATURES,
         .xlevel = 0,
+        .model_id = "",
     },
     {
         .name = "pentium2",
@@ -945,6 +947,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .features[FEAT_1_EDX] =
             PENTIUM2_FEATURES,
         .xlevel = 0,
+        .model_id = "",
     },
     {
         .name = "pentium3",
@@ -956,6 +959,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .features[FEAT_1_EDX] =
             PENTIUM3_FEATURES,
         .xlevel = 0,
+        .model_id = "",
     },
     {
         .name = "athlon",
@@ -2736,6 +2740,9 @@ static void x86_register_cpudef_type(X86CPUDefinition *def)
      * they shouldn't be set on the CPU model table.
      */
     assert(!(def->features[FEAT_8000_0001_EDX] & CPUID_EXT2_AMD_ALIASES));
+    /* catch mistakes instead of silently truncating model_id when too long */
+    assert(def->model_id && strlen(def->model_id) <= 48);
+
 
     type_register(&ti);
     g_free(typename);
-- 
2.14.3

[Qemu-devel] [PULL 4/8] i386: Add support for SPEC_CTRL MSR

[Eduardo Habkost]

From: Paolo Bonzini <pbonzini@redhat.com>

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-3-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.h     |  3 +++
 target/i386/kvm.c     | 14 ++++++++++++++
 target/i386/machine.c | 20 ++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index f64e5ed827..10264b2e31 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -353,6 +353,7 @@ typedef enum X86Seg {
 #define MSR_IA32_APICBASE_BASE          (0xfffffU<<12)
 #define MSR_IA32_FEATURE_CONTROL        0x0000003a
 #define MSR_TSC_ADJUST                  0x0000003b
+#define MSR_IA32_SPEC_CTRL              0x48
 #define MSR_IA32_TSCDEADLINE            0x6e0
 
 #define FEATURE_CONTROL_LOCKED                    (1<<0)
@@ -1125,6 +1126,8 @@ typedef struct CPUX86State {
 
     uint32_t pkru;
 
+    uint64_t spec_ctrl;
+
     /* End of state preserved by INIT (dummy marker).  */
     struct {} end_init_save;
 
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 4912f4d538..ad4b159b28 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -91,6 +91,7 @@ static bool has_msr_hv_synic;
 static bool has_msr_hv_stimer;
 static bool has_msr_hv_frequencies;
 static bool has_msr_xss;
+static bool has_msr_spec_ctrl;
 
 static uint32_t has_architectural_pmu_version;
 static uint32_t num_architectural_pmu_gp_counters;
@@ -1153,6 +1154,9 @@ static int kvm_get_supported_msrs(KVMState *s)
                 case HV_X64_MSR_TSC_FREQUENCY:
                     has_msr_hv_frequencies = true;
                     break;
+                case MSR_IA32_SPEC_CTRL:
+                    has_msr_spec_ctrl = true;
+                    break;
                 }
             }
         }
@@ -1635,6 +1639,9 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
     if (has_msr_xss) {
         kvm_msr_entry_add(cpu, MSR_IA32_XSS, env->xss);
     }
+    if (has_msr_spec_ctrl) {
+        kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, env->spec_ctrl);
+    }
 #ifdef TARGET_X86_64
     if (lm_capable_kernel) {
         kvm_msr_entry_add(cpu, MSR_CSTAR, env->cstar);
@@ -1643,6 +1650,7 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
         kvm_msr_entry_add(cpu, MSR_LSTAR, env->lstar);
     }
 #endif
+
     /*
      * The following MSRs have side effects on the guest or are too heavy
      * for normal writeback. Limit them to reset or full state updates.
@@ -1980,6 +1988,9 @@ static int kvm_get_msrs(X86CPU *cpu)
     if (has_msr_xss) {
         kvm_msr_entry_add(cpu, MSR_IA32_XSS, 0);
     }
+    if (has_msr_spec_ctrl) {
+        kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, 0);
+    }
 
 
     if (!env->tsc_valid) {
@@ -2327,6 +2338,9 @@ static int kvm_get_msrs(X86CPU *cpu)
                 env->mtrr_var[MSR_MTRRphysIndex(index)].base = msrs[i].data;
             }
             break;
+        case MSR_IA32_SPEC_CTRL:
+            env->spec_ctrl = msrs[i].data;
+            break;
         }
     }
 
diff --git a/target/i386/machine.c b/target/i386/machine.c
index df5ec359eb..361c05aedf 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -818,6 +818,25 @@ static const VMStateDescription vmstate_mcg_ext_ctl = {
     }
 };
 
+static bool spec_ctrl_needed(void *opaque)
+{
+    X86CPU *cpu = opaque;
+    CPUX86State *env = &cpu->env;
+
+    return env->spec_ctrl != 0;
+}
+
+static const VMStateDescription vmstate_spec_ctrl = {
+    .name = "cpu/spec_ctrl",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .needed = spec_ctrl_needed,
+    .fields = (VMStateField[]){
+        VMSTATE_UINT64(env.spec_ctrl, X86CPU),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
 VMStateDescription vmstate_x86_cpu = {
     .name = "cpu",
     .version_id = 12,
@@ -936,6 +955,7 @@ VMStateDescription vmstate_x86_cpu = {
 #ifdef TARGET_X86_64
         &vmstate_pkru,
 #endif
+        &vmstate_spec_ctrl,
         &vmstate_mcg_ext_ctl,
         NULL
     }
-- 
2.14.3

[Qemu-devel] [PULL 5/8] i386: Add spec-ctrl CPUID bit

[Eduardo Habkost]

Add the feature name and a CPUID_7_0_EDX_SPEC_CTRL macro.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-4-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.h | 1 +
 target/i386/cpu.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 10264b2e31..d7bae242cd 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -667,6 +667,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 
 #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network Instructions */
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation Single Precision */
+#define CPUID_7_0_EDX_SPEC_CTRL     (1U << 26) /* Speculation Control */
 
 #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
 #define CPUID_XSAVE_XSAVEC     (1U << 1)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 0e26fa4ea7..7f815458a5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -459,7 +459,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
             NULL, NULL, NULL, NULL,
             NULL, NULL, NULL, NULL,
             NULL, NULL, NULL, NULL,
-            NULL, NULL, NULL, NULL,
+            NULL, NULL, "spec-ctrl", NULL,
             NULL, NULL, NULL, NULL,
         },
         .cpuid_eax = 7,
-- 
2.14.3

[Qemu-devel] [PULL 6/8] i386: Add FEAT_8000_0008_EBX CPUID feature word

[Eduardo Habkost]

Add the new feature word and the "ibpb" feature flag.

Based on a patch by Paolo Bonzini.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-5-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.h |  3 +++
 target/i386/cpu.c | 19 ++++++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d7bae242cd..30cc5628d2 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -472,6 +472,7 @@ typedef enum FeatureWord {
     FEAT_8000_0001_EDX, /* CPUID[8000_0001].EDX */
     FEAT_8000_0001_ECX, /* CPUID[8000_0001].ECX */
     FEAT_8000_0007_EDX, /* CPUID[8000_0007].EDX */
+    FEAT_8000_0008_EBX, /* CPUID[8000_0008].EBX */
     FEAT_C000_0001_EDX, /* CPUID[C000_0001].EDX */
     FEAT_KVM,           /* CPUID[4000_0001].EAX (KVM_CPUID_FEATURES) */
     FEAT_HYPERV_EAX,    /* CPUID[4000_0003].EAX */
@@ -669,6 +670,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation Single Precision */
 #define CPUID_7_0_EDX_SPEC_CTRL     (1U << 26) /* Speculation Control */
 
+#define CPUID_8000_0008_EBX_IBPB    (1U << 12) /* Indirect Branch Prediction Barrier */
+
 #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
 #define CPUID_XSAVE_XSAVEC     (1U << 1)
 #define CPUID_XSAVE_XGETBV1    (1U << 2)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 7f815458a5..6fe14362cc 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -483,6 +483,22 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
         .tcg_features = TCG_APM_FEATURES,
         .unmigratable_flags = CPUID_APM_INVTSC,
     },
+    [FEAT_8000_0008_EBX] = {
+        .feat_names = {
+            NULL, NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+            "ibpb", NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+            NULL, NULL, NULL, NULL,
+        },
+        .cpuid_eax = 0x80000008,
+        .cpuid_reg = R_EBX,
+        .tcg_features = 0,
+        .unmigratable_flags = 0,
+    },
     [FEAT_XSAVE] = {
         .feat_names = {
             "xsaveopt", "xsavec", "xgetbv1", "xsaves",
@@ -3130,7 +3146,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         } else {
             *eax = cpu->phys_bits;
         }
-        *ebx = 0;
+        *ebx = env->features[FEAT_8000_0008_EBX];
         *ecx = 0;
         *edx = 0;
         if (cs->nr_cores * cs->nr_threads > 1) {
@@ -3593,6 +3609,7 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
         x86_cpu_adjust_feat_level(cpu, FEAT_8000_0001_EDX);
         x86_cpu_adjust_feat_level(cpu, FEAT_8000_0001_ECX);
         x86_cpu_adjust_feat_level(cpu, FEAT_8000_0007_EDX);
+        x86_cpu_adjust_feat_level(cpu, FEAT_8000_0008_EBX);
         x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
         x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
         x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
-- 
2.14.3

[Qemu-devel] [PULL 7/8] i386: Add new -IBRS versions of Intel CPU models

[Eduardo Habkost]

The new MSR IA32_SPEC_CTRL MSR was introduced by a recent Intel
microcode updated and can be used by OSes to mitigate
CVE-2017-5715.  Unfortunately we can't change the existing CPU
models without breaking existing setups, so users need to
explicitly update their VM configuration to use the new *-IBRS
CPU model if they want to expose IBRS to guests.

The new CPU models are simple copies of the existing CPU models,
with just CPUID_7_0_EDX_SPEC_CTRL added and model_id updated.

Cc: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-6-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.c | 379 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 378 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6fe14362cc..365458a6a0 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1085,6 +1085,31 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Core i7 9xx (Nehalem Class Core i7)",
     },
+    {
+        .name = "Nehalem-IBRS",
+        .level = 11,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 26,
+        .stepping = 3,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+            CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_LAHF_LM,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core i7 9xx (Nehalem Core i7, IBRS update)",
+    },
     {
         .name = "Westmere",
         .level = 11,
@@ -1111,6 +1136,34 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)",
     },
+    {
+        .name = "Westmere-IBRS",
+        .level = 11,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 44,
+        .stepping = 1,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_LAHF_LM,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Westmere E56xx/L56xx/X56xx (IBRS update)",
+    },
     {
         .name = "SandyBridge",
         .level = 0xd,
@@ -1142,6 +1195,39 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Xeon E312xx (Sandy Bridge)",
     },
+    {
+        .name = "SandyBridge-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 42,
+        .stepping = 1,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            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,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_LAHF_LM,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Xeon E312xx (Sandy Bridge, IBRS update)",
+    },
     {
         .name = "IvyBridge",
         .level = 0xd,
@@ -1176,6 +1262,42 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Xeon E3-12xx v2 (Ivy Bridge)",
     },
+    {
+        .name = "IvyBridge-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 58,
+        .stepping = 9,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            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 | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_7_0_EBX] =
+            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP |
+            CPUID_7_0_EBX_ERMS,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_LAHF_LM,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)",
+    },
     {
         .name = "Haswell-noTSX",
         .level = 0xd,
@@ -1211,7 +1333,46 @@ static X86CPUDefinition builtin_x86_defs[] = {
             CPUID_6_EAX_ARAT,
         .xlevel = 0x80000008,
         .model_id = "Intel Core Processor (Haswell, no TSX)",
-    },    {
+    },
+    {
+        .name = "Haswell-noTSX-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 60,
+        .stepping = 1,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
+            CPUID_7_0_EBX_AVX2 | CPUID_7_0_EBX_SMEP |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core Processor (Haswell, no TSX, IBRS)",
+    },
+    {
         .name = "Haswell",
         .level = 0xd,
         .vendor = CPUID_VENDOR_INTEL,
@@ -1248,6 +1409,45 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Core Processor (Haswell)",
     },
+    {
+        .name = "Haswell-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 60,
+        .stepping = 4,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            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 |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+            CPUID_7_0_EBX_RTM,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core Processor (Haswell, IBRS)",
+    },
     {
         .name = "Broadwell-noTSX",
         .level = 0xd,
@@ -1286,6 +1486,46 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Core Processor (Broadwell, no TSX)",
     },
+    {
+        .name = "Broadwell-noTSX-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 61,
+        .stepping = 2,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
+            CPUID_7_0_EBX_AVX2 | CPUID_7_0_EBX_SMEP |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+            CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
+            CPUID_7_0_EBX_SMAP,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core Processor (Broadwell, no TSX, IBRS)",
+    },
     {
         .name = "Broadwell",
         .level = 0xd,
@@ -1324,6 +1564,46 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Core Processor (Broadwell)",
     },
+    {
+        .name = "Broadwell-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 61,
+        .stepping = 2,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            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 |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+            CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
+            CPUID_7_0_EBX_SMAP,
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core Processor (Broadwell, IBRS)",
+    },
     {
         .name = "Skylake-Client",
         .level = 0xd,
@@ -1369,6 +1649,53 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Core Processor (Skylake)",
     },
+    {
+        .name = "Skylake-Client-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 94,
+        .stepping = 3,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            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 |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+            CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
+            CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_MPX,
+        /* Missing: XSAVES (not supported by some Linux versions,
+         * including v4.1 to v4.12).
+         * KVM doesn't yet expose any XSAVES state save component,
+         * and the only one defined in Skylake (processor tracing)
+         * probably will block migration anyway.
+         */
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
+            CPUID_XSAVE_XGETBV1,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Core Processor (Skylake, IBRS)",
+    },
     {
         .name = "Skylake-Server",
         .level = 0xd,
@@ -1417,6 +1744,56 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Xeon Processor (Skylake)",
     },
+    {
+        .name = "Skylake-Server-IBRS",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 85,
+        .stepping = 4,
+        .features[FEAT_1_EDX] =
+            CPUID_VME | 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,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+            CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
+            CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+            CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
+            CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE |
+            CPUID_EXT_PCID | CPUID_EXT_F16C | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_RDTSCP |
+            CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL,
+        .features[FEAT_7_0_EBX] =
+            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 |
+            CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS | CPUID_7_0_EBX_INVPCID |
+            CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
+            CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_CLWB |
+            CPUID_7_0_EBX_AVX512F | CPUID_7_0_EBX_AVX512DQ |
+            CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512CD |
+            CPUID_7_0_EBX_AVX512VL,
+        /* Missing: XSAVES (not supported by some Linux versions,
+         * including v4.1 to v4.12).
+         * KVM doesn't yet expose any XSAVES state save component,
+         * and the only one defined in Skylake (processor tracing)
+         * probably will block migration anyway.
+         */
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
+            CPUID_XSAVE_XGETBV1,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x80000008,
+        .model_id = "Intel Xeon Processor (Skylake, IBRS)",
+    },
     {
         .name = "Opteron_G1",
         .level = 5,
-- 
2.14.3

[Qemu-devel] [PULL 8/8] i386: Add EPYC-IBPB CPU model

[Eduardo Habkost]

EPYC-IBPB is a copy of the EPYC CPU model with
just CPUID_8000_0008_EBX_IBPB added.

Cc: Jiri Denemark <jdenemar@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180109154519.25634-7-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 365458a6a0..a49d2221ad 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1968,6 +1968,52 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x8000000A,
         .model_id = "AMD EPYC Processor",
     },
+    {
+        .name = "EPYC-IBPB",
+        .level = 0xd,
+        .vendor = CPUID_VENDOR_AMD,
+        .family = 23,
+        .model = 1,
+        .stepping = 2,
+        .features[FEAT_1_EDX] =
+            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_VME | CPUID_FP87,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_RDRAND | CPUID_EXT_F16C | CPUID_EXT_AVX |
+            CPUID_EXT_XSAVE | CPUID_EXT_AES |  CPUID_EXT_POPCNT |
+            CPUID_EXT_MOVBE | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+            CPUID_EXT_CX16 | CPUID_EXT_FMA | CPUID_EXT_SSSE3 |
+            CPUID_EXT_MONITOR | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_PDPE1GB |
+            CPUID_EXT2_FFXSR | CPUID_EXT2_MMXEXT | CPUID_EXT2_NX |
+            CPUID_EXT2_SYSCALL,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
+            CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
+            CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+        .features[FEAT_8000_0008_EBX] =
+            CPUID_8000_0008_EBX_IBPB,
+        .features[FEAT_7_0_EBX] =
+            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_AVX2 |
+            CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_RDSEED |
+            CPUID_7_0_EBX_ADX | CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_CLFLUSHOPT |
+            CPUID_7_0_EBX_SHA_NI,
+        /* Missing: XSAVES (not supported by some Linux versions,
+         * including v4.1 to v4.12).
+         * KVM doesn't yet expose any XSAVES state save component.
+         */
+        .features[FEAT_XSAVE] =
+            CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
+            CPUID_XSAVE_XGETBV1,
+        .features[FEAT_6_EAX] =
+            CPUID_6_EAX_ARAT,
+        .xlevel = 0x8000000A,
+        .model_id = "AMD EPYC Processor (with IBPB)",
+    },
 };
 
 typedef struct PropValue {
-- 
2.14.3

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Peter Maydell]

On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
>
> are available in the Git repository at:
>
>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>
> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>
>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>
> ----------------------------------------------------------------
> x86 queue, 2018-01-17
>
> Highlight: new CPU models that expose CPU features that guests
> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Christian Ehrhardt]

On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>
>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
>>
>> are available in the Git repository at:
>>
>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>
>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>
>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>
>> ----------------------------------------------------------------
>> x86 queue, 2018-01-17
>>
>> Highlight: new CPU models that expose CPU features that guests
>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>
>
> Applied, thanks.
>
> -- PMM
>

Hi,
I was kind of clinging to [1] so far and had the expectation that all
those would be wrapped up in 2.11.1 once ready.
I see that the s390x changes are targeted to qemu-stable (well to
admit I suggested so referring the article above).
So I'd expected to see this series to show up on qemu-stable as well
but haven't seen it so far.

Therefore I wanted to ask if there was a change of plans in that
regard or if it needs just a few days more to see (part of) this
series on qemu-stable and on its way into 2.11.1?

[1]: https://www.qemu.org/2018/01/04/spectre/

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Christian Borntraeger]

On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>>
>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>>
>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>>
>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>>
>>> ----------------------------------------------------------------
>>> x86 queue, 2018-01-17
>>>
>>> Highlight: new CPU models that expose CPU features that guests
>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>>
>>
>> Applied, thanks.
>>
>> -- PMM
>>
> 
> Hi,
> I was kind of clinging to [1] so far and had the expectation that all
> those would be wrapped up in 2.11.1 once ready.
> I see that the s390x changes are targeted to qemu-stable (well to
> admit I suggested so referring the article above).
> So I'd expected to see this series to show up on qemu-stable as well
> but haven't seen it so far.
> 
> Therefore I wanted to ask if there was a change of plans in that
> regard or if it needs just a few days more to see (part of) this
> series on qemu-stable and on its way into 2.11.1?
> 
> [1]: https://www.qemu.org/2018/01/04/spectre/

Adding Michael,

Yes, I think it makes sense to have the guest enablement for the spectre 
mitigations available in 2.11.1 for all architectures that provide it. 
(this queue for x86, Connies pending S390 patches, whatever Power
and arm will do).

Not sure about a 2.10.3?

Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

[Cornelia Huck]

On Tue, 23 Jan 2018 10:59:39 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:  
> >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:  
> >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> >>>
> >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> >>>
> >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> >>>
> >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> >>>
> >>> ----------------------------------------------------------------
> >>> x86 queue, 2018-01-17
> >>>
> >>> Highlight: new CPU models that expose CPU features that guests
> >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> >>>  
> >>
> >> Applied, thanks.
> >>
> >> -- PMM
> >>  
> > 
> > Hi,
> > I was kind of clinging to [1] so far and had the expectation that all
> > those would be wrapped up in 2.11.1 once ready.
> > I see that the s390x changes are targeted to qemu-stable (well to
> > admit I suggested so referring the article above).
> > So I'd expected to see this series to show up on qemu-stable as well
> > but haven't seen it so far.
> > 
> > Therefore I wanted to ask if there was a change of plans in that
> > regard or if it needs just a few days more to see (part of) this
> > series on qemu-stable and on its way into 2.11.1?
> > 
> > [1]: https://www.qemu.org/2018/01/04/spectre/  
> 
> Adding Michael,
> 
> Yes, I think it makes sense to have the guest enablement for the spectre 
> mitigations available in 2.11.1 for all architectures that provide it. 
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

Also note that we will need a headers update for 2.11.1.

> 
> Not sure about a 2.10.3?

I'm not sure how far back we want to do stable changes (the further
back, the more likely it is that the patches need some massaging).
Also, I'm still not quite sure what the intended consumers are for our
stable trees.

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Christian Ehrhardt]

On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
>
>
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
>> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>>>
>>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>>>>
>>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
>>>>
>>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
>>>>
>>>> ----------------------------------------------------------------
>>>> x86 queue, 2018-01-17
>>>>
>>>> Highlight: new CPU models that expose CPU features that guests
>>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
>>>>
>>>
>>> Applied, thanks.
>>>
>>> -- PMM
>>>
>>
>> Hi,
>> I was kind of clinging to [1] so far and had the expectation that all
>> those would be wrapped up in 2.11.1 once ready.
>> I see that the s390x changes are targeted to qemu-stable (well to
>> admit I suggested so referring the article above).
>> So I'd expected to see this series to show up on qemu-stable as well
>> but haven't seen it so far.
>>
>> Therefore I wanted to ask if there was a change of plans in that
>> regard or if it needs just a few days more to see (part of) this
>> series on qemu-stable and on its way into 2.11.1?
>>
>> [1]: https://www.qemu.org/2018/01/04/spectre/
>
> Adding Michael,
>
> Yes, I think it makes sense to have the guest enablement for the spectre
> mitigations available in 2.11.1 for all architectures that provide it.
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
[PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
the PPC version of all of this right?
Not sure who to add for Arm :-/

@Cornelia - the consumers of these stable changes in particular IMHO
are Distributions for security updates.
Seeing at least one backport into 2.11.1 would be very helpful to
avoid issues that would not apply to a forward thinking 2.12 commit.
Such a (even short distance) backport being done by the Author would
have the lowest risk of such issues creeping in.
I'm not so sure on 2.(<11).x  - but one backport at least into the
latest release would be very nice to fulfill the [1] announcement
referenced above and provide a first release of these important
changes available earlier than full 2.12.

cu
Christian

Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

[Cornelia Huck]

On Tue, 23 Jan 2018 11:34:18 +0100
Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote:

> On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
> >
> >
> > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:  
> >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:  
> >>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:  
> >>>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> >>>>
> >>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> >>>>
> >>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> >>>>
> >>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> x86 queue, 2018-01-17
> >>>>
> >>>> Highlight: new CPU models that expose CPU features that guests
> >>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> >>>>  
> >>>
> >>> Applied, thanks.
> >>>
> >>> -- PMM
> >>>  
> >>
> >> Hi,
> >> I was kind of clinging to [1] so far and had the expectation that all
> >> those would be wrapped up in 2.11.1 once ready.
> >> I see that the s390x changes are targeted to qemu-stable (well to
> >> admit I suggested so referring the article above).
> >> So I'd expected to see this series to show up on qemu-stable as well
> >> but haven't seen it so far.
> >>
> >> Therefore I wanted to ask if there was a change of plans in that
> >> regard or if it needs just a few days more to see (part of) this
> >> series on qemu-stable and on its way into 2.11.1?
> >>
> >> [1]: https://www.qemu.org/2018/01/04/spectre/  
> >
> > Adding Michael,
> >
> > Yes, I think it makes sense to have the guest enablement for the spectre
> > mitigations available in 2.11.1 for all architectures that provide it.
> > (this queue for x86, Connies pending S390 patches, whatever Power
> > and arm will do).  
> 
> Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> the PPC version of all of this right?
> Not sure who to add for Arm :-/
> 
> @Cornelia - the consumers of these stable changes in particular IMHO
> are Distributions for security updates.
> Seeing at least one backport into 2.11.1 would be very helpful to
> avoid issues that would not apply to a forward thinking 2.12 commit.
> Such a (even short distance) backport being done by the Author would
> have the lowest risk of such issues creeping in.
> I'm not so sure on 2.(<11).x  - but one backport at least into the
> latest release would be very nice to fulfill the [1] announcement
> referenced above and provide a first release of these important
> changes available earlier than full 2.12.

I agree that a backport unto 2.11.x is useful.

But I still think we should clarify the purpose of our stable tree --
not necessarily in this thread, though.

Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Cornelia Huck (2018-01-23 04:50:45)
> On Tue, 23 Jan 2018 11:34:18 +0100
> Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote:
> 
> > On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
> > <borntraeger@de.ibm.com> wrote:
> > >
> > >
> > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:  
> > >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:  
> > >>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:  
> > >>>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > >>>>
> > >>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > >>>>
> > >>>> are available in the Git repository at:
> > >>>>
> > >>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > >>>>
> > >>>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > >>>>
> > >>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > >>>>
> > >>>> ----------------------------------------------------------------
> > >>>> x86 queue, 2018-01-17
> > >>>>
> > >>>> Highlight: new CPU models that expose CPU features that guests
> > >>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > >>>>  
> > >>>
> > >>> Applied, thanks.
> > >>>
> > >>> -- PMM
> > >>>  
> > >>
> > >> Hi,
> > >> I was kind of clinging to [1] so far and had the expectation that all
> > >> those would be wrapped up in 2.11.1 once ready.
> > >> I see that the s390x changes are targeted to qemu-stable (well to
> > >> admit I suggested so referring the article above).
> > >> So I'd expected to see this series to show up on qemu-stable as well
> > >> but haven't seen it so far.
> > >>
> > >> Therefore I wanted to ask if there was a change of plans in that
> > >> regard or if it needs just a few days more to see (part of) this
> > >> series on qemu-stable and on its way into 2.11.1?
> > >>
> > >> [1]: https://www.qemu.org/2018/01/04/spectre/  
> > >
> > > Adding Michael,
> > >
> > > Yes, I think it makes sense to have the guest enablement for the spectre
> > > mitigations available in 2.11.1 for all architectures that provide it.
> > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > and arm will do).  
> > 
> > Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> > [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> > the PPC version of all of this right?
> > Not sure who to add for Arm :-/
> > 
> > @Cornelia - the consumers of these stable changes in particular IMHO
> > are Distributions for security updates.
> > Seeing at least one backport into 2.11.1 would be very helpful to
> > avoid issues that would not apply to a forward thinking 2.12 commit.
> > Such a (even short distance) backport being done by the Author would
> > have the lowest risk of such issues creeping in.
> > I'm not so sure on 2.(<11).x  - but one backport at least into the
> > latest release would be very nice to fulfill the [1] announcement
> > referenced above and provide a first release of these important
> > changes available earlier than full 2.12.
> 
> I agree that a backport unto 2.11.x is useful.
> 
> But I still think we should clarify the purpose of our stable tree --
> not necessarily in this thread, though.
> 

Generally the idea is a development cycle's worth of bug/security fixes
that a distro that bases on, say, 2.11, can pull in without any other
changes throughout their stack. Stuff like this is somewhat of an
exceptional case because it doesn't have any benefit to someone who
just drops it into their existing stack, but if it seems likely they'll
become reliant on it then it makes sense. We've done this in the past to
fix stuff like migration breakages that were discovered after release
and required new machine options. Certainly not an ideal situation
though.

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Peter Maydell]

On 23 January 2018 at 10:34, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> the PPC version of all of this right?
> Not sure who to add for Arm :-/

AIUI for Arm no QEMU changes should be required -- KVM VMs always
use the same CPU type as the host, and the kernel always exposes
the same MIDR (main ID register) value to the guest as the host has,
and the guest kernel fixes will key off the MIDR.

thanks
-- PMM

Re: [Qemu-devel] [qemu-s390x] [PULL 0/8] x86 queue, 2018-01-17

[David Hildenbrand]

On 23.01.2018 12:14, Peter Maydell wrote:
> On 23 January 2018 at 10:34, Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
>> Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
>> [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
>> the PPC version of all of this right?
>> Not sure who to add for Arm :-/
> 
> AIUI for Arm no QEMU changes should be required -- KVM VMs always
> use the same CPU type as the host, and the kernel always exposes
> the same MIDR (main ID register) value to the guest as the host has,
> and the guest kernel fixes will key off the MIDR.

Unrelated, but how can ARM make sure that migration back and forth works
reliably? (e.g. from a system with spectre fixes to a system without
spectre fixes)

Thanks!

> 
> thanks
> -- PMM
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Christian Borntraeger (2018-01-23 03:59:39)
> 
> 
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> >>>
> >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> >>>
> >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> >>>
> >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> >>>
> >>> ----------------------------------------------------------------
> >>> x86 queue, 2018-01-17
> >>>
> >>> Highlight: new CPU models that expose CPU features that guests
> >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> >>>
> >>
> >> Applied, thanks.
> >>
> >> -- PMM
> >>
> > 
> > Hi,
> > I was kind of clinging to [1] so far and had the expectation that all
> > those would be wrapped up in 2.11.1 once ready.
> > I see that the s390x changes are targeted to qemu-stable (well to
> > admit I suggested so referring the article above).
> > So I'd expected to see this series to show up on qemu-stable as well
> > but haven't seen it so far.
> > 
> > Therefore I wanted to ask if there was a change of plans in that
> > regard or if it needs just a few days more to see (part of) this
> > series on qemu-stable and on its way into 2.11.1?
> > 
> > [1]: https://www.qemu.org/2018/01/04/spectre/
> 
> Adding Michael,
> 
> Yes, I think it makes sense to have the guest enablement for the spectre 
> mitigations available in 2.11.1 for all architectures that provide it. 
> (this queue for x86, Connies pending S390 patches, whatever Power
> and arm will do).

That's my plan as well, but IIUC the QEMU side of these patches rely on
a KVM flag that in turn relies on this series:

  https://lkml.org/lkml/2018/1/20/158

But that's still in RFC and Linus seems to have reservations with the
current code. Since coordinating these all this to users/downstreams is
somewhat of a mess I was thinking we should accompany the 2.11.1 release
with a blog post on the various options/backports/microcode needed throughout
the stack to enable the fixes, but until there's a stable patchset on
the linux side I'm not sure there's much worth in putting out the 2.11.1
release (if I'm missing something here please let me know).

There's also the testing aspect of this, which I'd at least like to cover
on the x86 side. I've be doing some basic testing on top of early versions
of the IBRS patches and KVM patches, but I'd really like to make sure
everything is working on top of what's ultimately going upstream before
I commit the release.

In the meantime I've started a staging tree for 2.11.1 here:

  https://github.com/mdroth/qemu/commits/stable-2.11-staging

it doesn't have these patches yet, and given the above I'm not sure it
makes sense to try to set a release date yet, but I'll update the tree
as we go and post a call-for-patches within a day or so where we can
coordinate what else should go in for other archs.

> 
> Not sure about a 2.10.3?
> 

Out of support as far as stable releases go; will have to leave that one
up to the downstreams.

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Eduardo Habkost]

On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > 
> > 
> > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > >>>
> > >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > >>>
> > >>> are available in the Git repository at:
> > >>>
> > >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > >>>
> > >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > >>>
> > >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > >>>
> > >>> ----------------------------------------------------------------
> > >>> x86 queue, 2018-01-17
> > >>>
> > >>> Highlight: new CPU models that expose CPU features that guests
> > >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > >>>
> > >>
> > >> Applied, thanks.
> > >>
> > >> -- PMM
> > >>
> > > 
> > > Hi,
> > > I was kind of clinging to [1] so far and had the expectation that all
> > > those would be wrapped up in 2.11.1 once ready.
> > > I see that the s390x changes are targeted to qemu-stable (well to
> > > admit I suggested so referring the article above).
> > > So I'd expected to see this series to show up on qemu-stable as well
> > > but haven't seen it so far.
> > > 
> > > Therefore I wanted to ask if there was a change of plans in that
> > > regard or if it needs just a few days more to see (part of) this
> > > series on qemu-stable and on its way into 2.11.1?
> > > 
> > > [1]: https://www.qemu.org/2018/01/04/spectre/
> > 
> > Adding Michael,
> > 
> > Yes, I think it makes sense to have the guest enablement for the spectre 
> > mitigations available in 2.11.1 for all architectures that provide it. 
> > (this queue for x86, Connies pending S390 patches, whatever Power
> > and arm will do).
> 
> That's my plan as well, but IIUC the QEMU side of these patches rely on
> a KVM flag that in turn relies on this series:
> 
>   https://lkml.org/lkml/2018/1/20/158

Actually it depends on:
https://lkml.org/lkml/2018/1/9/329
([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest)

The ability to expose IBRS to guests doesn't seem to depend on
the host kernel using IBRS to protect itself.  But I guess it
will be easier to merge that code after Linux developers decide
what they'll do.  Paolo, what's your take on this?

Note that there are released OSes that use IBRS (Windows and
RHEL), so even if upstream Linux decide to not rely on IBRS,
users will probably want to expose IBRS to VMs as soon as KVM
becomes able to do that.

BUT:

> 
> But that's still in RFC and Linus seems to have reservations with the
> current code. Since coordinating these all this to users/downstreams is
> somewhat of a mess I was thinking we should accompany the 2.11.1 release
> with a blog post on the various options/backports/microcode needed throughout
> the stack to enable the fixes, but until there's a stable patchset on
> the linux side I'm not sure there's much worth in putting out the 2.11.1
> release (if I'm missing something here please let me know).

I'm inclined to agree.  I merged the -IBRS CPU models expecting
that the fixes would be included quickly in upstream Linux too,
but it was not the case.

To be honest, I don't think adding new CPU models are the proper
solution for the problem.  They are just a quick solution that
doesn't require intrusive changes in the management stack.

Meltdown & Spectre made us painfully aware of limitations of
management stacks out there (esp. OpenStack): they normally don't
have an easy mechanism to enable CPU features that are not part
of an existing CPU model name.  A good management stack would be
able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
"Westmere-IBRS" if it knows all the hosts on a given
cluster/migration-set/whatever-it-is-called support the feature.
The same applies to other flags like ibpb and pcid.

There's work being done on OpenStack to fix this,
e.g.: https://review.openstack.org/#/c/534384/


That said, we will probably want to include MSR code and the CPU
feature flag names (spec-ctrl and ibpb) on the stable branch as
soon as possible.  This way, people will have the option to
manually enable those features (or make them automatically
available using "-cpu host") before a decision is made regarding
CPU model names.

I can send a patch series to -stable including only those
patches, if it makes the work easier.


> 
> There's also the testing aspect of this, which I'd at least like to cover
> on the x86 side. I've be doing some basic testing on top of early versions
> of the IBRS patches and KVM patches, but I'd really like to make sure
> everything is working on top of what's ultimately going upstream before
> I commit the release.
> 
> In the meantime I've started a staging tree for 2.11.1 here:
> 
>   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> 
> it doesn't have these patches yet, and given the above I'm not sure it
> makes sense to try to set a release date yet, but I'll update the tree
> as we go and post a call-for-patches within a day or so where we can
> coordinate what else should go in for other archs.
> 
> > 
> > Not sure about a 2.10.3?
> > 
> 
> Out of support as far as stable releases go; will have to leave that one
> up to the downstreams.

-- 
Eduardo

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Eduardo Habkost (2018-01-23 13:31:18)
> On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> > Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > > 
> > > 
> > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > > >>>
> > > >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > > >>>
> > > >>> are available in the Git repository at:
> > > >>>
> > > >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > > >>>
> > > >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > > >>>
> > > >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > > >>>
> > > >>> ----------------------------------------------------------------
> > > >>> x86 queue, 2018-01-17
> > > >>>
> > > >>> Highlight: new CPU models that expose CPU features that guests
> > > >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > > >>>
> > > >>
> > > >> Applied, thanks.
> > > >>
> > > >> -- PMM
> > > >>
> > > > 
> > > > Hi,
> > > > I was kind of clinging to [1] so far and had the expectation that all
> > > > those would be wrapped up in 2.11.1 once ready.
> > > > I see that the s390x changes are targeted to qemu-stable (well to
> > > > admit I suggested so referring the article above).
> > > > So I'd expected to see this series to show up on qemu-stable as well
> > > > but haven't seen it so far.
> > > > 
> > > > Therefore I wanted to ask if there was a change of plans in that
> > > > regard or if it needs just a few days more to see (part of) this
> > > > series on qemu-stable and on its way into 2.11.1?
> > > > 
> > > > [1]: https://www.qemu.org/2018/01/04/spectre/
> > > 
> > > Adding Michael,
> > > 
> > > Yes, I think it makes sense to have the guest enablement for the spectre 
> > > mitigations available in 2.11.1 for all architectures that provide it. 
> > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > and arm will do).
> > 
> > That's my plan as well, but IIUC the QEMU side of these patches rely on
> > a KVM flag that in turn relies on this series:
> > 
> >   https://lkml.org/lkml/2018/1/20/158
> 
> Actually it depends on:
> https://lkml.org/lkml/2018/1/9/329
> ([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest)
> 
> The ability to expose IBRS to guests doesn't seem to depend on
> the host kernel using IBRS to protect itself.  But I guess it
> will be easier to merge that code after Linux developers decide
> what they'll do.  Paolo, what's your take on this?
> 
> Note that there are released OSes that use IBRS (Windows and
> RHEL), so even if upstream Linux decide to not rely on IBRS,
> users will probably want to expose IBRS to VMs as soon as KVM
> becomes able to do that.

I didn't really consider that angle, but I think anyone supporting such
guests will tend to be relying on their host distros for the fixes, and
distros will want their own guest types covered as well (looks like RHEL
already has its bases covered in this regard, maybe Hyper-V too WRT to
Windows guests..)

> 
> BUT:
> 
> > 
> > But that's still in RFC and Linus seems to have reservations with the
> > current code. Since coordinating these all this to users/downstreams is
> > somewhat of a mess I was thinking we should accompany the 2.11.1 release
> > with a blog post on the various options/backports/microcode needed throughout
> > the stack to enable the fixes, but until there's a stable patchset on
> > the linux side I'm not sure there's much worth in putting out the 2.11.1
> > release (if I'm missing something here please let me know).
> 
> I'm inclined to agree.  I merged the -IBRS CPU models expecting
> that the fixes would be included quickly in upstream Linux too,
> but it was not the case.
> 
> To be honest, I don't think adding new CPU models are the proper
> solution for the problem.  They are just a quick solution that
> doesn't require intrusive changes in the management stack.
> 
> Meltdown & Spectre made us painfully aware of limitations of
> management stacks out there (esp. OpenStack): they normally don't
> have an easy mechanism to enable CPU features that are not part
> of an existing CPU model name.  A good management stack would be
> able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
> "Westmere-IBRS" if it knows all the hosts on a given
> cluster/migration-set/whatever-it-is-called support the feature.
> The same applies to other flags like ibpb and pcid.
> 
> There's work being done on OpenStack to fix this,
> e.g.: https://review.openstack.org/#/c/534384/
> 
> 
> That said, we will probably want to include MSR code and the CPU
> feature flag names (spec-ctrl and ibpb) on the stable branch as
> soon as possible.  This way, people will have the option to
> manually enable those features (or make them automatically
> available using "-cpu host") before a decision is made regarding
> CPU model names.
> 
> I can send a patch series to -stable including only those
> patches, if it makes the work easier.

Will these proposed patches be dropping the model names introduced here
in favor of those flags, or introducing them alongside?

> 
> 
> > 
> > There's also the testing aspect of this, which I'd at least like to cover
> > on the x86 side. I've be doing some basic testing on top of early versions
> > of the IBRS patches and KVM patches, but I'd really like to make sure
> > everything is working on top of what's ultimately going upstream before
> > I commit the release.
> > 
> > In the meantime I've started a staging tree for 2.11.1 here:
> > 
> >   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> > 
> > it doesn't have these patches yet, and given the above I'm not sure it
> > makes sense to try to set a release date yet, but I'll update the tree
> > as we go and post a call-for-patches within a day or so where we can
> > coordinate what else should go in for other archs.
> > 
> > > 
> > > Not sure about a 2.10.3?
> > > 
> > 
> > Out of support as far as stable releases go; will have to leave that one
> > up to the downstreams.
> 
> -- 
> Eduardo
> 

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Eduardo Habkost]

On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote:
> Quoting Eduardo Habkost (2018-01-23 13:31:18)
> > On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> > > Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > > > 
> > > > 
> > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > > > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > > > >>>
> > > > >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > > > >>>
> > > > >>> are available in the Git repository at:
> > > > >>>
> > > > >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > > > >>>
> > > > >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > > > >>>
> > > > >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > > > >>>
> > > > >>> ----------------------------------------------------------------
> > > > >>> x86 queue, 2018-01-17
> > > > >>>
> > > > >>> Highlight: new CPU models that expose CPU features that guests
> > > > >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > > > >>>
> > > > >>
> > > > >> Applied, thanks.
> > > > >>
> > > > >> -- PMM
> > > > >>
> > > > > 
> > > > > Hi,
> > > > > I was kind of clinging to [1] so far and had the expectation that all
> > > > > those would be wrapped up in 2.11.1 once ready.
> > > > > I see that the s390x changes are targeted to qemu-stable (well to
> > > > > admit I suggested so referring the article above).
> > > > > So I'd expected to see this series to show up on qemu-stable as well
> > > > > but haven't seen it so far.
> > > > > 
> > > > > Therefore I wanted to ask if there was a change of plans in that
> > > > > regard or if it needs just a few days more to see (part of) this
> > > > > series on qemu-stable and on its way into 2.11.1?
> > > > > 
> > > > > [1]: https://www.qemu.org/2018/01/04/spectre/
> > > > 
> > > > Adding Michael,
> > > > 
> > > > Yes, I think it makes sense to have the guest enablement for the spectre 
> > > > mitigations available in 2.11.1 for all architectures that provide it. 
> > > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > > and arm will do).
> > > 
> > > That's my plan as well, but IIUC the QEMU side of these patches rely on
> > > a KVM flag that in turn relies on this series:
> > > 
> > >   https://lkml.org/lkml/2018/1/20/158
> > 
> > Actually it depends on:
> > https://lkml.org/lkml/2018/1/9/329
> > ([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest)
> > 
> > The ability to expose IBRS to guests doesn't seem to depend on
> > the host kernel using IBRS to protect itself.  But I guess it
> > will be easier to merge that code after Linux developers decide
> > what they'll do.  Paolo, what's your take on this?
> > 
> > Note that there are released OSes that use IBRS (Windows and
> > RHEL), so even if upstream Linux decide to not rely on IBRS,
> > users will probably want to expose IBRS to VMs as soon as KVM
> > becomes able to do that.
> 
> I didn't really consider that angle, but I think anyone supporting such
> guests will tend to be relying on their host distros for the fixes, and
> distros will want their own guest types covered as well (looks like RHEL
> already has its bases covered in this regard, maybe Hyper-V too WRT to
> Windows guests..)

Well, who exactly is the audience for -stable?  Doesn't it
include people who run (or let their users run) Windows or RHEL
guests?


> 
> > 
> > BUT:
> > 
> > > 
> > > But that's still in RFC and Linus seems to have reservations with the
> > > current code. Since coordinating these all this to users/downstreams is
> > > somewhat of a mess I was thinking we should accompany the 2.11.1 release
> > > with a blog post on the various options/backports/microcode needed throughout
> > > the stack to enable the fixes, but until there's a stable patchset on
> > > the linux side I'm not sure there's much worth in putting out the 2.11.1
> > > release (if I'm missing something here please let me know).
> > 
> > I'm inclined to agree.  I merged the -IBRS CPU models expecting
> > that the fixes would be included quickly in upstream Linux too,
> > but it was not the case.
> > 
> > To be honest, I don't think adding new CPU models are the proper
> > solution for the problem.  They are just a quick solution that
> > doesn't require intrusive changes in the management stack.
> > 
> > Meltdown & Spectre made us painfully aware of limitations of
> > management stacks out there (esp. OpenStack): they normally don't
> > have an easy mechanism to enable CPU features that are not part
> > of an existing CPU model name.  A good management stack would be
> > able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
> > "Westmere-IBRS" if it knows all the hosts on a given
> > cluster/migration-set/whatever-it-is-called support the feature.
> > The same applies to other flags like ibpb and pcid.
> > 
> > There's work being done on OpenStack to fix this,
> > e.g.: https://review.openstack.org/#/c/534384/
> > 
> > 
> > That said, we will probably want to include MSR code and the CPU
> > feature flag names (spec-ctrl and ibpb) on the stable branch as
> > soon as possible.  This way, people will have the option to
> > manually enable those features (or make them automatically
> > available using "-cpu host") before a decision is made regarding
> > CPU model names.
> > 
> > I can send a patch series to -stable including only those
> > patches, if it makes the work easier.
> 
> Will these proposed patches be dropping the model names introduced here
> in favor of those flags, or introducing them alongside?

The flag names and MSR code (included in this pull request) are a
requirement of the new CPU models.  So it's possible to have just
the flag names, or have both the flag names and the new CPU
models.

If people are able to edit the QEMU command-line or libvirt
domain XML, they can enable the flags manually and this will be
enough for them (so the new CPU models won't be a requirement).
The difference is that picking a CPU model is easier than
enabling CPU flags manually, and some management systems don't
even allow users to configure individual CPU flags (that's why I
included the -IBRS CPU models in the tree).


> 
> > 
> > 
> > > 
> > > There's also the testing aspect of this, which I'd at least like to cover
> > > on the x86 side. I've be doing some basic testing on top of early versions
> > > of the IBRS patches and KVM patches, but I'd really like to make sure
> > > everything is working on top of what's ultimately going upstream before
> > > I commit the release.
> > > 
> > > In the meantime I've started a staging tree for 2.11.1 here:
> > > 
> > >   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> > > 
> > > it doesn't have these patches yet, and given the above I'm not sure it
> > > makes sense to try to set a release date yet, but I'll update the tree
> > > as we go and post a call-for-patches within a day or so where we can
> > > coordinate what else should go in for other archs.
> > > 
> > > > 
> > > > Not sure about a 2.10.3?
> > > > 
> > > 
> > > Out of support as far as stable releases go; will have to leave that one
> > > up to the downstreams.
> > 
> > -- 
> > Eduardo
> > 
> 

-- 
Eduardo

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Eduardo Habkost (2018-01-25 19:29:50)
> On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote:
> > Quoting Eduardo Habkost (2018-01-23 13:31:18)
> > > On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> > > > Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > > > > 
> > > > > 
> > > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > > > > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > > >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > > > > >>>
> > > > > >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > > > > >>>
> > > > > >>> are available in the Git repository at:
> > > > > >>>
> > > > > >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > > > > >>>
> > > > > >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > > > > >>>
> > > > > >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > > > > >>>
> > > > > >>> ----------------------------------------------------------------
> > > > > >>> x86 queue, 2018-01-17
> > > > > >>>
> > > > > >>> Highlight: new CPU models that expose CPU features that guests
> > > > > >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > > > > >>>
> > > > > >>
> > > > > >> Applied, thanks.
> > > > > >>
> > > > > >> -- PMM
> > > > > >>
> > > > > > 
> > > > > > Hi,
> > > > > > I was kind of clinging to [1] so far and had the expectation that all
> > > > > > those would be wrapped up in 2.11.1 once ready.
> > > > > > I see that the s390x changes are targeted to qemu-stable (well to
> > > > > > admit I suggested so referring the article above).
> > > > > > So I'd expected to see this series to show up on qemu-stable as well
> > > > > > but haven't seen it so far.
> > > > > > 
> > > > > > Therefore I wanted to ask if there was a change of plans in that
> > > > > > regard or if it needs just a few days more to see (part of) this
> > > > > > series on qemu-stable and on its way into 2.11.1?
> > > > > > 
> > > > > > [1]: https://www.qemu.org/2018/01/04/spectre/
> > > > > 
> > > > > Adding Michael,
> > > > > 
> > > > > Yes, I think it makes sense to have the guest enablement for the spectre 
> > > > > mitigations available in 2.11.1 for all architectures that provide it. 
> > > > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > > > and arm will do).
> > > > 
> > > > That's my plan as well, but IIUC the QEMU side of these patches rely on
> > > > a KVM flag that in turn relies on this series:
> > > > 
> > > >   https://lkml.org/lkml/2018/1/20/158
> > > 
> > > Actually it depends on:
> > > https://lkml.org/lkml/2018/1/9/329
> > > ([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest)
> > > 
> > > The ability to expose IBRS to guests doesn't seem to depend on
> > > the host kernel using IBRS to protect itself.  But I guess it
> > > will be easier to merge that code after Linux developers decide
> > > what they'll do.  Paolo, what's your take on this?
> > > 
> > > Note that there are released OSes that use IBRS (Windows and
> > > RHEL), so even if upstream Linux decide to not rely on IBRS,
> > > users will probably want to expose IBRS to VMs as soon as KVM
> > > becomes able to do that.
> > 
> > I didn't really consider that angle, but I think anyone supporting such
> > guests will tend to be relying on their host distros for the fixes, and
> > distros will want their own guest types covered as well (looks like RHEL
> > already has its bases covered in this regard, maybe Hyper-V too WRT to
> > Windows guests..)
> 
> Well, who exactly is the audience for -stable?  Doesn't it
> include people who run (or let their users run) Windows or RHEL
> guests?

Yes, I just think in most cases they'll likely be expecting an updated
QEMU through their distro, and distros, outside of their own guest types
(and even then), would probably prefer to roll it out once for everyone
based on what will be landing upstream.

> 
> 
> > 
> > > 
> > > BUT:
> > > 
> > > > 
> > > > But that's still in RFC and Linus seems to have reservations with the
> > > > current code. Since coordinating these all this to users/downstreams is
> > > > somewhat of a mess I was thinking we should accompany the 2.11.1 release
> > > > with a blog post on the various options/backports/microcode needed throughout
> > > > the stack to enable the fixes, but until there's a stable patchset on
> > > > the linux side I'm not sure there's much worth in putting out the 2.11.1
> > > > release (if I'm missing something here please let me know).
> > > 
> > > I'm inclined to agree.  I merged the -IBRS CPU models expecting
> > > that the fixes would be included quickly in upstream Linux too,
> > > but it was not the case.
> > > 
> > > To be honest, I don't think adding new CPU models are the proper
> > > solution for the problem.  They are just a quick solution that
> > > doesn't require intrusive changes in the management stack.
> > > 
> > > Meltdown & Spectre made us painfully aware of limitations of
> > > management stacks out there (esp. OpenStack): they normally don't
> > > have an easy mechanism to enable CPU features that are not part
> > > of an existing CPU model name.  A good management stack would be
> > > able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
> > > "Westmere-IBRS" if it knows all the hosts on a given
> > > cluster/migration-set/whatever-it-is-called support the feature.
> > > The same applies to other flags like ibpb and pcid.
> > > 
> > > There's work being done on OpenStack to fix this,
> > > e.g.: https://review.openstack.org/#/c/534384/
> > > 
> > > 
> > > That said, we will probably want to include MSR code and the CPU
> > > feature flag names (spec-ctrl and ibpb) on the stable branch as
> > > soon as possible.  This way, people will have the option to
> > > manually enable those features (or make them automatically
> > > available using "-cpu host") before a decision is made regarding
> > > CPU model names.
> > > 
> > > I can send a patch series to -stable including only those
> > > patches, if it makes the work easier.
> > 
> > Will these proposed patches be dropping the model names introduced here
> > in favor of those flags, or introducing them alongside?
> 
> The flag names and MSR code (included in this pull request) are a
> requirement of the new CPU models.  So it's possible to have just
> the flag names, or have both the flag names and the new CPU
> models.
> 
> If people are able to edit the QEMU command-line or libvirt
> domain XML, they can enable the flags manually and this will be
> enough for them (so the new CPU models won't be a requirement).
> The difference is that picking a CPU model is easier than
> enabling CPU flags manually, and some management systems don't
> even allow users to configure individual CPU flags (that's why I
> included the -IBRS CPU models in the tree).

Ok, makes sense. From a stable perspective it seems reasonable to have
both then. Is that where you're leaning on the upstream side?

If so I'll go ahead and pull these in for stable and pull in your
proposed changes when they become available (FWIW this series applies
cleanly to current stable tree so not expecting much extra work there).

> 
> 
> > 
> > > 
> > > 
> > > > 
> > > > There's also the testing aspect of this, which I'd at least like to cover
> > > > on the x86 side. I've be doing some basic testing on top of early versions
> > > > of the IBRS patches and KVM patches, but I'd really like to make sure
> > > > everything is working on top of what's ultimately going upstream before
> > > > I commit the release.
> > > > 
> > > > In the meantime I've started a staging tree for 2.11.1 here:
> > > > 
> > > >   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> > > > 
> > > > it doesn't have these patches yet, and given the above I'm not sure it
> > > > makes sense to try to set a release date yet, but I'll update the tree
> > > > as we go and post a call-for-patches within a day or so where we can
> > > > coordinate what else should go in for other archs.
> > > > 
> > > > > 
> > > > > Not sure about a 2.10.3?
> > > > > 
> > > > 
> > > > Out of support as far as stable releases go; will have to leave that one
> > > > up to the downstreams.
> > > 
> > > -- 
> > > Eduardo
> > > 
> > 
> 
> -- 
> Eduardo
> 

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Eduardo Habkost]

On Fri, Jan 26, 2018 at 10:28:52AM -0600, Michael Roth wrote:
> Quoting Eduardo Habkost (2018-01-25 19:29:50)
> > On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote:
> > > Quoting Eduardo Habkost (2018-01-23 13:31:18)
> > > > On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> > > > > Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > > > > > 
> > > > > > 
> > > > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
> > > > > > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > > > >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > > > > > >>>
> > > > > > >>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000)
> > > > > > >>>
> > > > > > >>> are available in the Git repository at:
> > > > > > >>>
> > > > > > >>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > > > > > >>>
> > > > > > >>> for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > > > > > >>>
> > > > > > >>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > > > > > >>>
> > > > > > >>> ----------------------------------------------------------------
> > > > > > >>> x86 queue, 2018-01-17
> > > > > > >>>
> > > > > > >>> Highlight: new CPU models that expose CPU features that guests
> > > > > > >>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > > > > > >>>
> > > > > > >>
> > > > > > >> Applied, thanks.
> > > > > > >>
> > > > > > >> -- PMM
> > > > > > >>
> > > > > > > 
> > > > > > > Hi,
> > > > > > > I was kind of clinging to [1] so far and had the expectation that all
> > > > > > > those would be wrapped up in 2.11.1 once ready.
> > > > > > > I see that the s390x changes are targeted to qemu-stable (well to
> > > > > > > admit I suggested so referring the article above).
> > > > > > > So I'd expected to see this series to show up on qemu-stable as well
> > > > > > > but haven't seen it so far.
> > > > > > > 
> > > > > > > Therefore I wanted to ask if there was a change of plans in that
> > > > > > > regard or if it needs just a few days more to see (part of) this
> > > > > > > series on qemu-stable and on its way into 2.11.1?
> > > > > > > 
> > > > > > > [1]: https://www.qemu.org/2018/01/04/spectre/
> > > > > > 
> > > > > > Adding Michael,
> > > > > > 
> > > > > > Yes, I think it makes sense to have the guest enablement for the spectre 
> > > > > > mitigations available in 2.11.1 for all architectures that provide it. 
> > > > > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > > > > and arm will do).
> > > > > 
> > > > > That's my plan as well, but IIUC the QEMU side of these patches rely on
> > > > > a KVM flag that in turn relies on this series:
> > > > > 
> > > > >   https://lkml.org/lkml/2018/1/20/158
> > > > 
> > > > Actually it depends on:
> > > > https://lkml.org/lkml/2018/1/9/329
> > > > ([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest)
> > > > 
> > > > The ability to expose IBRS to guests doesn't seem to depend on
> > > > the host kernel using IBRS to protect itself.  But I guess it
> > > > will be easier to merge that code after Linux developers decide
> > > > what they'll do.  Paolo, what's your take on this?
> > > > 
> > > > Note that there are released OSes that use IBRS (Windows and
> > > > RHEL), so even if upstream Linux decide to not rely on IBRS,
> > > > users will probably want to expose IBRS to VMs as soon as KVM
> > > > becomes able to do that.
> > > 
> > > I didn't really consider that angle, but I think anyone supporting such
> > > guests will tend to be relying on their host distros for the fixes, and
> > > distros will want their own guest types covered as well (looks like RHEL
> > > already has its bases covered in this regard, maybe Hyper-V too WRT to
> > > Windows guests..)
> > 
> > Well, who exactly is the audience for -stable?  Doesn't it
> > include people who run (or let their users run) Windows or RHEL
> > guests?
> 
> Yes, I just think in most cases they'll likely be expecting an updated
> QEMU through their distro, and distros, outside of their own guest types
> (and even then), would probably prefer to roll it out once for everyone
> based on what will be landing upstream.
> 
> > 
> > 
> > > 
> > > > 
> > > > BUT:
> > > > 
> > > > > 
> > > > > But that's still in RFC and Linus seems to have reservations with the
> > > > > current code. Since coordinating these all this to users/downstreams is
> > > > > somewhat of a mess I was thinking we should accompany the 2.11.1 release
> > > > > with a blog post on the various options/backports/microcode needed throughout
> > > > > the stack to enable the fixes, but until there's a stable patchset on
> > > > > the linux side I'm not sure there's much worth in putting out the 2.11.1
> > > > > release (if I'm missing something here please let me know).
> > > > 
> > > > I'm inclined to agree.  I merged the -IBRS CPU models expecting
> > > > that the fixes would be included quickly in upstream Linux too,
> > > > but it was not the case.
> > > > 
> > > > To be honest, I don't think adding new CPU models are the proper
> > > > solution for the problem.  They are just a quick solution that
> > > > doesn't require intrusive changes in the management stack.
> > > > 
> > > > Meltdown & Spectre made us painfully aware of limitations of
> > > > management stacks out there (esp. OpenStack): they normally don't
> > > > have an easy mechanism to enable CPU features that are not part
> > > > of an existing CPU model name.  A good management stack would be
> > > > able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
> > > > "Westmere-IBRS" if it knows all the hosts on a given
> > > > cluster/migration-set/whatever-it-is-called support the feature.
> > > > The same applies to other flags like ibpb and pcid.
> > > > 
> > > > There's work being done on OpenStack to fix this,
> > > > e.g.: https://review.openstack.org/#/c/534384/
> > > > 
> > > > 
> > > > That said, we will probably want to include MSR code and the CPU
> > > > feature flag names (spec-ctrl and ibpb) on the stable branch as
> > > > soon as possible.  This way, people will have the option to
> > > > manually enable those features (or make them automatically
> > > > available using "-cpu host") before a decision is made regarding
> > > > CPU model names.
> > > > 
> > > > I can send a patch series to -stable including only those
> > > > patches, if it makes the work easier.
> > > 
> > > Will these proposed patches be dropping the model names introduced here
> > > in favor of those flags, or introducing them alongside?
> > 
> > The flag names and MSR code (included in this pull request) are a
> > requirement of the new CPU models.  So it's possible to have just
> > the flag names, or have both the flag names and the new CPU
> > models.
> > 
> > If people are able to edit the QEMU command-line or libvirt
> > domain XML, they can enable the flags manually and this will be
> > enough for them (so the new CPU models won't be a requirement).
> > The difference is that picking a CPU model is easier than
> > enabling CPU flags manually, and some management systems don't
> > even allow users to configure individual CPU flags (that's why I
> > included the -IBRS CPU models in the tree).
> 
> Ok, makes sense. From a stable perspective it seems reasonable to have
> both then. Is that where you're leaning on the upstream side?

Yes.  The -IBRS CPU models are nice to have even if it's just to
avoid user confusion.


> 
> If so I'll go ahead and pull these in for stable and pull in your
> proposed changes when they become available (FWIW this series applies
> cleanly to current stable tree so not expecting much extra work there).

It looks like there's some confusion here: I don't have
additional proposed changes; the flag names and MSR code I
mentioned are already merged on master (through this pull
request).


> 
> > 
> > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > There's also the testing aspect of this, which I'd at least like to cover
> > > > > on the x86 side. I've be doing some basic testing on top of early versions
> > > > > of the IBRS patches and KVM patches, but I'd really like to make sure
> > > > > everything is working on top of what's ultimately going upstream before
> > > > > I commit the release.
> > > > > 
> > > > > In the meantime I've started a staging tree for 2.11.1 here:
> > > > > 
> > > > >   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> > > > > 
> > > > > it doesn't have these patches yet, and given the above I'm not sure it
> > > > > makes sense to try to set a release date yet, but I'll update the tree
> > > > > as we go and post a call-for-patches within a day or so where we can
> > > > > coordinate what else should go in for other archs.
> > > > > 
> > > > > > 
> > > > > > Not sure about a 2.10.3?
> > > > > > 
> > > > > 
> > > > > Out of support as far as stable releases go; will have to leave that one
> > > > > up to the downstreams.
> > > > 
> > > > -- 
> > > > Eduardo
> > > > 
> > > 
> > 
> > -- 
> > Eduardo
> > 

-- 
Eduardo

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Peter Maydell]

On 26 January 2018 at 18:08, Eduardo Habkost <ehabkost@redhat.com> wrote:
[lots of quoted text]

Could you folks try to trim down the quoted text when
you're replying to this thread, please? Every time somebody
replies to this thread and leaves the original pull request
email quoted in it it flags the thread back up onto my
"needs my attention" list...

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Eduardo Habkost (2018-01-26 12:08:16)
> It looks like there's some confusion here: I don't have
> additional proposed changes; the flag names and MSR code I
> mentioned are already merged on master (through this pull
> request).

Ah, my mistake, I thought the flags were being proposed as follow-up.
Will pull these in as is then. Thanks!

> 
> -- 
> Eduardo
>