qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
@ 2019-07-17  4:57 Tao Xu
  2019-07-17  5:39 ` Tao Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Tao Xu @ 2019-07-17  4:57 UTC (permalink / raw)
  To: ehabkost; +Cc: qemu-devel

Denverton is the Atom Processor of Intel Harrisonville platform.

For more information:
https://ark.intel.com/content/www/us/en/ark/products/\
codename/63508/denverton.html

Signed-off-by: Tao Xu <tao3.xu@intel.com>
---

Changes in v2:

    - Renamed as Denverton instead of Denverton-Server, because there
      is only server for Denverton
    - Remove vmx from cpu model
---
 target/i386/cpu.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 805ce95247..38000dd975 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2471,6 +2471,51 @@ static X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000008,
         .model_id = "Intel Xeon Processor (Icelake)",
     },
+    {
+        .name = "Denverton",
+        .level = 21,
+        .vendor = CPUID_VENDOR_INTEL,
+        .family = 6,
+        .model = 95,
+        .stepping = 1,
+        .features[FEAT_1_EDX] =
+            CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE | CPUID_TSC |
+            CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC |
+            CPUID_SEP | CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
+            CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH | CPUID_MMX | CPUID_FXSR |
+            CPUID_SSE | CPUID_SSE2,
+        .features[FEAT_1_ECX] =
+            CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
+            CPUID_EXT_SSSE3 | CPUID_EXT_CX16 | CPUID_EXT_SSE41 |
+            CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
+            CPUID_EXT_POPCNT | CPUID_EXT_TSC_DEADLINE_TIMER |
+            CPUID_EXT_AES | CPUID_EXT_XSAVE | CPUID_EXT_RDRAND,
+        .features[FEAT_8000_0001_EDX] =
+            CPUID_EXT2_SYSCALL | CPUID_EXT2_NX | CPUID_EXT2_PDPE1GB |
+            CPUID_EXT2_RDTSCP | CPUID_EXT2_LM,
+        .features[FEAT_8000_0001_ECX] =
+            CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
+        .features[FEAT_7_0_EBX] =
+            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS |
+            CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_SMAP |
+            CPUID_7_0_EBX_CLFLUSHOPT | CPUID_7_0_EBX_SHA_NI,
+        .features[FEAT_7_0_EDX] =
+            CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_ARCH_CAPABILITIES |
+            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
+        /*
+         * 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 Atom Processor (Denverton)",
+    },
     {
         .name = "SnowRidge-Server",
         .level = 27,
-- 
2.20.1



^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
  2019-07-17  4:57 [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model Tao Xu
@ 2019-07-17  5:39 ` Tao Xu
  2019-07-17 18:38   ` Eduardo Habkost
  0 siblings, 1 reply; 6+ messages in thread
From: Tao Xu @ 2019-07-17  5:39 UTC (permalink / raw)
  To: ehabkost@redhat.com; +Cc: qemu-devel@nongnu.org, Xiaoyao Li

Hi Eduardo,

Could I ask a question about introducing a old CPU model? Maybe not so 
old because it was launched in 2017. It is the former generation (Atom 
Server) of Snowridge and if this cpu model be added, qemu may can 
migrate guest between Denverton CPU and Snowridge CPU.

I am wondering which way is more appropriate, because maybe there are a 
few Denverton machines using old microcodes:

1. Just like this patch, introduce one version cpu cpu model.

2. Introduce multi versions of cpu model, cover old microcodes, may be 3 
versions.

On 7/17/2019 12:57 PM, Tao Xu wrote:
> Denverton is the Atom Processor of Intel Harrisonville platform.
> 
> For more information:
> https://ark.intel.com/content/www/us/en/ark/products/\
> codename/63508/denverton.html
> 
> Signed-off-by: Tao Xu <tao3.xu@intel.com>
> ---
> 
> Changes in v2:
> 
>      - Renamed as Denverton instead of Denverton-Server, because there
>        is only server for Denverton
>      - Remove vmx from cpu model
> ---
>   target/i386/cpu.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 45 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 805ce95247..38000dd975 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2471,6 +2471,51 @@ static X86CPUDefinition builtin_x86_defs[] = {
>           .xlevel = 0x80000008,
>           .model_id = "Intel Xeon Processor (Icelake)",
>       },
> +    {
> +        .name = "Denverton",
> +        .level = 21,
> +        .vendor = CPUID_VENDOR_INTEL,
> +        .family = 6,
> +        .model = 95,
> +        .stepping = 1,
> +        .features[FEAT_1_EDX] =
> +            CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE | CPUID_TSC |
> +            CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC |
> +            CPUID_SEP | CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
> +            CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH | CPUID_MMX | CPUID_FXSR |
> +            CPUID_SSE | CPUID_SSE2,
> +        .features[FEAT_1_ECX] =
> +            CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
> +            CPUID_EXT_SSSE3 | CPUID_EXT_CX16 | CPUID_EXT_SSE41 |
> +            CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
> +            CPUID_EXT_POPCNT | CPUID_EXT_TSC_DEADLINE_TIMER |
> +            CPUID_EXT_AES | CPUID_EXT_XSAVE | CPUID_EXT_RDRAND,
> +        .features[FEAT_8000_0001_EDX] =
> +            CPUID_EXT2_SYSCALL | CPUID_EXT2_NX | CPUID_EXT2_PDPE1GB |
> +            CPUID_EXT2_RDTSCP | CPUID_EXT2_LM,
> +        .features[FEAT_8000_0001_ECX] =
> +            CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
> +        .features[FEAT_7_0_EBX] =
> +            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS |
> +            CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_SMAP |
> +            CPUID_7_0_EBX_CLFLUSHOPT | CPUID_7_0_EBX_SHA_NI,
> +        .features[FEAT_7_0_EDX] =
> +            CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_ARCH_CAPABILITIES |
> +            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
> +        /*
> +         * 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 Atom Processor (Denverton)",
> +    },
>       {
>           .name = "SnowRidge-Server",
>           .level = 27,
> --
> 2.20.1
> 
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
  2019-07-17  5:39 ` Tao Xu
