| Message ID | 20230616032311.19137-7-tao1.su@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add new CPU model EmeraldRapids and GraniteRapids | expand |
On Fri, 16 Jun 2023 11:23:10 +0800 Tao Su <tao1.su@linux.intel.com> wrote: > From: Qian Wen <qian.wen@intel.com> > > Emerald Rapids (EMR) is the next generation of Xeon server processor > after Sapphire Rapids (SPR). > > Currently, regarding the feature set that can be exposed to guest, there > isn't any one new comparing with SPR cpu model, except that EMR has a > different model number. > > Though it's practicable to define EMR as an alias of a new version of > SPR by only updating the model number and model name, it loses the > flexibility when new version of EMR cpu model are needed for adding new > features (that hasn't virtalized/supported by KVM yet). Which begs a question, why do we need EMR model (or alias) at all if it's the same as SPR at the moment. Make new features supported 1st and only then introduce a new CPU model. > > So just add EMR as a standalone cpu model. > > Signed-off-by: Qian Wen <qian.wen@intel.com> > Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> > Signed-off-by: Tao Su <tao1.su@linux.intel.com> > --- > Changes to original patch > (https://lore.kernel.org/qemu-devel/20230515025308.1050277-1-qian.wen@intel.com/) > > - Add MSR_ARCH_CAP_SBDR_SSDP_NO, MSR_ARCH_CAP_FBSDP_NO and > MSR_ARCH_CAP_PSDP_NO > --- > target/i386/cpu.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 127 insertions(+) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index f84fd20bb1..7faf6dfaee 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -3866,6 +3866,133 @@ static const X86CPUDefinition builtin_x86_defs[] = { > { /* end of list */ } > } > }, > + { > + .name = "EmeraldRapids", > + .level = 0x20, > + .vendor = CPUID_VENDOR_INTEL, > + .family = 6, > + .model = 207, > + .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_SSSE3 | > + CPUID_EXT_FMA | CPUID_EXT_CX16 | CPUID_EXT_PCID | 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_AVX | CPUID_EXT_F16C | 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_ABM | CPUID_EXT3_3DNOWPREFETCH, > + .features[FEAT_8000_0008_EBX] = > + CPUID_8000_0008_EBX_WBNOINVD, > + .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_AVX512F | CPUID_7_0_EBX_AVX512DQ | > + CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX | CPUID_7_0_EBX_SMAP | > + CPUID_7_0_EBX_AVX512IFMA | CPUID_7_0_EBX_CLFLUSHOPT | > + CPUID_7_0_EBX_CLWB | CPUID_7_0_EBX_AVX512CD | CPUID_7_0_EBX_SHA_NI | > + CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512VL, > + .features[FEAT_7_0_ECX] = > + CPUID_7_0_ECX_AVX512_VBMI | CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_PKU | > + CPUID_7_0_ECX_AVX512_VBMI2 | CPUID_7_0_ECX_GFNI | > + CPUID_7_0_ECX_VAES | CPUID_7_0_ECX_VPCLMULQDQ | > + CPUID_7_0_ECX_AVX512VNNI | CPUID_7_0_ECX_AVX512BITALG | > + CPUID_7_0_ECX_AVX512_VPOPCNTDQ | CPUID_7_0_ECX_LA57 | > + CPUID_7_0_ECX_RDPID | CPUID_7_0_ECX_BUS_LOCK_DETECT, > + .features[FEAT_7_0_EDX] = > + CPUID_7_0_EDX_FSRM | CPUID_7_0_EDX_SERIALIZE | > + CPUID_7_0_EDX_TSX_LDTRK | CPUID_7_0_EDX_AMX_BF16 | > + CPUID_7_0_EDX_AVX512_FP16 | CPUID_7_0_EDX_AMX_TILE | > + CPUID_7_0_EDX_AMX_INT8 | CPUID_7_0_EDX_SPEC_CTRL | > + CPUID_7_0_EDX_ARCH_CAPABILITIES | CPUID_7_0_EDX_SPEC_CTRL_SSBD, > + .features[FEAT_ARCH_CAPABILITIES] = > + MSR_ARCH_CAP_RDCL_NO | MSR_ARCH_CAP_IBRS_ALL | > + MSR_ARCH_CAP_SKIP_L1DFL_VMENTRY | MSR_ARCH_CAP_MDS_NO | > + MSR_ARCH_CAP_PSCHANGE_MC_NO | MSR_ARCH_CAP_TAA_NO | > + MSR_ARCH_CAP_SBDR_SSDP_NO | MSR_ARCH_CAP_FBSDP_NO | > + MSR_ARCH_CAP_PSDP_NO, > + .features[FEAT_XSAVE] = > + CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC | > + CPUID_XSAVE_XGETBV1 | CPUID_XSAVE_XSAVES | CPUID_D_1_EAX_XFD, > + .features[FEAT_6_EAX] = > + CPUID_6_EAX_ARAT, > + .features[FEAT_7_1_EAX] = > + CPUID_7_1_EAX_AVX_VNNI | CPUID_7_1_EAX_AVX512_BF16 | > + CPUID_7_1_EAX_FZRM | CPUID_7_1_EAX_FSRS | CPUID_7_1_EAX_FSRC, > + .features[FEAT_VMX_BASIC] = > + MSR_VMX_BASIC_INS_OUTS | MSR_VMX_BASIC_TRUE_CTLS, > + .features[FEAT_VMX_ENTRY_CTLS] = > + VMX_VM_ENTRY_LOAD_DEBUG_CONTROLS | VMX_VM_ENTRY_IA32E_MODE | > + VMX_VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL | > + VMX_VM_ENTRY_LOAD_IA32_PAT | VMX_VM_ENTRY_LOAD_IA32_EFER, > + .features[FEAT_VMX_EPT_VPID_CAPS] = > + MSR_VMX_EPT_EXECONLY | > + MSR_VMX_EPT_PAGE_WALK_LENGTH_4 | MSR_VMX_EPT_PAGE_WALK_LENGTH_5 | > + MSR_VMX_EPT_WB | MSR_VMX_EPT_2MB | MSR_VMX_EPT_1GB | > + MSR_VMX_EPT_INVEPT | MSR_VMX_EPT_AD_BITS | > + MSR_VMX_EPT_INVEPT_SINGLE_CONTEXT | MSR_VMX_EPT_INVEPT_ALL_CONTEXT | > + MSR_VMX_EPT_INVVPID | MSR_VMX_EPT_INVVPID_SINGLE_ADDR | > + MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT | > + MSR_VMX_EPT_INVVPID_ALL_CONTEXT | > + MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT_NOGLOBALS, > + .features[FEAT_VMX_EXIT_CTLS] = > + VMX_VM_EXIT_SAVE_DEBUG_CONTROLS | > + VMX_VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL | > + VMX_VM_EXIT_ACK_INTR_ON_EXIT | VMX_VM_EXIT_SAVE_IA32_PAT | > + VMX_VM_EXIT_LOAD_IA32_PAT | VMX_VM_EXIT_SAVE_IA32_EFER | > + VMX_VM_EXIT_LOAD_IA32_EFER | VMX_VM_EXIT_SAVE_VMX_PREEMPTION_TIMER, > + .features[FEAT_VMX_MISC] = > + MSR_VMX_MISC_STORE_LMA | MSR_VMX_MISC_ACTIVITY_HLT | > + MSR_VMX_MISC_VMWRITE_VMEXIT, > + .features[FEAT_VMX_PINBASED_CTLS] = > + VMX_PIN_BASED_EXT_INTR_MASK | VMX_PIN_BASED_NMI_EXITING | > + VMX_PIN_BASED_VIRTUAL_NMIS | VMX_PIN_BASED_VMX_PREEMPTION_TIMER | > + VMX_PIN_BASED_POSTED_INTR, > + .features[FEAT_VMX_PROCBASED_CTLS] = > + VMX_CPU_BASED_VIRTUAL_INTR_PENDING | > + VMX_CPU_BASED_USE_TSC_OFFSETING | VMX_CPU_BASED_HLT_EXITING | > + VMX_CPU_BASED_INVLPG_EXITING | VMX_CPU_BASED_MWAIT_EXITING | > + VMX_CPU_BASED_RDPMC_EXITING | VMX_CPU_BASED_RDTSC_EXITING | > + VMX_CPU_BASED_CR3_LOAD_EXITING | VMX_CPU_BASED_CR3_STORE_EXITING | > + VMX_CPU_BASED_CR8_LOAD_EXITING | VMX_CPU_BASED_CR8_STORE_EXITING | > + VMX_CPU_BASED_TPR_SHADOW | VMX_CPU_BASED_VIRTUAL_NMI_PENDING | > + VMX_CPU_BASED_MOV_DR_EXITING | VMX_CPU_BASED_UNCOND_IO_EXITING | > + VMX_CPU_BASED_USE_IO_BITMAPS | VMX_CPU_BASED_MONITOR_TRAP_FLAG | > + VMX_CPU_BASED_USE_MSR_BITMAPS | VMX_CPU_BASED_MONITOR_EXITING | > + VMX_CPU_BASED_PAUSE_EXITING | > + VMX_CPU_BASED_ACTIVATE_SECONDARY_CONTROLS, > + .features[FEAT_VMX_SECONDARY_CTLS] = > + VMX_SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES | > + VMX_SECONDARY_EXEC_ENABLE_EPT | VMX_SECONDARY_EXEC_DESC | > + VMX_SECONDARY_EXEC_RDTSCP | > + VMX_SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE | > + VMX_SECONDARY_EXEC_ENABLE_VPID | VMX_SECONDARY_EXEC_WBINVD_EXITING | > + VMX_SECONDARY_EXEC_UNRESTRICTED_GUEST | > + VMX_SECONDARY_EXEC_APIC_REGISTER_VIRT | > + VMX_SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY | > + VMX_SECONDARY_EXEC_RDRAND_EXITING | > + VMX_SECONDARY_EXEC_ENABLE_INVPCID | > + VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS | > + VMX_SECONDARY_EXEC_RDSEED_EXITING | VMX_SECONDARY_EXEC_ENABLE_PML | > + VMX_SECONDARY_EXEC_XSAVES, > + .features[FEAT_VMX_VMFUNC] = > + MSR_VMX_VMFUNC_EPT_SWITCHING, > + .xlevel = 0x80000008, > + .model_id = "Intel Xeon Processor (EmeraldRapids)", > + .versions = (X86CPUVersionDefinition[]) { > + { .version = 1 }, > + { /* end of list */ }, > + }, > + }, > { > .name = "Denverton", > .level = 21,
On 6/26/2023 8:56 PM, Igor Mammedov wrote: > On Fri, 16 Jun 2023 11:23:10 +0800 > Tao Su<tao1.su@linux.intel.com> wrote: > >> From: Qian Wen<qian.wen@intel.com> >> >> Emerald Rapids (EMR) is the next generation of Xeon server processor >> after Sapphire Rapids (SPR). >> >> Currently, regarding the feature set that can be exposed to guest, there >> isn't any one new comparing with SPR cpu model, except that EMR has a >> different model number. >> >> Though it's practicable to define EMR as an alias of a new version of >> SPR by only updating the model number and model name, it loses the >> flexibility when new version of EMR cpu model are needed for adding new >> features (that hasn't virtalized/supported by KVM yet). > Which begs a question, why do we need EMR model (or alias) at all > if it's the same as SPR at the moment. > > Make new features supported 1st and only then introduce a new CPU model. > Even if no new feature (that can be virtualized and exposed to guest) in EMR compared to SPR in the end, I think it still makes sense to provide a dedicated EMR CPU model in QEMU. Because 1) User will know EMR, Intel's next generation of Xeon after SRP, is supported by QEMU, via -cpu ?/ -cpu help; 2) It's convenient for user to create an EMR VM. People may not care that much what the difference between "-cpu SapphireRapids" with "-cpu EmeraldRapids", while they do want to create an VM which shows the CPU is EmeraldRapids.
On Tue, 27 Jun 2023 13:54:23 +0800 Xiaoyao Li <xiaoyao.li@intel.com> wrote: > On 6/26/2023 8:56 PM, Igor Mammedov wrote: > > On Fri, 16 Jun 2023 11:23:10 +0800 > > Tao Su<tao1.su@linux.intel.com> wrote: > > > >> From: Qian Wen<qian.wen@intel.com> > >> > >> Emerald Rapids (EMR) is the next generation of Xeon server processor > >> after Sapphire Rapids (SPR). > >> > >> Currently, regarding the feature set that can be exposed to guest, there > >> isn't any one new comparing with SPR cpu model, except that EMR has a > >> different model number. > >> > >> Though it's practicable to define EMR as an alias of a new version of > >> SPR by only updating the model number and model name, it loses the > >> flexibility when new version of EMR cpu model are needed for adding new > >> features (that hasn't virtalized/supported by KVM yet). > > Which begs a question, why do we need EMR model (or alias) at all > > if it's the same as SPR at the moment. > > > > Make new features supported 1st and only then introduce a new CPU model. > > > > Even if no new feature (that can be virtualized and exposed to guest) in > EMR compared to SPR in the end, I think it still makes sense to provide > a dedicated EMR CPU model in QEMU. Because > 1) User will know EMR, Intel's next generation of Xeon after SRP, is > supported by QEMU, via -cpu ?/ -cpu help; I don't see any benefits in misleading user by showing EMR model which is nothing else but SPR one. On negative side you would increase maintenance burden by introducing extra versions of CPU model later. Which by itself is abusing versioning, mainly used for fixing CPU bugs, by using it for adding new features. > 2) It's convenient for user to create an EMR VM. People may not care > that much what the difference between "-cpu SapphireRapids" with "-cpu > EmeraldRapids", while they do want to create an VM which shows the CPU > is EmeraldRapids. > My guess would be is that you need guest to show EMR for developing EMR features/guest bringup, in that case do it in your fork, and once support is actually ready publish completed patches for it. To exaggerate you reasoning further, we should create CPU models for all future planned Intel/AMD CPU as a one of currently existing in QEMU right now and then sometime in future implement features that actually make those models what they should be. It's downright confusing for user, so I'd object to this approach.
On 6/27/2023 4:49 PM, Igor Mammedov wrote: > On Tue, 27 Jun 2023 13:54:23 +0800 > Xiaoyao Li <xiaoyao.li@intel.com> wrote: > >> On 6/26/2023 8:56 PM, Igor Mammedov wrote: >>> On Fri, 16 Jun 2023 11:23:10 +0800 >>> Tao Su<tao1.su@linux.intel.com> wrote: >>> >>>> From: Qian Wen<qian.wen@intel.com> >>>> >>>> Emerald Rapids (EMR) is the next generation of Xeon server processor >>>> after Sapphire Rapids (SPR). >>>> >>>> Currently, regarding the feature set that can be exposed to guest, there >>>> isn't any one new comparing with SPR cpu model, except that EMR has a >>>> different model number. >>>> >>>> Though it's practicable to define EMR as an alias of a new version of >>>> SPR by only updating the model number and model name, it loses the >>>> flexibility when new version of EMR cpu model are needed for adding new >>>> features (that hasn't virtalized/supported by KVM yet). >>> Which begs a question, why do we need EMR model (or alias) at all >>> if it's the same as SPR at the moment. >>> >>> Make new features supported 1st and only then introduce a new CPU model. >>> >> >> Even if no new feature (that can be virtualized and exposed to guest) in >> EMR compared to SPR in the end, I think it still makes sense to provide >> a dedicated EMR CPU model in QEMU. Because >> 1) User will know EMR, Intel's next generation of Xeon after SRP, is >> supported by QEMU, via -cpu ?/ -cpu help; > > I don't see any benefits in misleading user by showing EMR model which is > nothing else but SPR one. > On negative side you would increase maintenance burden by introducing > extra versions of CPU model later. Which by itself is abusing versioning, > mainly used for fixing CPU bugs, by using it for adding new features. > >> 2) It's convenient for user to create an EMR VM. People may not care >> that much what the difference between "-cpu SapphireRapids" with "-cpu >> EmeraldRapids", while they do want to create an VM which shows the CPU >> is EmeraldRapids. >> > My guess would be is that you need guest to show EMR for developing EMR > features/guest bringup, in that case do it in your fork, and once > support is actually ready publish completed patches for it. No. I meant for CSPs who want to provide an EMR virtual machine to their customers, or lab admin provides an EMR (virtual) machine to its user. Without a dedicated EmeraldRapids cpu model provided by QEMU, they need to use something like -cpu SapphireRapids,model=207,model-id="Intel Xeon Processor (EmeraldRapids)" It's likely that no difference in supported features between SPR cpu model and EMR cpu model in the end. If so, will QEMU choose to provide a dedicated CPU model for EMR? or just document somewhere to QEMU users that "if you want to create an virtual machine with EMR cpu model, please go with SPR cpu model while changing it's model number to EMR's 207 and changing model-id to tell EmeraldRapids" ? > To exaggerate you reasoning further, we should create CPU models for > all future planned Intel/AMD CPU as a one of currently existing in > QEMU right now and then sometime in future implement features that > actually make those models what they should be. No, it's not the purpose. In fact, we're not adding an temporary EMR cpu model while planing to complement it in the future. Instead, we are adding an official EMR cpu model. The fact is, in terms of the features that are virtualizable and can be exposed to guest, there is no difference between SPR and EMR. This comes to a basic question：Will QEMU provide a EMR cpu model even if no difference to SPR cpu model except the model number? > It's downright confusing for user, so I'd object to this approach. >
On Tue, Jun 27, 2023 at 07:25:21PM +0800, Xiaoyao Li wrote: > On 6/27/2023 4:49 PM, Igor Mammedov wrote: > > On Tue, 27 Jun 2023 13:54:23 +0800 > > Xiaoyao Li <xiaoyao.li@intel.com> wrote: > > > > > On 6/26/2023 8:56 PM, Igor Mammedov wrote: > > > > On Fri, 16 Jun 2023 11:23:10 +0800 > > > > Tao Su<tao1.su@linux.intel.com> wrote: > > > > > From: Qian Wen<qian.wen@intel.com> > > > > > > > > > > Emerald Rapids (EMR) is the next generation of Xeon server processor > > > > > after Sapphire Rapids (SPR). > > > > > > > > > > Currently, regarding the feature set that can be exposed to guest, there > > > > > isn't any one new comparing with SPR cpu model, except that EMR has a > > > > > different model number. > > > > > > > > > > Though it's practicable to define EMR as an alias of a new version of > > > > > SPR by only updating the model number and model name, it loses the > > > > > flexibility when new version of EMR cpu model are needed for adding new > > > > > features (that hasn't virtalized/supported by KVM yet). > > > > Which begs a question, why do we need EMR model (or alias) at all > > > > if it's the same as SPR at the moment. > > > > > > > > Make new features supported 1st and only then introduce a new CPU model. > > > > > > Even if no new feature (that can be virtualized and exposed to guest) in > > > EMR compared to SPR in the end, I think it still makes sense to provide > > > a dedicated EMR CPU model in QEMU. Because > > > 1) User will know EMR, Intel's next generation of Xeon after SRP, is > > > supported by QEMU, via -cpu ?/ -cpu help; > > > > I don't see any benefits in misleading user by showing EMR model which is > > nothing else but SPR one. > > On negative side you would increase maintenance burden by introducing > > extra versions of CPU model later. Which by itself is abusing versioning, > > mainly used for fixing CPU bugs, by using it for adding new features. > > > > > 2) It's convenient for user to create an EMR VM. People may not care > > > that much what the difference between "-cpu SapphireRapids" with "-cpu > > > EmeraldRapids", while they do want to create an VM which shows the CPU > > > is EmeraldRapids. > > > > > My guess would be is that you need guest to show EMR for developing EMR > > features/guest bringup, in that case do it in your fork, and once > > support is actually ready publish completed patches for it. > > No. I meant for CSPs who want to provide an EMR virtual machine to their > customers, or lab admin provides an EMR (virtual) machine to its user. > > Without a dedicated EmeraldRapids cpu model provided by QEMU, they need to > use something like > > -cpu SapphireRapids,model=207,model-id="Intel Xeon Processor > (EmeraldRapids)" > > It's likely that no difference in supported features between SPR cpu model > and EMR cpu model in the end. If so, will QEMU choose to provide a dedicated > CPU model for EMR? or just document somewhere to QEMU users that "if you > want to create an virtual machine with EMR cpu model, please go with SPR cpu > model while changing it's model number to EMR's 207 and changing model-id to > tell EmeraldRapids" ? I think QEMU's answer would be to not bother trying todo this at all, just expose '-cpu SapphireRapids', because there's no functional benefit to overriding the model ID, when all the CPUID features are identical. Those who have the guest to see the *perfect* functional match of the host still have '-cpu host' available. The named CPU models are for the case where we want a rough approximation for a CPU generation available, to easy migration across mixed CPU clusters. Given the intent is to have a rough approximation, there's no compelling reason to add an exact EmeraldRapids named CPU. > > To exaggerate you reasoning further, we should create CPU models for > > all future planned Intel/AMD CPU as a one of currently existing in > > QEMU right now and then sometime in future implement features that > > actually make those models what they should be. > > No, it's not the purpose. In fact, we're not adding an temporary EMR cpu > model while planing to complement it in the future. Instead, we are adding > an official EMR cpu model. The fact is, in terms of the features that are > virtualizable and can be exposed to guest, there is no difference between > SPR and EMR. > > This comes to a basic question：Will QEMU provide a EMR cpu model even if no > difference to SPR cpu model except the model number? Historically we have generally only added new CPU models if there was a feature difference. We've skipped adding many of the Intel models that didn't add bring new features, on the basis that there is no compelling functional need to have them. With regards, Daniel
diff --git a/target/i386/cpu.c b/target/i386/cpu.c index f84fd20bb1..7faf6dfaee 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -3866,6 +3866,133 @@ static const X86CPUDefinition builtin_x86_defs[] = { { /* end of list */ } } }, + { + .name = "EmeraldRapids", + .level = 0x20, + .vendor = CPUID_VENDOR_INTEL, + .family = 6, + .model = 207, + .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_SSSE3 | + CPUID_EXT_FMA | CPUID_EXT_CX16 | CPUID_EXT_PCID | 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_AVX | CPUID_EXT_F16C | 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_ABM | CPUID_EXT3_3DNOWPREFETCH, + .features[FEAT_8000_0008_EBX] = + CPUID_8000_0008_EBX_WBNOINVD, + .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_AVX512F | CPUID_7_0_EBX_AVX512DQ | + CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX | CPUID_7_0_EBX_SMAP | + CPUID_7_0_EBX_AVX512IFMA | CPUID_7_0_EBX_CLFLUSHOPT | + CPUID_7_0_EBX_CLWB | CPUID_7_0_EBX_AVX512CD | CPUID_7_0_EBX_SHA_NI | + CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512VL, + .features[FEAT_7_0_ECX] = + CPUID_7_0_ECX_AVX512_VBMI | CPUID_7_0_ECX_UMIP | CPUID_7_0_ECX_PKU | + CPUID_7_0_ECX_AVX512_VBMI2 | CPUID_7_0_ECX_GFNI | + CPUID_7_0_ECX_VAES | CPUID_7_0_ECX_VPCLMULQDQ | + CPUID_7_0_ECX_AVX512VNNI | CPUID_7_0_ECX_AVX512BITALG | + CPUID_7_0_ECX_AVX512_VPOPCNTDQ | CPUID_7_0_ECX_LA57 | + CPUID_7_0_ECX_RDPID | CPUID_7_0_ECX_BUS_LOCK_DETECT, + .features[FEAT_7_0_EDX] = + CPUID_7_0_EDX_FSRM | CPUID_7_0_EDX_SERIALIZE | + CPUID_7_0_EDX_TSX_LDTRK | CPUID_7_0_EDX_AMX_BF16 | + CPUID_7_0_EDX_AVX512_FP16 | CPUID_7_0_EDX_AMX_TILE | + CPUID_7_0_EDX_AMX_INT8 | CPUID_7_0_EDX_SPEC_CTRL | + CPUID_7_0_EDX_ARCH_CAPABILITIES | CPUID_7_0_EDX_SPEC_CTRL_SSBD, + .features[FEAT_ARCH_CAPABILITIES] = + MSR_ARCH_CAP_RDCL_NO | MSR_ARCH_CAP_IBRS_ALL | + MSR_ARCH_CAP_SKIP_L1DFL_VMENTRY | MSR_ARCH_CAP_MDS_NO | + MSR_ARCH_CAP_PSCHANGE_MC_NO | MSR_ARCH_CAP_TAA_NO | + MSR_ARCH_CAP_SBDR_SSDP_NO | MSR_ARCH_CAP_FBSDP_NO | + MSR_ARCH_CAP_PSDP_NO, + .features[FEAT_XSAVE] = + CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC | + CPUID_XSAVE_XGETBV1 | CPUID_XSAVE_XSAVES | CPUID_D_1_EAX_XFD, + .features[FEAT_6_EAX] = + CPUID_6_EAX_ARAT, + .features[FEAT_7_1_EAX] = + CPUID_7_1_EAX_AVX_VNNI | CPUID_7_1_EAX_AVX512_BF16 | + CPUID_7_1_EAX_FZRM | CPUID_7_1_EAX_FSRS | CPUID_7_1_EAX_FSRC, + .features[FEAT_VMX_BASIC] = + MSR_VMX_BASIC_INS_OUTS | MSR_VMX_BASIC_TRUE_CTLS, + .features[FEAT_VMX_ENTRY_CTLS] = + VMX_VM_ENTRY_LOAD_DEBUG_CONTROLS | VMX_VM_ENTRY_IA32E_MODE | + VMX_VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL | + VMX_VM_ENTRY_LOAD_IA32_PAT | VMX_VM_ENTRY_LOAD_IA32_EFER, + .features[FEAT_VMX_EPT_VPID_CAPS] = + MSR_VMX_EPT_EXECONLY | + MSR_VMX_EPT_PAGE_WALK_LENGTH_4 | MSR_VMX_EPT_PAGE_WALK_LENGTH_5 | + MSR_VMX_EPT_WB | MSR_VMX_EPT_2MB | MSR_VMX_EPT_1GB | + MSR_VMX_EPT_INVEPT | MSR_VMX_EPT_AD_BITS | + MSR_VMX_EPT_INVEPT_SINGLE_CONTEXT | MSR_VMX_EPT_INVEPT_ALL_CONTEXT | + MSR_VMX_EPT_INVVPID | MSR_VMX_EPT_INVVPID_SINGLE_ADDR | + MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT | + MSR_VMX_EPT_INVVPID_ALL_CONTEXT | + MSR_VMX_EPT_INVVPID_SINGLE_CONTEXT_NOGLOBALS, + .features[FEAT_VMX_EXIT_CTLS] = + VMX_VM_EXIT_SAVE_DEBUG_CONTROLS | + VMX_VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL | + VMX_VM_EXIT_ACK_INTR_ON_EXIT | VMX_VM_EXIT_SAVE_IA32_PAT | + VMX_VM_EXIT_LOAD_IA32_PAT | VMX_VM_EXIT_SAVE_IA32_EFER | + VMX_VM_EXIT_LOAD_IA32_EFER | VMX_VM_EXIT_SAVE_VMX_PREEMPTION_TIMER, + .features[FEAT_VMX_MISC] = + MSR_VMX_MISC_STORE_LMA | MSR_VMX_MISC_ACTIVITY_HLT | + MSR_VMX_MISC_VMWRITE_VMEXIT, + .features[FEAT_VMX_PINBASED_CTLS] = + VMX_PIN_BASED_EXT_INTR_MASK | VMX_PIN_BASED_NMI_EXITING | + VMX_PIN_BASED_VIRTUAL_NMIS | VMX_PIN_BASED_VMX_PREEMPTION_TIMER | + VMX_PIN_BASED_POSTED_INTR, + .features[FEAT_VMX_PROCBASED_CTLS] = + VMX_CPU_BASED_VIRTUAL_INTR_PENDING | + VMX_CPU_BASED_USE_TSC_OFFSETING | VMX_CPU_BASED_HLT_EXITING | + VMX_CPU_BASED_INVLPG_EXITING | VMX_CPU_BASED_MWAIT_EXITING | + VMX_CPU_BASED_RDPMC_EXITING | VMX_CPU_BASED_RDTSC_EXITING | + VMX_CPU_BASED_CR3_LOAD_EXITING | VMX_CPU_BASED_CR3_STORE_EXITING | + VMX_CPU_BASED_CR8_LOAD_EXITING | VMX_CPU_BASED_CR8_STORE_EXITING | + VMX_CPU_BASED_TPR_SHADOW | VMX_CPU_BASED_VIRTUAL_NMI_PENDING | + VMX_CPU_BASED_MOV_DR_EXITING | VMX_CPU_BASED_UNCOND_IO_EXITING | + VMX_CPU_BASED_USE_IO_BITMAPS | VMX_CPU_BASED_MONITOR_TRAP_FLAG | + VMX_CPU_BASED_USE_MSR_BITMAPS | VMX_CPU_BASED_MONITOR_EXITING | + VMX_CPU_BASED_PAUSE_EXITING | + VMX_CPU_BASED_ACTIVATE_SECONDARY_CONTROLS, + .features[FEAT_VMX_SECONDARY_CTLS] = + VMX_SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES | + VMX_SECONDARY_EXEC_ENABLE_EPT | VMX_SECONDARY_EXEC_DESC | + VMX_SECONDARY_EXEC_RDTSCP | + VMX_SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE | + VMX_SECONDARY_EXEC_ENABLE_VPID | VMX_SECONDARY_EXEC_WBINVD_EXITING | + VMX_SECONDARY_EXEC_UNRESTRICTED_GUEST | + VMX_SECONDARY_EXEC_APIC_REGISTER_VIRT | + VMX_SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY | + VMX_SECONDARY_EXEC_RDRAND_EXITING | + VMX_SECONDARY_EXEC_ENABLE_INVPCID | + VMX_SECONDARY_EXEC_ENABLE_VMFUNC | VMX_SECONDARY_EXEC_SHADOW_VMCS | + VMX_SECONDARY_EXEC_RDSEED_EXITING | VMX_SECONDARY_EXEC_ENABLE_PML | + VMX_SECONDARY_EXEC_XSAVES, + .features[FEAT_VMX_VMFUNC] = + MSR_VMX_VMFUNC_EPT_SWITCHING, + .xlevel = 0x80000008, + .model_id = "Intel Xeon Processor (EmeraldRapids)", + .versions = (X86CPUVersionDefinition[]) { + { .version = 1 }, + { /* end of list */ }, + }, + }, { .name = "Denverton", .level = 21,