From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A02A7C433E3 for ; Mon, 27 Jul 2020 05:56:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 76B992075D for ; Mon, 27 Jul 2020 05:56:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="bxtwza+l" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726951AbgG0F4E (ORCPT ); Mon, 27 Jul 2020 01:56:04 -0400 Received: from terminus.zytor.com ([198.137.202.136]:58827 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726817AbgG0F4D (ORCPT ); Mon, 27 Jul 2020 01:56:03 -0400 Received: from [IPv6:2601:646:8600:3281:d01e:b6c6:1a24:9007] ([IPv6:2601:646:8600:3281:d01e:b6c6:1a24:9007]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id 06R5tSiG1894912 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 26 Jul 2020 22:55:30 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 06R5tSiG1894912 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2020072401; t=1595829330; bh=q43yxrICPWtEznO0DvAh1fXGlgYTxGeEdUMQ1ZEw3WY=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=bxtwza+lvE7XEmO86pjOVeRBurkBu91lVsW+Dn9tQtLwzMh+0c39xiOzWRMrjiDOX 6h9fxadORCzi/wW4SS7uVsYXdMxAFSBUIqOJNg7U/LfDcDSZ6X3blZYMw3jlPtw7Ch 5dxKfJDo4dcY8PoWw2sK+ACsrQnhg20h31HXxnZhMhnopRHvhCbuHPdxMsPS6dHVPC /t3K1lTtoNrasbYG9Fs2CCKPtvVBkLkujGw3TVag/4HWRoi493mvcfVrt6QC2xHUYk DF0jJhaSABUnK3eYr5zirXPISrZv70xmo5ADjv1+dEPcAPBmHbZwowuIluq4t6DCGr vQV7G9pP0ARwQ== Date: Sun, 26 Jul 2020 22:55:15 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20200727043132.15082-5-ricardo.neri-calderon@linux.intel.com> References: <20200727043132.15082-1-ricardo.neri-calderon@linux.intel.com> <20200727043132.15082-5-ricardo.neri-calderon@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 4/4] x86/cpu: Use SERIALIZE in sync_core() when available To: Ricardo Neri , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , x86@kernel.org CC: Dave Hansen , Tony Luck , Cathy Zhang , Fenghua Yu , Kyung Min Park , "Peter Zijlstra (Intel)" , "Ravi V. Shankar" , Sean Christopherson , linux-kernel@vger.kernel.org, Ricardo Neri , Dave Hansen , linux-edac@vger.kernel.org From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On July 26, 2020 9:31:32 PM PDT, Ricardo Neri wrote: >The SERIALIZE instruction gives software a way to force the processor >to >complete all modifications to flags, registers and memory from previous >instructions and drain all buffered writes to memory before the next >instruction is fetched and executed=2E Thus, it serves the purpose of >sync_core()=2E Use it when available=2E > >Use boot_cpu_has() and not static_cpu_has(); the most critical paths >(returning to user mode and from interrupt and NMI) will not reach >sync_core()=2E > >Cc: Andy Lutomirski >Cc: Cathy Zhang >Cc: Dave Hansen >Cc: Fenghua Yu >Cc: "H=2E Peter Anvin" >Cc: Kyung Min Park >Cc: Peter Zijlstra >Cc: "Ravi V=2E Shankar" >Cc: Sean Christopherson >Cc: linux-edac@vger=2Ekernel=2Eorg >Cc: linux-kernel@vger=2Ekernel=2Eorg >Reviwed-by: Tony Luck >Suggested-by: Andy Lutomirski >Signed-off-by: Ricardo Neri >--- >--- > arch/x86/include/asm/special_insns=2Eh | 5 +++++ > arch/x86/include/asm/sync_core=2Eh | 10 +++++++++- > 2 files changed, 14 insertions(+), 1 deletion(-) > >diff --git a/arch/x86/include/asm/special_insns=2Eh >b/arch/x86/include/asm/special_insns=2Eh >index 59a3e13204c3=2E=2E0a2a60bba282 100644 >--- a/arch/x86/include/asm/special_insns=2Eh >+++ b/arch/x86/include/asm/special_insns=2Eh >@@ -234,6 +234,11 @@ static inline void clwb(volatile void *__p) >=20 > #define nop() asm volatile ("nop") >=20 >+static inline void serialize(void) >+{ >+ asm volatile("=2Ebyte 0xf, 0x1, 0xe8"); >+} >+ > #endif /* __KERNEL__ */ >=20 > #endif /* _ASM_X86_SPECIAL_INSNS_H */ >diff --git a/arch/x86/include/asm/sync_core=2Eh >b/arch/x86/include/asm/sync_core=2Eh >index fdb5b356e59b=2E=2Ebf132c09d61b 100644 >--- a/arch/x86/include/asm/sync_core=2Eh >+++ b/arch/x86/include/asm/sync_core=2Eh >@@ -5,6 +5,7 @@ > #include > #include > #include >+#include >=20 > #ifdef CONFIG_X86_32 > static inline void iret_to_self(void) >@@ -54,7 +55,8 @@ static inline void iret_to_self(void) > static inline void sync_core(void) > { > /* >- * There are quite a few ways to do this=2E IRET-to-self is nice >+ * Hardware can do this for us if SERIALIZE is available=2E Otherwise, >+ * there are quite a few ways to do this=2E IRET-to-self is nice > * because it works on every CPU, at any CPL (so it's compatible > * with paravirtualization), and it never exits to a hypervisor=2E > * The only down sides are that it's a bit slow (it seems to be >@@ -75,6 +77,12 @@ static inline void sync_core(void) > * Like all of Linux's memory ordering operations, this is a > * compiler barrier as well=2E > */ >+ >+ if (boot_cpu_has(X86_FEATURE_SERIALIZE)) { >+ serialize(); >+ return; >+ } >+ > iret_to_self(); > } >=20 Any reason to not make sync_core() an inline with alternatives? For a really overenginered solution, but which might perform unnecessary p= oorly on existing hardware: asm volatile("1: =2Ebyte 0xf, 0x1, 0xe8; 2:" _ASM_EXTABLE(1b,2b)); --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E