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;
Date:   Wed, 12 Dec 2018 02:37:53 +0300
From:   Alexey Dobriyan <adobriyan@gmail.com>
To:     luto@kernel.org
Cc:     linux-kernel@vger.kernel.org, tglx@linutronix.de, bp@suse.de,
        thomas.lendacky@amd.com, hpa@zytor.com, john.stultz@linaro.org,
        x86@kernel.org
Subject: Re: [RFC PATCH 4/4] x86/TSC: Use RDTSCP
Message-ID: <20181211233753.GA26593@avx2>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> And I had a bit of a WTF moment, as in "WTF does
> RDTSC have to do with a speculation protection barrier".
> Does it actually make sense?

It doesn't. There was too much s/lfence/barrier_nospec/ apparently.

> +	asm volatile(ALTERNATIVE_3("rdtsc",
> +				   "mfence; rdtsc", X86_FEATURE_MFENCE_RDTSC,
> +				   "lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
> +				   "rdtscp", X86_FEATURE_RDTSCP)
> +			: EAX_EDX_RET(val, low, high)
> +			/* RDTSCP clobbers ECX with MSR_TSC_AUX. */
> +			:: "ecx");

I have a question: does alternatives ordering matter? CPU can have
both features.

And other code in this file uses "c" for clobber.