| Message ID | 20180129174132.108925-6-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Brijesh Singh (brijesh.singh@amd.com) 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. That's going to make it interesting for migration. If the guest needs to know that C-bit position then you presumably can't migrate between those two host types, but we wouldn't have anything that currently stops us. We already have similar problems with variations in physical address size but normally get away with that, especially on smaller VMs. Dave > The details for memory encryption CPUID is available in AMD APM > (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1 > 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 | 6 ++++++ > 2 files changed, 42 insertions(+) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index a49d2221adc9..4147eb6e18a9 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -234,6 +234,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 | \ > @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { > .cpuid_reg = R_EDX, > .tcg_features = ~0U, > }, > + [FEAT_MEM_ENCRYPT] = { > + .feat_names = { > + "sme", "sev", "page-flush-msr", "sev-es", > + 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 { > @@ -1965,6 +1980,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_SME | CPUID_8000_001F_EAX_SEV, > .xlevel = 0x8000000A, > .model_id = "AMD EPYC Processor", > }, > @@ -3589,6 +3607,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; > @@ -4036,10 +4067,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..f7a0ab20fdd1 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,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; > > #define CPUID_6_EAX_ARAT (1U << 2) > > +#define CPUID_8000_001F_EAX_SME (1U << 0) /* SME */ > +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ > +#define CPUID_8000_001F_EAX_PAGE_FLUSH_MSR (1U << 2) /* Page flush MSR */ > +#define CPUID_8000_001F_EAX_SEV_ES (1U << 3) /* SEV-ES */ > + > /* CPUID[0x80000007].EDX flags: */ > #define CPUID_APM_INVTSC (1U << 8) > > -- > 2.9.5 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote: > * Brijesh Singh (brijesh.singh@amd.com) 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. > That's going to make it interesting for migration. If the guest needs > to know that C-bit position then you presumably can't migrate between > those two host types, but we wouldn't have anything that currently > stops us. > We already have similar problems with variations in physical address > size but normally get away with that, especially on smaller VMs. Dave, While building the page tables guest need to know the C-bit position. The C-bit position in the guest is same as C-bit position on the host. For migration case, we should be able to migrate SEV guest on same host type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should be okay migrating the SEV guests among those host types). Since C-bit position is not fixed hence migrating to different host family will be an issue. -Brijesh > Dave > > >> The details for memory encryption CPUID is available in AMD APM >> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1 >> 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 | 6 ++++++ >> 2 files changed, 42 insertions(+) >> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c >> index a49d2221adc9..4147eb6e18a9 100644 >> --- a/target/i386/cpu.c >> +++ b/target/i386/cpu.c >> @@ -234,6 +234,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 | \ >> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { >> .cpuid_reg = R_EDX, >> .tcg_features = ~0U, >> }, >> + [FEAT_MEM_ENCRYPT] = { >> + .feat_names = { >> + "sme", "sev", "page-flush-msr", "sev-es", >> + 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 { >> @@ -1965,6 +1980,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_SME | CPUID_8000_001F_EAX_SEV, >> .xlevel = 0x8000000A, >> .model_id = "AMD EPYC Processor", >> }, >> @@ -3589,6 +3607,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; >> @@ -4036,10 +4067,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..f7a0ab20fdd1 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,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; >> >> #define CPUID_6_EAX_ARAT (1U << 2) >> >> +#define CPUID_8000_001F_EAX_SME (1U << 0) /* SME */ >> +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ >> +#define CPUID_8000_001F_EAX_PAGE_FLUSH_MSR (1U << 2) /* Page flush MSR */ >> +#define CPUID_8000_001F_EAX_SEV_ES (1U << 3) /* SEV-ES */ >> + >> /* CPUID[0x80000007].EDX flags: */ >> #define CPUID_APM_INVTSC (1U << 8) >> >> -- >> 2.9.5 >> > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 1/30/18 3:46 PM, Brijesh Singh wrote: > > On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote: >> * Brijesh Singh (brijesh.singh@amd.com) 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. >> That's going to make it interesting for migration. If the guest needs >> to know that C-bit position then you presumably can't migrate between >> those two host types, but we wouldn't have anything that currently >> stops us. >> We already have similar problems with variations in physical address >> size but normally get away with that, especially on smaller VMs. > Dave, > > While building the page tables guest need to know the C-bit position. > The C-bit position in the guest is same as C-bit position on the host. > For migration case, we should be able to migrate SEV guest on same host > type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should > be okay migrating the SEV guests among those host types). Since C-bit > position is not fixed hence migrating to different host family will be > an issue. One small correct, Ryzen CPUs do not support SEV feature hence we will not able migrate SEV guest from EPYC to Ryzen. > -Brijesh >> Dave >> >> >>> The details for memory encryption CPUID is available in AMD APM >>> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1 >>> 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 | 6 ++++++ >>> 2 files changed, 42 insertions(+) >>> >>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c >>> index a49d2221adc9..4147eb6e18a9 100644 >>> --- a/target/i386/cpu.c >>> +++ b/target/i386/cpu.c >>> @@ -234,6 +234,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 | \ >>> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { >>> .cpuid_reg = R_EDX, >>> .tcg_features = ~0U, >>> }, >>> + [FEAT_MEM_ENCRYPT] = { >>> + .feat_names = { >>> + "sme", "sev", "page-flush-msr", "sev-es", >>> + 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 { >>> @@ -1965,6 +1980,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_SME | CPUID_8000_001F_EAX_SEV, >>> .xlevel = 0x8000000A, >>> .model_id = "AMD EPYC Processor", >>> }, >>> @@ -3589,6 +3607,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; >>> @@ -4036,10 +4067,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..f7a0ab20fdd1 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,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; >>> >>> #define CPUID_6_EAX_ARAT (1U << 2) >>> >>> +#define CPUID_8000_001F_EAX_SME (1U << 0) /* SME */ >>> +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ >>> +#define CPUID_8000_001F_EAX_PAGE_FLUSH_MSR (1U << 2) /* Page flush MSR */ >>> +#define CPUID_8000_001F_EAX_SEV_ES (1U << 3) /* SEV-ES */ >>> + >>> /* CPUID[0x80000007].EDX flags: */ >>> #define CPUID_APM_INVTSC (1U << 8) >>> >>> -- >>> 2.9.5 >>> >> -- >> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
* Brijesh Singh (brijesh.singh@amd.com) wrote: > > > On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote: > > * Brijesh Singh (brijesh.singh@amd.com) 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. > > That's going to make it interesting for migration. If the guest needs > > to know that C-bit position then you presumably can't migrate between > > those two host types, but we wouldn't have anything that currently > > stops us. > > We already have similar problems with variations in physical address > > size but normally get away with that, especially on smaller VMs. > > Dave, > > While building the page tables guest need to know the C-bit position. > The C-bit position in the guest is same as C-bit position on the host. > For migration case, we should be able to migrate SEV guest on same host > type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should > be okay migrating the SEV guests among those host types). Since C-bit > position is not fixed hence migrating to different host family will be > an issue. Sure; so the interesting question is how would a management layer like libvirt know when it's safe to migrate a guest between EPYC and a later family that has the C-bit in a different location? Dave > -Brijesh > > Dave > > > > > >> The details for memory encryption CPUID is available in AMD APM > >> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1 > >> 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 | 6 ++++++ > >> 2 files changed, 42 insertions(+) > >> > >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c > >> index a49d2221adc9..4147eb6e18a9 100644 > >> --- a/target/i386/cpu.c > >> +++ b/target/i386/cpu.c > >> @@ -234,6 +234,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 | \ > >> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { > >> .cpuid_reg = R_EDX, > >> .tcg_features = ~0U, > >> }, > >> + [FEAT_MEM_ENCRYPT] = { > >> + .feat_names = { > >> + "sme", "sev", "page-flush-msr", "sev-es", > >> + 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 { > >> @@ -1965,6 +1980,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_SME | CPUID_8000_001F_EAX_SEV, > >> .xlevel = 0x8000000A, > >> .model_id = "AMD EPYC Processor", > >> }, > >> @@ -3589,6 +3607,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; > >> @@ -4036,10 +4067,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..f7a0ab20fdd1 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,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; > >> > >> #define CPUID_6_EAX_ARAT (1U << 2) > >> > >> +#define CPUID_8000_001F_EAX_SME (1U << 0) /* SME */ > >> +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ > >> +#define CPUID_8000_001F_EAX_PAGE_FLUSH_MSR (1U << 2) /* Page flush MSR */ > >> +#define CPUID_8000_001F_EAX_SEV_ES (1U << 3) /* SEV-ES */ > >> + > >> /* CPUID[0x80000007].EDX flags: */ > >> #define CPUID_APM_INVTSC (1U << 8) > >> > >> -- > >> 2.9.5 > >> > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Tue, Jan 30, 2018 at 03:46:45PM -0600, Brijesh Singh wrote: > > > On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote: > > * Brijesh Singh (brijesh.singh@amd.com) 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. > > That's going to make it interesting for migration. If the guest needs > > to know that C-bit position then you presumably can't migrate between > > those two host types, but we wouldn't have anything that currently > > stops us. > > We already have similar problems with variations in physical address > > size but normally get away with that, especially on smaller VMs. > > Dave, > > While building the page tables guest need to know the C-bit position. > The C-bit position in the guest is same as C-bit position on the host. > For migration case, we should be able to migrate SEV guest on same host > type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should > be okay migrating the SEV guests among those host types). Since C-bit > position is not fixed hence migrating to different host family will be > an issue. Thanks for the explanation. If this affects ability to migrate, you need to either: a) not report the "sev" property on query-cpu-model-expansion type=static output (because the feature is not migration-safe); or b) make the C-bit position configurable, and let management explicitly specify it. In this case, you need to validate the configured C-bit position and prevent the VM from running if it doesn't match the host. This is more work, but would make the feature migration-safe and more useful for management software. Option (b) is preferred because it lets management software ensure the VM is migratable to a host before starting migration. There was a very recent discussion about migration-safe features and the problems with relaying host CPUID data directly to the guest. Look for the "i386: Add Intel Processor Trace feature support" threads in qemu-devel for more info. I'm looking for a way to document these rules concisely so people touching the CPUID code are aware of the available options.
On 01/31/2018 07:41 AM, Eduardo Habkost wrote: > On Tue, Jan 30, 2018 at 03:46:45PM -0600, Brijesh Singh wrote: >> >> >> On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote: >>> * Brijesh Singh (brijesh.singh@amd.com) 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. >>> That's going to make it interesting for migration. If the guest needs >>> to know that C-bit position then you presumably can't migrate between >>> those two host types, but we wouldn't have anything that currently >>> stops us. >>> We already have similar problems with variations in physical address >>> size but normally get away with that, especially on smaller VMs. >> >> Dave, >> >> While building the page tables guest need to know the C-bit position. >> The C-bit position in the guest is same as C-bit position on the host. >> For migration case, we should be able to migrate SEV guest on same host >> type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should >> be okay migrating the SEV guests among those host types). Since C-bit >> position is not fixed hence migrating to different host family will be >> an issue. > > Thanks for the explanation. If this affects ability to migrate, > you need to either: > a) not report the "sev" property on > query-cpu-model-expansion type=static output (because the > feature is not migration-safe); or > b) make the C-bit position configurable, and let management > explicitly specify it. In this case, you need to validate the > configured C-bit position and prevent the VM from running if > it doesn't match the host. This is more work, but would make > the feature migration-safe and more useful for management > software. > > Option (b) is preferred because it lets management software > ensure the VM is migratable to a host before starting migration. > > There was a very recent discussion about migration-safe features > and the problems with relaying host CPUID data directly to the > guest. Look for the "i386: Add Intel Processor Trace feature > support" threads in qemu-devel for more info. > > I'm looking for a way to document these rules concisely so people > touching the CPUID code are aware of the available options. > I also prefer Option (b). In next series, I will extend the sev-guest object to add a new property (cbitpos). Management software stack can use this property to pass the c-bit position and we validate it. Thanks for the feedback. -Brijesh
diff --git a/target/i386/cpu.c b/target/i386/cpu.c index a49d2221adc9..4147eb6e18a9 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -234,6 +234,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 | \ @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = { .cpuid_reg = R_EDX, .tcg_features = ~0U, }, + [FEAT_MEM_ENCRYPT] = { + .feat_names = { + "sme", "sev", "page-flush-msr", "sev-es", + 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 { @@ -1965,6 +1980,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_SME | CPUID_8000_001F_EAX_SEV, .xlevel = 0x8000000A, .model_id = "AMD EPYC Processor", }, @@ -3589,6 +3607,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; @@ -4036,10 +4067,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..f7a0ab20fdd1 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,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS]; #define CPUID_6_EAX_ARAT (1U << 2) +#define CPUID_8000_001F_EAX_SME (1U << 0) /* SME */ +#define CPUID_8000_001F_EAX_SEV (1U << 1) /* SEV */ +#define CPUID_8000_001F_EAX_PAGE_FLUSH_MSR (1U << 2) /* Page flush MSR */ +#define CPUID_8000_001F_EAX_SEV_ES (1U << 3) /* SEV-ES */ + /* 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 (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1 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 | 6 ++++++ 2 files changed, 42 insertions(+)