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...@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