Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753439AbdFWLus (ORCPT ); Fri, 23 Jun 2017 07:50:48 -0400 Received: from mail.skyhub.de ([5.9.137.197]:44028 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751221AbdFWLuq (ORCPT ); Fri, 23 Jun 2017 07:50:46 -0400 Date: Fri, 23 Jun 2017 13:50:26 +0200 From: Borislav Petkov To: Andy Lutomirski Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" , Nadav Amit , Rik van Riel , Dave Hansen , Arjan van de Ven , Peter Zijlstra , Juergen Gross , Boris Ostrovsky Subject: Re: [PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems Message-ID: <20170623115026.qqy5mpyihymocaet@pd.tnic> References: <57c1d18b1c11f9bc9a3bcf8bdee38033415e1a13.1498022414.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57c1d18b1c11f9bc9a3bcf8bdee38033415e1a13.1498022414.git.luto@kernel.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3070 Lines: 94 On Tue, Jun 20, 2017 at 10:22:16PM -0700, Andy Lutomirski wrote: > We can use PCID if the CPU has PCID and PGE and we're not on Xen. > > By itself, this has no effect. The next patch will start using > PCID. > > Cc: Juergen Gross > Cc: Boris Ostrovsky > Signed-off-by: Andy Lutomirski > --- > arch/x86/include/asm/tlbflush.h | 8 ++++++++ > arch/x86/kernel/cpu/common.c | 15 +++++++++++++++ > arch/x86/xen/enlighten_pv.c | 6 ++++++ > 3 files changed, 29 insertions(+) > > diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h > index 87b13e51e867..57b305e13c4c 100644 > --- a/arch/x86/include/asm/tlbflush.h > +++ b/arch/x86/include/asm/tlbflush.h > @@ -243,6 +243,14 @@ static inline void __flush_tlb_all(void) > __flush_tlb_global(); > else > __flush_tlb(); > + > + /* > + * Note: if we somehow had PCID but not PGE, then this wouldn't work -- > + * we'd end up flushing kernel translations for the current ASID but > + * we might fail to flush kernel translations for other cached ASIDs. > + * > + * To avoid this issue, we force PCID off if PGE is off. > + */ > } > > static inline void __flush_tlb_one(unsigned long addr) > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 904485e7b230..01caf66b270f 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -1143,6 +1143,21 @@ static void identify_cpu(struct cpuinfo_x86 *c) > setup_smep(c); > setup_smap(c); > > + /* Set up PCID */ > + if (cpu_has(c, X86_FEATURE_PCID)) { > + if (cpu_has(c, X86_FEATURE_PGE)) { What are we protecting ourselves here against? Funny virtualization guests? Because PGE should be ubiquitous by now. Or have you heard something? > + cr4_set_bits(X86_CR4_PCIDE); > + } else { > + /* > + * flush_tlb_all(), as currently implemented, won't > + * work if PCID is on but PGE is not. Since that > + * combination doesn't exist on real hardware, there's > + * no reason to try to fully support it. > + */ > + clear_cpu_cap(c, X86_FEATURE_PCID); > + } > + } This whole in setup_pcid() I guess, like the rest of the features. > + > /* > * The vendor-specific functions might have changed features. > * Now we do "generic changes." > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index f33eef4ebd12..a136aac543c3 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -295,6 +295,12 @@ static void __init xen_init_capabilities(void) > setup_clear_cpu_cap(X86_FEATURE_ACC); > setup_clear_cpu_cap(X86_FEATURE_X2APIC); > > + /* > + * Xen PV would need some work to support PCID: CR3 handling as well > + * as xen_flush_tlb_others() would need updating. > + */ > + setup_clear_cpu_cap(X86_FEATURE_PCID); > + > if (!xen_initial_domain()) > setup_clear_cpu_cap(X86_FEATURE_ACPI); > > -- > 2.9.4 > -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.