[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181116153821.GA29898@linux.intel.com>
Date: Fri, 16 Nov 2018 07:38:21 -0800
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, x86@...nel.org,
platform-driver-x86@...r.kernel.org, linux-sgx@...r.kernel.org,
dave.hansen@...el.com, nhorman@...hat.com, npmccallum@...hat.com,
serge.ayoun@...el.com, shay.katz-zamir@...el.com,
haitao.huang@...ux.intel.com, andriy.shevchenko@...ux.intel.com,
tglx@...utronix.de, kai.svahn@...el.com, mark.shanahan@...el.com,
luto@...capital.net, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Fenghua Yu <fenghua.yu@...el.com>,
Brijesh Singh <brijesh.singh@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Tom Lendacky <thomas.lendacky@....com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v17 03/23] x86/cpufeatures: Add SGX sub-features (as
Linux-defined bits)
On Fri, Nov 16, 2018 at 03:37:15PM +0100, Borislav Petkov wrote:
> On Fri, Nov 16, 2018 at 03:01:10AM +0200, Jarkko Sakkinen wrote:
> > From: Sean Christopherson <sean.j.christopherson@...el.com>
> >
> > CPUID_12_EAX is an Intel-defined feature bits leaf dedicated for SGX
> > that enumerates the SGX instruction sets that are supported by the
> > CPU, e.g. SGX1, SGX2, etc... Because Linux currently only cares about
> > two bits (SGX1 and SGX2) and there are currently only four documented
> > bits in total, relocate the bits to Linux-defined word 8 to conserve
> > space.
> >
> > But, keep the bit positions identical between the Intel-defined value
> > and the Linux-defined value, e.g. keep SGX1 at bit 0. This allows KVM
> > to use its existing code for probing guest CPUID bits using Linux's
> > X86_FEATURE_* definitions. To do so, shift around some existing bits
> > to effectively reserve bits 0-7 of word 8 for SGX sub-features.
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
> > ---
> > arch/x86/include/asm/cpufeatures.h | 21 +++++++++++++++------
> > arch/x86/kernel/cpu/scattered.c | 2 ++
> > tools/arch/x86/include/asm/cpufeatures.h | 21 +++++++++++++++------
> > 3 files changed, 32 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index da7fed4939a3..afdf5f2e13b5 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -222,12 +222,21 @@
> > #define X86_FEATURE_L1TF_PTEINV ( 7*32+29) /* "" L1TF workaround PTE inversion */
> > #define X86_FEATURE_IBRS_ENHANCED ( 7*32+30) /* Enhanced IBRS */
> >
> > -/* Virtualization flags: Linux defined, word 8 */
> > -#define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
> > -#define X86_FEATURE_VNMI ( 8*32+ 1) /* Intel Virtual NMI */
> > -#define X86_FEATURE_FLEXPRIORITY ( 8*32+ 2) /* Intel FlexPriority */
> > -#define X86_FEATURE_EPT ( 8*32+ 3) /* Intel Extended Page Table */
> > -#define X86_FEATURE_VPID ( 8*32+ 4) /* Intel Virtual Processor ID */
> > +/*
> > + * Scattered Intel features: Linux defined, word 8.
> > + *
> > + * Note that the bit location of the SGX features is meaningful as KVM expects
> > + * the Linux defined bit to match the Intel defined bit, e.g. X86_FEATURE_SGX1
> > + * must remain at bit 0, SGX2 at bit 1, etc...
> > + */
> > +#define X86_FEATURE_SGX1 ( 8*32+ 0) /* SGX1 leaf functions */
> > +#define X86_FEATURE_SGX2 ( 8*32+ 1) /* SGX2 leaf functions */
> > +
>
> Yeah, add here ^^^^
>
> /* Bits [0:7] are reserved for SGX */
>
> or so, so that people don't use those. Once CPUID(12) gets more bits
> added to it, I don't see anything wrong with allocating a separate leaf
> for that.
>
> BUT(!), the question then is whether kvm would still be ok with that?
> I'm thinking yes, as it will simply use the new definitions, or?
Yep, wouldn't be a problem for KVM.
Powered by blists - more mailing lists