From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dr. David Alan Gilbert" Subject: Re: [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support Date: Wed, 31 Jan 2018 09:57:16 +0000 Message-ID: <20180131095715.GA2521@work-vm> References: <20180129174132.108925-1-brijesh.singh@amd.com> <20180129174132.108925-6-brijesh.singh@amd.com> <20180130174957.GD2536@work-vm> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Paolo Bonzini , Tom Lendacky , Peter Maydell , Richard Henderson , "Edgar E. Iglesias" , Eduardo Habkost , Stefan Hajnoczi , Eric Blake , "Michael S. Tsirkin" , "Daniel P . Berrange" , Richard Henderson To: Brijesh Singh Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53126 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751320AbeAaJ5Z (ORCPT ); Wed, 31 Jan 2018 04:57:25 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: * 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 > >> Cc: Richard Henderson > >> Cc: Eduardo Habkost > >> Signed-off-by: Brijesh Singh > >> --- > >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egp91-0006SI-Dn for qemu-devel@nongnu.org; Wed, 31 Jan 2018 04:57:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egp8w-00066x-6g for qemu-devel@nongnu.org; Wed, 31 Jan 2018 04:57:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51864) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1egp8v-00065A-TS for qemu-devel@nongnu.org; Wed, 31 Jan 2018 04:57:26 -0500 Date: Wed, 31 Jan 2018 09:57:16 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20180131095715.GA2521@work-vm> References: <20180129174132.108925-1-brijesh.singh@amd.com> <20180129174132.108925-6-brijesh.singh@amd.com> <20180130174957.GD2536@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Brijesh Singh Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Paolo Bonzini , Tom Lendacky , Peter Maydell , Richard Henderson , "Edgar E. Iglesias" , Eduardo Habkost , Stefan Hajnoczi , Eric Blake , "Michael S. Tsirkin" , "Daniel P . Berrange" , Richard Henderson * Brijesh Singh (brijesh.singh@amd.com) wrote: >=20 >=20 > 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] sho= uld > >> provide additional information regarding the feature (such as which = page > >> table bit is used to mark pages as encrypted etc). The information i= n EBX > >> and ECX may vary from one family to another hence we use the host cp= uid > >> to populate the EBX information. > > That's going to make it interesting for migration. If the guest need= s > > 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. >=20 > Dave, >=20 > 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).=A0 Since C-bi= t > 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 > >> Cc: Richard Henderson > >> Cc: Eduardo Habkost > >> Signed-off-by: Brijesh Singh > >> --- > >> 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_SM= AP | \ > >> CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_A= DX | \ > >> CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT | = \ > >> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATUR= E_WORDS] =3D { > >> .cpuid_reg =3D R_EDX, > >> .tcg_features =3D ~0U, > >> }, > >> + [FEAT_MEM_ENCRYPT] =3D { > >> + .feat_names =3D { > >> + "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 =3D 0x8000001F, .cpuid_reg =3D R_EAX, > >> + .tcg_features =3D TCG_MEM_ENCRYPT_FEATURES, > >> + } > >> }; > >> =20 > >> typedef struct X86RegisterInfo32 { > >> @@ -1965,6 +1980,9 @@ static X86CPUDefinition builtin_x86_defs[] =3D= { > >> CPUID_XSAVE_XGETBV1, > >> .features[FEAT_6_EAX] =3D > >> CPUID_6_EAX_ARAT, > >> + /* Missing: SEV_ES */ > >> + .features[FEAT_MEM_ENCRYPT] =3D > >> + CPUID_8000_001F_EAX_SME | CPUID_8000_001F_EAX_SEV, > >> .xlevel =3D 0x8000000A, > >> .model_id =3D "AMD EPYC Processor", > >> }, > >> @@ -3589,6 +3607,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t= index, uint32_t count, > >> *edx =3D 0; > >> } > >> break; > >> + case 0x8000001F: > >> + if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_S= EV) { > >> + *eax =3D env->features[FEAT_MEM_ENCRYPT]; > >> + host_cpuid(0x8000001F, 0, NULL, ebx, NULL, NULL); > >> + *ecx =3D 0; > >> + *edx =3D 0; > >> + } else { > >> + *eax =3D 0; > >> + *ebx =3D 0; > >> + *ecx =3D 0; > >> + *edx =3D 0; > >> + } > >> + break; > >> case 0xC0000000: > >> *eax =3D env->cpuid_xlevel2; > >> *ebx =3D 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, 0x800= 0000A); > >> } > >> + /* SEV requires CPUID[0x8000001F] */ > >> + if ((env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_= SEV)) { > >> + x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x800= 0001F); > >> + } > >> } > >> =20 > >> /* Set cpuid_*level* based on cpuid_min_*level, if not explicit= ly 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=3D0xd,ECX=3D0].EAX */ > >> FEAT_XSAVE_COMP_HI, /* CPUID[EAX=3D0xd,ECX=3D0].EDX */ > >> + FEAT_MEM_ENCRYPT, /* CPUID[8000_001F].EAX */ > >> FEATURE_WORDS, > >> } FeatureWord; > >> =20 > >> @@ -679,6 +680,11 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS= ]; > >> =20 > >> #define CPUID_6_EAX_ARAT (1U << 2) > >> =20 > >> +#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) > >> =20 > >> --=20 > >> 2.9.5 > >> > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK