| Message ID | 20180212153715.87555-6-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Feb 12, 2018 at 09:36:52AM -0600, Brijesh Singh wrote: > AMD EPYC processors support memory encryption feature. The feature > is reported through CPUID 8000_001F[EAX]. > > Fn8000_001F [EAX]: > Bit 0 Secure Memory Encryption (SME) supported > Bit 1 Secure Encrypted Virtualization (SEV) supported > Bit 2 Page flush MSR supported > Bit 3 Ecrypted State (SEV-ES) support > > when memory encryption feature is reported, CPUID 8000_001F[EBX] should > provide additional information regarding the feature (such as which page > table bit is used to mark pages as encrypted etc). The information in EBX > and ECX may vary from one family to another hence we use the host cpuid > to populate the EBX information. > > The details for memory encryption CPUID is available in AMD APM > (https://support.amd.com/TechDocs/24594.pdf) Section E.4.17 > > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Richard Henderson <rth@twiddle.net> > Cc: Eduardo Habkost <ehabkost@redhat.com> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > --- > target/i386/cpu.c | 36 ++++++++++++++++++++++++++++++++++++ > target/i386/cpu.h | 3 +++ > 2 files changed, 39 insertions(+) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index b5e431e769da..475d98a44880 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -235,6 +235,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1, > #define TCG_EXT4_FEATURES 0 > #define TCG_SVM_FEATURES 0 > #define TCG_KVM_FEATURES 0 > +#define TCG_MEM_ENCRYPT_FEATURES 0 > #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \ > CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \ > CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT | \ > @@ -546,6 +547,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { > .cpuid_reg = R_EDX, > .tcg_features = ~0U, > }, > + [FEAT_MEM_ENCRYPT] = { > + .feat_names = { > + NULL, "sev", NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + NULL, NULL, NULL, NULL, > + }, > + .cpuid_eax = 0x8000001F, .cpuid_reg = R_EAX, > + .tcg_features = TCG_MEM_ENCRYPT_FEATURES, > + } What should happen if "-cpu ...,+sev" is used without the appropriate SEV configuration on the command-line? > }; > > typedef struct X86RegisterInfo32 { > @@ -1966,6 +1981,9 @@ static X86CPUDefinition builtin_x86_defs[] = { > CPUID_XSAVE_XGETBV1, > .features[FEAT_6_EAX] = > CPUID_6_EAX_ARAT, > + /* Missing: SEV_ES */ > + .features[FEAT_MEM_ENCRYPT] = > + CPUID_8000_001F_EAX_SEV, Changing existing CPU models is possible only on very specific circumstances (where VMs that are currently runnable would always stay runnable), and would require compat_props entries to keep compatibility on existing machine-types. I don't think this is one case where adding the feature will be safe (even if adding compat code). What about existing VMs that are running on hosts that don't return SEV on KVM_GET_SUPPORTED_CPUID? "-cpu EPYC" would become not runnable on those hosts. (BTW, do you have a pointer to the KVM patches that enable SEV on KVM_GET_SUPPORTED_CPUID? I couldn't find them.) > .xlevel = 0x8000000A, > .model_id = "AMD EPYC Processor", > }, > @@ -3590,6 +3608,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, > *edx = 0; > } > break; > + case 0x8000001F: > + if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) { > + *eax = env->features[FEAT_MEM_ENCRYPT]; > + host_cpuid(0x8000001F, 0, NULL, ebx, NULL, NULL); This still have the same problem as v6. The CPUID data shouldn't come from the host CPU, but from the QEMU configuration. The same QEMU command-line must expose the same machine to the guest on any host (except on the "host" and "max" CPU models, that are the only non-migration-safe CPU models). > + *ecx = 0; > + *edx = 0; > + } else { > + *eax = 0; > + *ebx = 0; > + *ecx = 0; > + *edx = 0; > + } > + break; > case 0xC0000000: > *eax = env->cpuid_xlevel2; > *ebx = 0; > @@ -4037,10 +4068,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp) > 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); > + x86_cpu_adjust_feat_level(cpu, FEAT_MEM_ENCRYPT); This call here will automatically increase xlevel to 0x8000001F if any FEAT_MEM_ENCRYPT feature is set, so... > /* SVM requires CPUID[0x8000000A] */ > if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { > x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A); > } > + /* SEV requires CPUID[0x8000001F] */ > + if ((env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV)) { > + x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F); ...this code here seems unnecessary. > + } > } > > /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */ > diff --git a/target/i386/cpu.h b/target/i386/cpu.h > index f91e37d25dea..448b30f893fa 100644 > --- a/target/i386/cpu.h > +++ b/target/i386/cpu.h > @@ -483,6 +483,7 @@ typedef enum FeatureWord { > FEAT_6_EAX, /* CPUID[6].EAX */ > FEAT_XSAVE_COMP_LO, /* CPUID[EAX=0xd,ECX=0].EAX */ > FEAT_XSAVE_COMP_HI, /* CPUID[EAX=0xd,ECX=0].EDX */ > + FEAT_MEM_ENCRYPT, /* CPUID[8000_001F].EAX */ > FEATURE_WORDS, > } FeatureWord; > > @@ -679,6 +680,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; > > #define CPUID_6_EAX_ARAT (1U << 2) > > +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ > + > /* CPUID[0x80000007].EDX flags: */ > #define CPUID_APM_INVTSC (1U << 8) > > -- > 2.14.3 >
On 2/12/18 12:38 PM, Eduardo Habkost wrote: > On Mon, Feb 12, 2018 at 09:36:52AM -0600, Brijesh Singh wrote: >> AMD EPYC processors support memory encryption feature. The feature >> is reported through CPUID 8000_001F[EAX]. >> >> Fn8000_001F [EAX]: >> Bit 0 Secure Memory Encryption (SME) supported >> Bit 1 Secure Encrypted Virtualization (SEV) supported >> Bit 2 Page flush MSR supported >> Bit 3 Ecrypted State (SEV-ES) support >> >> when memory encryption feature is reported, CPUID 8000_001F[EBX] should >> provide additional information regarding the feature (such as which page >> table bit is used to mark pages as encrypted etc). The information in EBX >> and ECX may vary from one family to another hence we use the host cpuid >> to populate the EBX information. >> >> The details for memory encryption CPUID is available in AMD APM >> (https://support.amd.com/TechDocs/24594.pdf) Section E.4.17 >> >> Cc: Paolo Bonzini <pbonzini@redhat.com> >> Cc: Richard Henderson <rth@twiddle.net> >> Cc: Eduardo Habkost <ehabkost@redhat.com> >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >> --- >> target/i386/cpu.c | 36 ++++++++++++++++++++++++++++++++++++ >> target/i386/cpu.h | 3 +++ >> 2 files changed, 39 insertions(+) >> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c >> index b5e431e769da..475d98a44880 100644 >> --- a/target/i386/cpu.c >> +++ b/target/i386/cpu.c >> @@ -235,6 +235,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1, >> #define TCG_EXT4_FEATURES 0 >> #define TCG_SVM_FEATURES 0 >> #define TCG_KVM_FEATURES 0 >> +#define TCG_MEM_ENCRYPT_FEATURES 0 >> #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \ >> CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \ >> CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT | \ >> @@ -546,6 +547,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { >> .cpuid_reg = R_EDX, >> .tcg_features = ~0U, >> }, >> + [FEAT_MEM_ENCRYPT] = { >> + .feat_names = { >> + NULL, "sev", NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + NULL, NULL, NULL, NULL, >> + }, >> + .cpuid_eax = 0x8000001F, .cpuid_reg = R_EAX, >> + .tcg_features = TCG_MEM_ENCRYPT_FEATURES, >> + } > What should happen if "-cpu ...,+sev" is used without the > appropriate SEV configuration on the command-line? > If host supports SEV feature then we should communicate guest that SEV feature is available but not enabled. At least that's what I am doing today. Having said that, I am flexible to change if you all things otherwise. We could abort the launch if SEV configuration is missing and feature is enabled. In current implementation, when -cpu ...,+sev is passed without appropriate SEV configuration then we populate the Fn8000_001F CPUID but VMCB will not have SEV bit set hence a guest will be launched as non-SEV. The presence of Fn8000_001F provides the hint that HW supports the SEV feature but does not mean that it is enabled. A guest OS need to call MSR_AMD64_SEV (0xc001_0131) to determine if SEV is enabled. The MSR_AMD64_SEV is non interceptable read-only MSR. This MSR is set by the HW when SEV bit is enabled in VMCB. SEV bit in VMCB is enabled only when qemu adds those extra SEV configuration (i.e KVM_SEV_INIT is success) The steps used by guest OS to determine SEV active is documented here [1] [1] https://git.kernel.org/pub/scm/virt/kvm/kvm.git/tree/Documentation/x86/amd-memory-encryption.txt?h=linux-next#n57 > >> }; >> >> typedef struct X86RegisterInfo32 { >> @@ -1966,6 +1981,9 @@ static X86CPUDefinition builtin_x86_defs[] = { >> CPUID_XSAVE_XGETBV1, >> .features[FEAT_6_EAX] = >> CPUID_6_EAX_ARAT, >> + /* Missing: SEV_ES */ >> + .features[FEAT_MEM_ENCRYPT] = >> + CPUID_8000_001F_EAX_SEV, > Changing existing CPU models is possible only on very specific > circumstances (where VMs that are currently runnable would always > stay runnable), and would require compat_props entries to keep > compatibility on existing machine-types. Ah I didn't consider that case. What is recommendation, should we create a new CPU Model (EPYC-SEV) ? > I don't think this is one case where adding the feature will be > safe (even if adding compat code). What about existing VMs that > are running on hosts that don't return SEV on KVM_GET_SUPPORTED_CPUID? > "-cpu EPYC" would become not runnable on those hosts. > > (BTW, do you have a pointer to the KVM patches that enable SEV on > KVM_GET_SUPPORTED_CPUID? I couldn't find them.) > https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=linux-next&id=8765d75329a386dd7742f94a1ea5fdcdea8d93d0 >> .xlevel = 0x8000000A, >> .model_id = "AMD EPYC Processor", >> }, >> @@ -3590,6 +3608,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, >> *edx = 0; >> } >> break; >> + case 0x8000001F: >> + if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) { >> + *eax = env->features[FEAT_MEM_ENCRYPT]; >> + host_cpuid(0x8000001F, 0, NULL, ebx, NULL, NULL); > This still have the same problem as v6. The CPUID data shouldn't > come from the host CPU, but from the QEMU configuration. During SEV guest configuration parsing we validate cbit position passed through QEMU configure against the host and assert if verification fails hence I thought it was OK to call host_cpuid() later in the code path. Please note that EBX contains two information 1# C-bit position and 2# physical address bit reduction. Both of these information need to filled for the SEV guest. The physical address bit reduction depends on C-bit position and I have expose only C-bit position configuration to qemu command line. I was not sure if we should expose physical address bit reduction in qemu cmdline and then construct EBX using those two information. > The same QEMU command-line must expose the same machine to the > guest on any host (except on the "host" and "max" CPU models, > that are the only non-migration-safe CPU models). > > >> + *ecx = 0; >> + *edx = 0; >> + } else { >> + *eax = 0; >> + *ebx = 0; >> + *ecx = 0; >> + *edx = 0; >> + } >> + break; >> case 0xC0000000: >> *eax = env->cpuid_xlevel2; >> *ebx = 0; >> @@ -4037,10 +4068,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp) >> 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); >> + x86_cpu_adjust_feat_level(cpu, FEAT_MEM_ENCRYPT); > This call here will automatically increase xlevel to 0x8000001F > if any FEAT_MEM_ENCRYPT feature is set, so... > > >> /* SVM requires CPUID[0x8000000A] */ >> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { >> x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A); >> } >> + /* SEV requires CPUID[0x8000001F] */ >> + if ((env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV)) { >> + x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F); > ...this code here seems unnecessary. > > >> + } >> } >> >> /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */ >> diff --git a/target/i386/cpu.h b/target/i386/cpu.h >> index f91e37d25dea..448b30f893fa 100644 >> --- a/target/i386/cpu.h >> +++ b/target/i386/cpu.h >> @@ -483,6 +483,7 @@ typedef enum FeatureWord { >> FEAT_6_EAX, /* CPUID[6].EAX */ >> FEAT_XSAVE_COMP_LO, /* CPUID[EAX=0xd,ECX=0].EAX */ >> FEAT_XSAVE_COMP_HI, /* CPUID[EAX=0xd,ECX=0].EDX */ >> + FEAT_MEM_ENCRYPT, /* CPUID[8000_001F].EAX */ >> FEATURE_WORDS, >> } FeatureWord; >> >> @@ -679,6 +680,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; >> >> #define CPUID_6_EAX_ARAT (1U << 2) >> >> +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ >> + >> /* CPUID[0x80000007].EDX flags: */ >> #define CPUID_APM_INVTSC (1U << 8) >> >> -- >> 2.14.3 >>
On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote: > In current implementation, when -cpu ...,+sev is passed without > appropriate SEV configuration then we populate the Fn8000_001F CPUID but > VMCB will not have SEV bit set hence a guest will be launched as > non-SEV. I think we should fail the guest init if sev is not really supported by the host. Otherwise people might get mislead. > > Changing existing CPU models is possible only on very specific > > circumstances (where VMs that are currently runnable would always > > stay runnable), and would require compat_props entries to keep > > compatibility on existing machine-types. > > Ah I didn't consider that case. What is recommendation, should we create > a new CPU Model (EPYC-SEV) ? Can we please stop creating a new CPU model with every new CPUID feature support added? This is just ridiculous. If this is about live migration, then by all means, fail the migration if the feature bits are not compatible. But replicating CPU models and then adding one new differing feature doesn't make any sense.
On Mon, Feb 12, 2018 at 3:19 PM, Borislav Petkov <bp@suse.de> wrote: > On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote: > > In current implementation, when -cpu ...,+sev is passed without > > appropriate SEV configuration then we populate the Fn8000_001F CPUID but > > VMCB will not have SEV bit set hence a guest will be launched as > > non-SEV. > > I think we should fail the guest init if sev is not really supported by > the host. Otherwise people might get mislead. > > Sure I will do that. We can simplify this patch if we don't fill the CPUID for non SEV guest. I am thinking of doing something like this: "If SEV configration is provided in QEMU command line then automatically increase xlevel to 0x8000_001F and populate the EAX and EBX registers" > > > Changing existing CPU models is possible only on very specific > > > circumstances (where VMs that are currently runnable would always > > > stay runnable), and would require compat_props entries to keep > > > compatibility on existing machine-types. > > > > Ah I didn't consider that case. What is recommendation, should we create > > a new CPU Model (EPYC-SEV) ? > > Can we please stop creating a new CPU model with every new CPUID feature > support added? This is just ridiculous. > > If this is about live migration, then by all means, fail the migration > if the feature bits are not compatible. But replicating CPU models and > then adding one new differing feature doesn't make any sense. > > Yes, I think we should be able to avoid creating new CPU model to handle this case. I am leaning towards dropping this patch and implement logic to populate the CPUID 0x8000_001F only when SEV is enabled. This should not require any changes in existing CPU model feature flag and live migration of existing guest should work fine. > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nürnberg) > -- > >
On Tue, Feb 13, 2018 at 09:39:01AM -0600, Brijesh Singh wrote: > Yes, I think we should be able to avoid creating new CPU model to > handle this case. I am leaning towards dropping this patch and > implement logic to populate the CPUID 0x8000_001F only when SEV is > enabled. This should not require any changes in existing CPU model > feature flag and live migration of existing guest should work fine. That sounds even nicer. Thx.
* Brijesh Singh (brijesh.ksingh@gmail.com) wrote: > On Mon, Feb 12, 2018 at 3:19 PM, Borislav Petkov <bp@suse.de> wrote: > > > On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote: > > > In current implementation, when -cpu ...,+sev is passed without > > > appropriate SEV configuration then we populate the Fn8000_001F CPUID but > > > VMCB will not have SEV bit set hence a guest will be launched as > > > non-SEV. > > > > I think we should fail the guest init if sev is not really supported by > > the host. Otherwise people might get mislead. > > > > > > Sure I will do that. We can simplify this patch if we don't fill the CPUID > for non SEV guest. I am thinking of doing something like this: > > "If SEV configration is provided in QEMU command line then > automatically increase xlevel to 0x8000_001F and populate the EAX and EBX > registers" > > > > > > > Changing existing CPU models is possible only on very specific > > > > circumstances (where VMs that are currently runnable would always > > > > stay runnable), and would require compat_props entries to keep > > > > compatibility on existing machine-types. > > > > > > Ah I didn't consider that case. What is recommendation, should we create > > > a new CPU Model (EPYC-SEV) ? > > > > Can we please stop creating a new CPU model with every new CPUID feature > > support added? This is just ridiculous. > > > > If this is about live migration, then by all means, fail the migration > > if the feature bits are not compatible. But replicating CPU models and > > then adding one new differing feature doesn't make any sense. > > > > > Yes, I think we should be able to avoid creating new CPU model to handle > this case. > I am leaning towards dropping this patch and implement logic to populate the > CPUID 0x8000_001F only when SEV is enabled. This should not require any > changes > in existing CPU model feature flag and live migration of existing guest > should work fine. Take care that a non-SEV guest works migrating from a SEV-enabled host back to a non-SEV-enabled host. Similarly a guest that understands SEV but you aren't going to enable it for this VM. Dave > > > > -- > > Regards/Gruss, > > Boris. > > > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > > 21284 (AG Nürnberg) > > -- > > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
diff --git a/target/i386/cpu.c b/target/i386/cpu.c index b5e431e769da..475d98a44880 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -235,6 +235,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1, #define TCG_EXT4_FEATURES 0 #define TCG_SVM_FEATURES 0 #define TCG_KVM_FEATURES 0 +#define TCG_MEM_ENCRYPT_FEATURES 0 #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \ CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \ CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT | \ @@ -546,6 +547,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { .cpuid_reg = R_EDX, .tcg_features = ~0U, }, + [FEAT_MEM_ENCRYPT] = { + .feat_names = { + NULL, "sev", NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, + }, + .cpuid_eax = 0x8000001F, .cpuid_reg = R_EAX, + .tcg_features = TCG_MEM_ENCRYPT_FEATURES, + } }; typedef struct X86RegisterInfo32 { @@ -1966,6 +1981,9 @@ static X86CPUDefinition builtin_x86_defs[] = { CPUID_XSAVE_XGETBV1, .features[FEAT_6_EAX] = CPUID_6_EAX_ARAT, + /* Missing: SEV_ES */ + .features[FEAT_MEM_ENCRYPT] = + CPUID_8000_001F_EAX_SEV, .xlevel = 0x8000000A, .model_id = "AMD EPYC Processor", }, @@ -3590,6 +3608,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, *edx = 0; } break; + case 0x8000001F: + if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) { + *eax = env->features[FEAT_MEM_ENCRYPT]; + host_cpuid(0x8000001F, 0, NULL, ebx, NULL, NULL); + *ecx = 0; + *edx = 0; + } else { + *eax = 0; + *ebx = 0; + *ecx = 0; + *edx = 0; + } + break; case 0xC0000000: *eax = env->cpuid_xlevel2; *ebx = 0; @@ -4037,10 +4068,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp) 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); + x86_cpu_adjust_feat_level(cpu, FEAT_MEM_ENCRYPT); /* SVM requires CPUID[0x8000000A] */ if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A); } + /* SEV requires CPUID[0x8000001F] */ + if ((env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV)) { + x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F); + } } /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */ diff --git a/target/i386/cpu.h b/target/i386/cpu.h index f91e37d25dea..448b30f893fa 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -483,6 +483,7 @@ typedef enum FeatureWord { FEAT_6_EAX, /* CPUID[6].EAX */ FEAT_XSAVE_COMP_LO, /* CPUID[EAX=0xd,ECX=0].EAX */ FEAT_XSAVE_COMP_HI, /* CPUID[EAX=0xd,ECX=0].EDX */ + FEAT_MEM_ENCRYPT, /* CPUID[8000_001F].EAX */ FEATURE_WORDS, } FeatureWord; @@ -679,6 +680,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; #define CPUID_6_EAX_ARAT (1U << 2) +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ + /* CPUID[0x80000007].EDX flags: */ #define CPUID_APM_INVTSC (1U << 8)
AMD EPYC processors support memory encryption feature. The feature is reported through CPUID 8000_001F[EAX]. Fn8000_001F [EAX]: Bit 0 Secure Memory Encryption (SME) supported Bit 1 Secure Encrypted Virtualization (SEV) supported Bit 2 Page flush MSR supported Bit 3 Ecrypted State (SEV-ES) support when memory encryption feature is reported, CPUID 8000_001F[EBX] should provide additional information regarding the feature (such as which page table bit is used to mark pages as encrypted etc). The information in EBX and ECX may vary from one family to another hence we use the host cpuid to populate the EBX information. The details for memory encryption CPUID is available in AMD APM (https://support.amd.com/TechDocs/24594.pdf) Section E.4.17 Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> --- target/i386/cpu.c | 36 ++++++++++++++++++++++++++++++++++++ target/i386/cpu.h | 3 +++ 2 files changed, 39 insertions(+)