linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Andi Kleen <ak@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Casey Schaufler <casey.schaufler@intel.com>,
	Asit Mallick <asit.k.mallick@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Jon Masters <jcm@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [Patch v2 3/4] x86/speculation: Extend per process STIBP to AMD cpus.
Date: Tue, 2 Oct 2018 21:02:59 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1810022000000.1435@nanos.tec.linutronix.de> (raw)
In-Reply-To: <705b51cba5b5e7805aeb08af7f7d21e6ec897a17.1537920575.git.tim.c.chen@linux.intel.com>

On Tue, 25 Sep 2018, Tim Chen wrote:
> From: Thomas Lendacky <Thomas.Lendacky@amd.com>
> 
> 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 <Thomas.Lendacky@amd.com>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
>  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

  parent reply	other threads:[~2018-10-02 19:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26  0:43 [Patch v2 0/4] Provide options to enable spectre_v2 userspace-userspace protection Tim Chen
2018-09-26  0:43 ` [Patch v2 1/4] x86/speculation: Option to select app to app mitigation for spectre_v2 Tim Chen
2018-10-02  9:23   ` Ingo Molnar
2018-10-02 16:24     ` Tim Chen
2018-10-02 20:04   ` Thomas Gleixner
2018-09-26  0:43 ` [Patch v2 2/4] x86/speculation: Provide application property based STIBP protection Tim Chen
2018-10-02 19:10   ` Thomas Gleixner
2018-10-04 19:19     ` Tim Chen
2018-09-26  0:43 ` [Patch v2 3/4] x86/speculation: Extend per process STIBP to AMD cpus Tim Chen
2018-09-26 17:24   ` Tim Chen
2018-09-26 19:11     ` Lendacky, Thomas
2018-10-02  9:27   ` Ingo Molnar
2018-10-02 19:02   ` Thomas Gleixner [this message]
2018-09-26  0:43 ` [Patch v2 4/4] x86/speculation: Add prctl to control indirect branch speculation per process Tim Chen
2018-10-02  9:35   ` Ingo Molnar
2018-10-02 16:12     ` Tim Chen
2018-10-03  7:25       ` Ingo Molnar
2018-10-02 17:58   ` Thomas Gleixner
2018-10-05 18:12     ` Tim Chen
2018-10-05 18:46       ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1810022000000.1435@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=Thomas.Lendacky@amd.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=casey.schaufler@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=jcm@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).