@ 2019-07-17 18:38   ` Eduardo Habkost
  2019-07-18  1:56     ` Tao Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Eduardo Habkost @ 2019-07-17 18:38 UTC (permalink / raw)
  To: Tao Xu; +Cc: qemu-devel@nongnu.org, Xiaoyao Li

On Wed, Jul 17, 2019 at 01:39:01PM +0800, Tao Xu wrote:
> Hi Eduardo,
> 
> Could I ask a question about introducing a old CPU model? Maybe not so old
> because it was launched in 2017. It is the former generation (Atom Server)
> of Snowridge and if this cpu model be added, qemu may can migrate guest
> between Denverton CPU and Snowridge CPU.
> 
> I am wondering which way is more appropriate, because maybe there are a few
> Denverton machines using old microcodes:
> 
> 1. Just like this patch, introduce one version cpu cpu model.
> 
> 2. Introduce multi versions of cpu model, cover old microcodes, may be 3
> versions.

What exactly are the differences between the old and new
microcodes?  Is it always possible to install a new microcode on
machines that are not up to date?

Both options look good to me.  I think it's OK to just declare
old microcode versions as not supported by QEMU, but I won't
complain if you decide to add multiple versions.

> 
> On 7/17/2019 12:57 PM, Tao Xu wrote:
> > Denverton is the Atom Processor of Intel Harrisonville platform.
> > 
> > For more information:
> > https://ark.intel.com/content/www/us/en/ark/products/\
> > codename/63508/denverton.html
> > 
> > Signed-off-by: Tao Xu <tao3.xu@intel.com>
> > ---
> > 
> > Changes in v2:
> > 
> >      - Renamed as Denverton instead of Denverton-Server, because there
> >        is only server for Denverton
> >      - Remove vmx from cpu model
> > ---
> >   target/i386/cpu.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 45 insertions(+)
> > 
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 805ce95247..38000dd975 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -2471,6 +2471,51 @@ static X86CPUDefinition builtin_x86_defs[] = {
> >           .xlevel = 0x80000008,
> >           .model_id = "Intel Xeon Processor (Icelake)",
> >       },
> > +    {
> > +        .name = "Denverton",
> > +        .level = 21,
> > +        .vendor = CPUID_VENDOR_INTEL,
> > +        .family = 6,
> > +        .model = 95,
> > +        .stepping = 1,
> > +        .features[FEAT_1_EDX] =
> > +            CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE | CPUID_TSC |
> > +            CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC |
> > +            CPUID_SEP | CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
> > +            CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH | CPUID_MMX | CPUID_FXSR |
> > +            CPUID_SSE | CPUID_SSE2,
> > +        .features[FEAT_1_ECX] =
> > +            CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
> > +            CPUID_EXT_SSSE3 | CPUID_EXT_CX16 | CPUID_EXT_SSE41 |
> > +            CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
> > +            CPUID_EXT_POPCNT | CPUID_EXT_TSC_DEADLINE_TIMER |
> > +            CPUID_EXT_AES | CPUID_EXT_XSAVE | CPUID_EXT_RDRAND,
> > +        .features[FEAT_8000_0001_EDX] =
> > +            CPUID_EXT2_SYSCALL | CPUID_EXT2_NX | CPUID_EXT2_PDPE1GB |
> > +            CPUID_EXT2_RDTSCP | CPUID_EXT2_LM,
> > +        .features[FEAT_8000_0001_ECX] =
> > +            CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
> > +        .features[FEAT_7_0_EBX] =
> > +            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS |
> > +            CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_SMAP |
> > +            CPUID_7_0_EBX_CLFLUSHOPT | CPUID_7_0_EBX_SHA_NI,
> > +        .features[FEAT_7_0_EDX] =
> > +            CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_ARCH_CAPABILITIES |
> > +            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
> > +        /*
> > +         * 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 Atom Processor (Denverton)",
> > +    },
> >       {
> >           .name = "SnowRidge-Server",
> >           .level = 27,
> > --
> > 2.20.1
> > 
> > 
> 

-- 
Eduardo


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
  2019-07-17 18:38   ` Eduardo Habkost
@ 2019-07-18  1:56     ` Tao Xu
  2019-07-18  6:16       ` Xiaoyao Li
  0 siblings, 1 reply; 6+ messages in thread
From: Tao Xu @ 2019-07-18  1:56 UTC (permalink / raw)
  To: Eduardo Habkost; +Cc: qemu-devel@nongnu.org, Xiaoyao Li

On 7/18/2019 2:38 AM, Eduardo Habkost wrote:
> On Wed, Jul 17, 2019 at 01:39:01PM +0800, Tao Xu wrote:
>> Hi Eduardo,
>>
>> Could I ask a question about introducing a old CPU model? Maybe not so old
>> because it was launched in 2017. It is the former generation (Atom Server)
>> of Snowridge and if this cpu model be added, qemu may can migrate guest
>> between Denverton CPU and Snowridge CPU.
>>
>> I am wondering which way is more appropriate, because maybe there are a few
>> Denverton machines using old microcodes:
>>
>> 1. Just like this patch, introduce one version cpu cpu model.
>>
>> 2. Introduce multi versions of cpu model, cover old microcodes, may be 3
>> versions.
> 
> What exactly are the differences between the old and new
> microcodes?  Is it always possible to install a new microcode on
> machines that are not up to date?
> 
Denverton Machines with old microcodes didn't have 
CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_SPEC_CTRL_SSBD on host. But user 
can update their machine follow the links below:

SSBD:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html
https://access.redhat.com/articles/3436091

SPEC_CTRL:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html
https://access.redhat.com/articles/3436091


> Both options look good to me.  I think it's OK to just declare
> old microcode versions as not supported by QEMU, but I won't
> complain if you decide to add multiple versions.
> 
Thank you Eduardo, I prefer option 1, just this patch. I think because 
Denverton CPU model will not have compatibility issue and the machines 
with old microcode are very few.
>>
>> On 7/17/2019 12:57 PM, Tao Xu wrote:
>>> Denverton is the Atom Processor of Intel Harrisonville platform.
>>>
>>> For more information:
>>> https://ark.intel.com/content/www/us/en/ark/products/\
>>> codename/63508/denverton.html
>>>
>>> Signed-off-by: Tao Xu <tao3.xu@intel.com>
>>> ---
>>>
>>> Changes in v2:
>>>
>>>       - Renamed as Denverton instead of Denverton-Server, because there
>>>         is only server for Denverton
>>>       - Remove vmx from cpu model
>>> ---
>>>    target/i386/cpu.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 45 insertions(+)
>>>
>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>> index 805ce95247..38000dd975 100644
>>> --- a/target/i386/cpu.c
>>> +++ b/target/i386/cpu.c
>>> @@ -2471,6 +2471,51 @@ static X86CPUDefinition builtin_x86_defs[] = {
>>>            .xlevel = 0x80000008,
>>>            .model_id = "Intel Xeon Processor (Icelake)",
>>>        },
>>> +    {
>>> +        .name = "Denverton",
>>> +        .level = 21,
>>> +        .vendor = CPUID_VENDOR_INTEL,
>>> +        .family = 6,
>>> +        .model = 95,
>>> +        .stepping = 1,
>>> +        .features[FEAT_1_EDX] =
>>> +            CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE | CPUID_TSC |
>>> +            CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 | CPUID_APIC |
>>> +            CPUID_SEP | CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
>>> +            CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH | CPUID_MMX | CPUID_FXSR |
>>> +            CPUID_SSE | CPUID_SSE2,
>>> +        .features[FEAT_1_ECX] =
>>> +            CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
>>> +            CPUID_EXT_SSSE3 | CPUID_EXT_CX16 | CPUID_EXT_SSE41 |
>>> +            CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
>>> +            CPUID_EXT_POPCNT | CPUID_EXT_TSC_DEADLINE_TIMER |
>>> +            CPUID_EXT_AES | CPUID_EXT_XSAVE | CPUID_EXT_RDRAND,
>>> +        .features[FEAT_8000_0001_EDX] =
>>> +            CPUID_EXT2_SYSCALL | CPUID_EXT2_NX | CPUID_EXT2_PDPE1GB |
>>> +            CPUID_EXT2_RDTSCP | CPUID_EXT2_LM,
>>> +        .features[FEAT_8000_0001_ECX] =
>>> +            CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
>>> +        .features[FEAT_7_0_EBX] =
>>> +            CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS |
>>> +            CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_SMAP |
>>> +            CPUID_7_0_EBX_CLFLUSHOPT | CPUID_7_0_EBX_SHA_NI,
>>> +        .features[FEAT_7_0_EDX] =
>>> +            CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_ARCH_CAPABILITIES |
>>> +            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
>>> +        /*
>>> +         * 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 Atom Processor (Denverton)",
>>> +    },
>>>        {
>>>            .name = "SnowRidge-Server",
>>>            .level = 27,
>>> --
>>> 2.20.1
>>>
>>>
>>
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
  2019-07-18  1:56     ` Tao Xu
@ 2019-07-18  6:16       ` Xiaoyao Li
  2019-07-18  7:01         ` Tao Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Xiaoyao Li @ 2019-07-18  6:16 UTC (permalink / raw)
  To: Tao Xu, Eduardo Habkost; +Cc: qemu-devel@nongnu.org, Xiaoyao Li

On 7/18/2019 9:56 AM, Tao Xu wrote:
> On 7/18/2019 2:38 AM, Eduardo Habkost wrote:
>> On Wed, Jul 17, 2019 at 01:39:01PM +0800, Tao Xu wrote:
>>> Hi Eduardo,
>>>
>>> Could I ask a question about introducing a old CPU model? Maybe not 
>>> so old
>>> because it was launched in 2017. It is the former generation (Atom 
>>> Server)
>>> of Snowridge and if this cpu model be added, qemu may can migrate guest
>>> between Denverton CPU and Snowridge CPU.
>>>
>>> I am wondering which way is more appropriate, because maybe there are 
>>> a few
>>> Denverton machines using old microcodes:
>>>
>>> 1. Just like this patch, introduce one version cpu cpu model.
>>>
>>> 2. Introduce multi versions of cpu model, cover old microcodes, may be 3
>>> versions.
>>
>> What exactly are the differences between the old and new
>> microcodes?  Is it always possible to install a new microcode on
>> machines that are not up to date?
>>
> Denverton Machines with old microcodes didn't have 
> CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_SPEC_CTRL_SSBD on host. But user 
> can update their machine follow the links below:
> 
> SSBD:
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html 
> 
> https://access.redhat.com/articles/3436091
> 
> SPEC_CTRL:
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html 
> 
> https://access.redhat.com/articles/3436091
> 
> 
>> Both options look good to me.  I think it's OK to just declare
>> old microcode versions as not supported by QEMU, but I won't
>> complain if you decide to add multiple versions.
>>
> Thank you Eduardo, I prefer option 1, just this patch. I think because 
> Denverton CPU model will not have compatibility issue and the machines 
> with old microcode are very few.

Hi Tao,

This patch also define CPUID_7_0_EDX_ARCH_CAPABILITIES in 
features[FEAT_7_0_EDX], but there is no feature defined with 
.feature[FEAT_ARCH_CAPABILITIES] in this cpu model.
Do you miss some features enumerated by MSR_IA32_ARCH_CAPABILITIES in 
this cpu model? Otherwise it can just remove 
CPUID_7_0_EDX_ARCH_CAPABILITIES.

>>>
>>> On 7/17/2019 12:57 PM, Tao Xu wrote:
>>>> Denverton is the Atom Processor of Intel Harrisonville platform.
>>>> +        .features[FEAT_7_0_EDX] =
>>>> +            CPUID_7_0_EDX_SPEC_CTRL | 
>>>> CPUID_7_0_EDX_ARCH_CAPABILITIES |
>>>> +            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
>>>> +        /*
>>>> +         * 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 Atom Processor (Denverton)",
>>>> +    },
>>>>        {
>>>>            .name = "SnowRidge-Server",
>>>>            .level = 27,
>>>> -- 
>>>> 2.20.1
>>>>
>>>>
>>>
>>
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model
  2019-07-18  6:16       ` Xiaoyao Li
@ 2019-07-18  7:01         ` Tao Xu
  0 siblings, 0 replies; 6+ messages in thread
From: Tao Xu @ 2019-07-18  7:01 UTC (permalink / raw)
  To: Xiaoyao Li, Eduardo Habkost; +Cc: qemu-devel@nongnu.org, Xiaoyao Li

On 7/18/2019 2:16 PM, Xiaoyao Li wrote:
> On 7/18/2019 9:56 AM, Tao Xu wrote:
>> On 7/18/2019 2:38 AM, Eduardo Habkost wrote:
>>> On Wed, Jul 17, 2019 at 01:39:01PM +0800, Tao Xu wrote:
>>>> Hi Eduardo,
>>>>
>>>> Could I ask a question about introducing a old CPU model? Maybe not 
>>>> so old
>>>> because it was launched in 2017. It is the former generation (Atom 
>>>> Server)
>>>> of Snowridge and if this cpu model be added, qemu may can migrate guest
>>>> between Denverton CPU and Snowridge CPU.
>>>>
>>>> I am wondering which way is more appropriate, because maybe there 
>>>> are a few
>>>> Denverton machines using old microcodes:
>>>>
>>>> 1. Just like this patch, introduce one version cpu cpu model.
>>>>
>>>> 2. Introduce multi versions of cpu model, cover old microcodes, may 
>>>> be 3
>>>> versions.
>>>
>>> What exactly are the differences between the old and new
>>> microcodes?  Is it always possible to install a new microcode on
>>> machines that are not up to date?
>>>
>> Denverton Machines with old microcodes didn't have 
>> CPUID_7_0_EDX_SPEC_CTRL | CPUID_7_0_EDX_SPEC_CTRL_SSBD on host. But 
>> user can update their machine follow the links below:
>>
>> SSBD:
>> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html 
>>
>> https://access.redhat.com/articles/3436091
>>
>> SPEC_CTRL:
>> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html 
>>
>> https://access.redhat.com/articles/3436091
>>
>>
>>> Both options look good to me.  I think it's OK to just declare
>>> old microcode versions as not supported by QEMU, but I won't
>>> complain if you decide to add multiple versions.
>>>
>> Thank you Eduardo, I prefer option 1, just this patch. I think because 
>> Denverton CPU model will not have compatibility issue and the machines 
>> with old microcode are very few.
> 
> Hi Tao,
> 
> This patch also define CPUID_7_0_EDX_ARCH_CAPABILITIES in 
> features[FEAT_7_0_EDX], but there is no feature defined with 
> .feature[FEAT_ARCH_CAPABILITIES] in this cpu model.
> Do you miss some features enumerated by MSR_IA32_ARCH_CAPABILITIES in 
> this cpu model? Otherwise it can just remove 
> CPUID_7_0_EDX_ARCH_CAPABILITIES.
> 

OK, When I RDMSR 0x10a in a Denverton machine with latest microcode, I 
get 9. So I plan to add "rdctl-no" and "skip-l1dfl-vmentry" in next version.
>>>>
>>>> On 7/17/2019 12:57 PM, Tao Xu wrote:
>>>>> Denverton is the Atom Processor of Intel Harrisonville platform.
>>>>> +        .features[FEAT_7_0_EDX] =
>>>>> +            CPUID_7_0_EDX_SPEC_CTRL | 
>>>>> CPUID_7_0_EDX_ARCH_CAPABILITIES |
>>>>> +            CPUID_7_0_EDX_SPEC_CTRL_SSBD,
>>>>> +        /*
>>>>> +         * 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 Atom Processor (Denverton)",
>>>>> +    },
>>>>>        {
>>>>>            .name = "SnowRidge-Server",
>>>>>            .level = 27,
>>>>> -- 
>>>>> 2.20.1
>>>>>
>>>>>
>>>>
>>>
>>
>>



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-07-18  7:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-17  4:57 [Qemu-devel] [PATCH v2] target/i386: Introduce Denverton CPU model Tao Xu
2019-07-17  5:39 ` Tao Xu
2019-07-17 18:38   ` Eduardo Habkost
2019-07-18  1:56     ` Tao Xu
2019-07-18  6:16       ` Xiaoyao Li
2019-07-18  7:01         ` Tao Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).