Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1678736imm; Tue, 2 Oct 2018 12:05:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV62g3VAF7M+uysds1eUR8178WwL00GYK6k14ZSyPer2rpeE5pkZ4J9h13tRL+qrwadyCtYSC X-Received: by 2002:a63:4a64:: with SMTP id j36-v6mr9667654pgl.168.1538507145769; Tue, 02 Oct 2018 12:05:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538507145; cv=none; d=google.com; s=arc-20160816; b=zZVxfRb4RvpP7gMyXdoQ5pT4FGMqMV6kQUwNKd7quCHKXUoCulWDRqXM5ZGvoN4R/S 2aKAjI2nwvyKENaank7COqivwlOwC+0+6+X5eDDMLOLqPUt0Verrr/jIRj2G3LVp+Qly 7LadvWkYxvgjFPI+kdNWFRuc5Mle4jiQEyPwpQNtucoSKsJReE2mI7GagXHfz7orteOy VtAPYHlYkt5/t0GKYstFrgVi7MPm6p8I1EI8vCO/GNhzZBajfhP8h3ZUPdZAzvLSKycQ LpyLomCrCUnlG/MkC7mfm3dF1CPxVM3iCXr5kJhqT6yAZ5xc+STB2EVgw7/VgsQREFfb aouA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=R0kruEFNXSg0QHZLt1TuaESi5AYWbMkzFY0rSCwuQHc=; b=Iw9nIwaVo16TVCcZPXOaHz9tRcHkQvtglHb3IW8XPz9LJQRsZcWnRzxKCZp22DBwcl zWm1DUrcf9EpVPl5i4MluaZ0W6YPOZaWYE2AyoOJ5fdnSE7KpmeT5/J9BUQ+4SXrhcpp hfe4q8FYJCNvSn0a5o8dgg7TpIj4M0Qv1WfMe398fYzSC3i8gBLv/hKJuZObs6e53ayO Zmco1Oq/+GyVhuUFRDkRkY4LRlhSj+WMGiW8xjp5NTlCAjkE85Ok750UU89SYDrcBI7e lF9kvrFGOGB0Ttwtenp883oXNwJn1BOV6hIE8AwOHmbJPDxkFEbvDpjmTvK6iUHE3ssM jyaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i23-v6si817470pfj.269.2018.10.02.12.05.30; Tue, 02 Oct 2018 12:05:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727775AbeJCBsG (ORCPT + 99 others); Tue, 2 Oct 2018 21:48:06 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:60830 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727407AbeJCBsF (ORCPT ); Tue, 2 Oct 2018 21:48:05 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g7Pwh-0001YL-QZ; Tue, 02 Oct 2018 21:03:00 +0200 Date: Tue, 2 Oct 2018 21:02:59 +0200 (CEST) From: Thomas Gleixner To: Tim Chen cc: Jiri Kosina , Thomas Lendacky , Tom Lendacky , Ingo Molnar , Peter Zijlstra , Josh Poimboeuf , Andrea Arcangeli , David Woodhouse , Andi Kleen , Dave Hansen , Casey Schaufler , Asit Mallick , Arjan van de Ven , Jon Masters , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [Patch v2 3/4] x86/speculation: Extend per process STIBP to AMD cpus. In-Reply-To: <705b51cba5b5e7805aeb08af7f7d21e6ec897a17.1537920575.git.tim.c.chen@linux.intel.com> Message-ID: References: <705b51cba5b5e7805aeb08af7f7d21e6ec897a17.1537920575.git.tim.c.chen@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 Sep 2018, Tim Chen wrote: > From: Thomas Lendacky > > We extend the app to app spectre v2 mitigation using STIBP > to the AMD cpus. We need to take care of special > cases for AMD cpu's update of SPEC_CTRL MSR to avoid double > writing of MSRs from update to SSBD and STIBP. According to documentation changelogs want to be written in imperative mood. > Originally-by: Thomas Lendacky > Signed-off-by: Tim Chen > --- > arch/x86/kernel/process.c | 48 +++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 38 insertions(+), 10 deletions(-) > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index cb24014..4a3a672 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -399,6 +399,10 @@ static __always_inline void set_spec_ctrl_state(unsigned long tifn) > { > u64 msr = x86_spec_ctrl_base; > > + /* > + * AMD cpu may have used a different method to update SSBD, so > + * we need to be sure we are using the SPEC_CTRL MSR for SSBD. This has nothing to do with AMD. If X86_FEATURE_SSBD is not set, the SSBD bit is not to be touched. > + */ > if (static_cpu_has(X86_FEATURE_SSBD)) > msr |= ssbd_tif_to_spec_ctrl(tifn); > > @@ -408,20 +412,45 @@ static __always_inline void set_spec_ctrl_state(unsigned long tifn) > wrmsrl(MSR_IA32_SPEC_CTRL, msr); > } > > -static __always_inline void __speculative_store_bypass_update(unsigned long tifn) > +static __always_inline void __speculative_store_bypass_update(unsigned long tifp, > + unsigned long tifn) > { > - if (static_cpu_has(X86_FEATURE_VIRT_SSBD)) > - amd_set_ssb_virt_state(tifn); > - else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD)) > - amd_set_core_ssb_state(tifn); > - else > - set_spec_ctrl_state(tifn); > + bool stibp = !!((tifp ^ tifn) & _TIF_STIBP); > + bool ssbd = !!((tifp ^ tifn) & _TIF_SSBD); > + > + if (!ssbd && !stibp) > + return; > + > + if (ssbd) { > + /* > + * For AMD, try these methods first. The ssbd variable will > + * reflect if the SPEC_CTRL MSR method is needed. > + */ > + ssbd = false; > + > + if (static_cpu_has(X86_FEATURE_VIRT_SSBD)) > + amd_set_ssb_virt_state(tifn); > + else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD)) > + amd_set_core_ssb_state(tifn); > + else > + ssbd = true; > + } > + > + /* Avoid a possible extra MSR write, recheck the flags */ > + if (!ssbd && !stibp) > + return; > + > + set_spec_ctrl_state(tifn); Uuurgh. This is context switch code and it results in a horrible assembly maze. Also the function name is bogus now. It's not only dealing with SSB anymore. Please stop glueing stuff into the code as you see fit. Something like the below creates halfways sensible code. static __always_inline void spec_ctrl_update_msr(unsigned long tifn) { u64 msr = x86_spec_ctrl_base; if (static_cpu_has(X86_FEATURE_SSBD)) msr |= ssbd_tif_to_spec_ctrl(tifn); wrmsrl(MSR_IA32_SPEC_CTRL, msr); } static __always_inline void spec_ctrl_update(unsigned long tifp, unsigned long tifn) { bool updmsr = !!((tifp ^ tifn) & _TIF_STIBP); if ((tifp ^ tifn) & _TIF_SSBD) { if (static_cpu_has(X86_FEATURE_VIRT_SSBD)) amd_set_ssb_virt_state(tifn); else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD)) amd_set_core_ssb_state(tifn); else if (static_cpu_has(X86_FEATURE_SSBD)) updmsr = true; } if (updmsr) spec_ctrl_update_msr(tifn); } void speculation_ctrl_update(unsigned long tif) { preempt_disable(); spec_ctrl_update(~tif, tif); preempt_enable(); } Hmm? Thanks, tglx