Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp798971ybg; Sun, 26 Jul 2020 22:57:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0PP8jN3weMADPL+/jhoHuymr2f+I6r1BggOR0SNWAczzI8tFfSQo6PnYJCd67VX3dXkHM X-Received: by 2002:a17:906:3e54:: with SMTP id t20mr19231131eji.471.1595829456582; Sun, 26 Jul 2020 22:57:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595829456; cv=none; d=google.com; s=arc-20160816; b=KLO+S6QYKgjmygcLec/6APLBuPKIzyEeLk2Wir62W4cgCNzfJrfKZUBrEhsNT3x7YM XBBQAo9CyUCLQeTBHVPUCtdkdiQRTrKUjKEPDQajulsmHL6dY8wcLPVhFvzSzMXVRXlx 57nywP4aZx7/ACTZRxuKxdcHB051IQWt32gza4V1y4YRBb3QXM1IlIFHNnZdjzkp8/E1 zJsjzHbN6CSgQeraT3cx+AUw8jtZKcm2O/1/NTmpYrdvRRYMxpR7YEwZgKk5hISL56dU L3fBzHdJESMi7kv4BVntMB9rdHBkzxxztDSbmxiRr4MR5vh+bgDDYM7l6ktxzNL/TWMB evhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:dkim-filter; bh=q43yxrICPWtEznO0DvAh1fXGlgYTxGeEdUMQ1ZEw3WY=; b=TleLhWU1VNxlh4ykLPQrGmZaQ6B+8oUMFG4keZllm/blcFgyeP9vS9Bqbvl52wH7Bh bTi1oT+gQ6H40O3vV0ta+8DaqJgwTAVNHwKM7bjsFHwzRk5V+6AZx20tloo5zw7owgvV fW79SCV3Vo4w2l9UjGmKLhhWqu8UaaIdsrNgOVGrK/XeuWlKM7KN5J6kHjZkpjn86jfb c42DdVrh1fmJxJVrrb03SIinbax7eqKWUYiwSnd0ig5EfCjTKhK4LzkkHbI1DyJswNl/ dTKJKXfrwDruy52cJIXjvVwdMG71HXPsRt2xJCTQX0w1ekk5WxntTJHVYRNYyB9cjobz jBGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@zytor.com header.s=2020072401 header.b=bxtwza+l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si4922819eds.15.2020.07.26.22.57.14; Sun, 26 Jul 2020 22:57:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@zytor.com header.s=2020072401 header.b=bxtwza+l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726929AbgG0F4E (ORCPT + 99 others); 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