All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>,
	Andrew Lutomirski <luto@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	John Stultz <john.stultz@linaro.org>
Subject: Re: [RFC PATCH 4/4] x86/TSC: Use RDTSCP
Date: Tue, 11 Dec 2018 18:24:44 -0800	[thread overview]
Message-ID: <CALCETrXvZ4avdUh2bTLVTTz3Jxogo3zK5akWTsJ=rkJpf1XiDg@mail.gmail.com> (raw)
In-Reply-To: <20181211233901.GV27375@zn.tnic>

> On Dec 11, 2018, at 3:39 PM, Borislav Petkov <bp@alien8.de> wrote:
>
>> On Tue, Dec 11, 2018 at 11:12:41PM +0000, Lendacky, Thomas wrote:
>> It does seem overloaded in that sense, but the feature means that LFENCE
>> is serializing and so can be used in rdtsc_ordered. In the same sense,
>> barrier_nospec is looking for whether LFENCE is serializing and preferring
>> that over MFENCE since it is lighter weight.
>>
>> In light of how they're being used now, they could probably stand to be
>> renamed in some way.
>
> Actually, come to think of it, what really matters here is whether
> LFENCE is serializing or not. Because if so, you wanna replace with LFENCE
> as it is lighter. And in that case a single alternative() - not _2() -
> should suffice.
>
> BUT(!), that still is not good enough if you do some qemu CPU models
> like pentium or so which don't even have MFENCE and cause stuff like
> this:
>
> https://lkml.kernel.org/r/20181123200307.GA6223@roeck-us.net
>
> Which means, that you *do* have to alternate between
>
> * no insn at all
> * MFENCE
> * LFENCE, if it is serializing
>
> so barrier_nospec() does the right thing, AFAICS. And this is why we
> need an ALTERNATIVE_3() to add RDTSCP into the mix too.
>
> WRT renaming, I guess we can do something like:
>
> * X86_FEATURE_MFENCE_RDTSC -> X86_FEATURE_MFENCE - to mean that CPU has
> MFENCE support.
>
> and
>
> * X86_FEATURE_LFENCE_RDTSC -> X86_FEATURE_LFENCE_SERIALIZING
>
> Or something to that effect.

This makes me nervous, since no one knows what “serializing” means.
IIRC AMD specifically documents that MFENCE is required before RDTSC
to get sensible ordering.  So it’s entirely plausible to me that
LFENCE is okay for Spectre mitigation but MFENCE is needed for RDTSC
on some CPU.

  reply	other threads:[~2018-12-12  2:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 22:23 [RFC PATCH 0/4] x86/alternative: Add ALTERNATIVE_3 Borislav Petkov
2018-12-11 22:23 ` [RFC PATCH 1/4] x86/alternatives: Add macro comments Borislav Petkov
2019-01-16 11:57   ` [tip:x86/alternatives] " tip-bot for Borislav Petkov
2018-12-11 22:23 ` [RFC PATCH 2/4] x86/alternatives: Print containing function Borislav Petkov
2019-01-16 11:58   ` [tip:x86/alternatives] " tip-bot for Borislav Petkov
2018-12-11 22:23 ` [RFC PATCH 3/4] x86/alternatives: Add an ALTERNATIVE_3() macro Borislav Petkov
2019-01-16 11:59   ` [tip:x86/alternatives] " tip-bot for Borislav Petkov
2018-12-11 22:23 ` [RFC PATCH 4/4] x86/TSC: Use RDTSCP Borislav Petkov
2018-12-11 22:59   ` Andy Lutomirski
2018-12-11 23:12     ` Lendacky, Thomas
2018-12-11 23:39       ` Borislav Petkov
2018-12-12  2:24         ` Andy Lutomirski [this message]
2018-12-12  9:59           ` Peter Zijlstra
2018-12-12 12:02             ` Andrea Parri
2018-12-12 10:08           ` Borislav Petkov
2018-12-12 18:07             ` Andy Lutomirski
2018-12-12 18:44               ` Borislav Petkov
2018-12-12 18:50                 ` Andy Lutomirski
2018-12-12 20:00                   ` Borislav Petkov
2018-12-12 20:09                     ` Andy Lutomirski
2018-12-12 20:29                       ` Borislav Petkov
2018-12-14 13:39                 ` David Laight
2018-12-15 18:53                   ` Andy Lutomirski
2018-12-12 14:15           ` Lendacky, Thomas
2018-12-12 14:18             ` Lendacky, Thomas
2018-12-11 23:37 Alexey Dobriyan
2018-12-11 23:43 ` Borislav Petkov
2018-12-12  0:06   ` Borislav Petkov

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='CALCETrXvZ4avdUh2bTLVTTz3Jxogo3zK5akWTsJ=rkJpf1XiDg@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.