All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>, x86-ml <x86@kernel.org>,
	linux-tip-commits@vger.kernel.org, hpa@zytor.com,
	gregkh@linuxfoundation.org, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, mingo@kernel.org
Subject: Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits
Date: Sat, 27 Jan 2018 10:37:22 +0100	[thread overview]
Message-ID: <20180127093722.t6dn4sgocihjjq37@pd.tnic> (raw)
In-Reply-To: <1517045268.30244.305.camel@infradead.org>

On Sat, Jan 27, 2018 at 09:27:48AM +0000, David Woodhouse wrote:
> http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
> tree?

@@ -223,7 +223,7 @@ static inline void indirect_branch_prediction_barrier(void)
 				 "movl %[val], %%eax\n\t"
 				 "movl $0, %%edx\n\t"
 				 "wrmsr",
-				 X86_FEATURE_IBPB)
+				 X86_FEATURE_USE_IBPB)

I still don't think that's the right approach: I'd call the
software-defined, synthetic features

X86_FEATURE_IBPB
X86_FEATURE_IBRS
X86_FEATURE_STIBP

then make *them* visible in /proc/cpuinfo and use them everywhere in the
code.

Only the vendor-specific detection code will set the synthetic ones when
it detects a corresponding vendor-specific one.

This way one *only* concentrates on the three above everywhere and
only low-level, early, vendor-specific code takes care to set the
corresponding synthetic features based on the actual hardware bits it
detects.

I think that unifies the view both to the user *and* to the rest of the
kernel which should not care about the actual name of a hardware feature
bit.

And then you avoid coders scratching heads, asking, so what should I
use, X86_FEATURE_IBPB or X86_FEATURE_USE_IBPB.

Instead you call IBPB the synthetic one and the hardware feature name is
something different like PRED_CMD or so. This will drop the confusion
additionally.

I hope that makes sense.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  reply	other threads:[~2018-01-27  9:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25 16:14 [PATCH v5 0/7] Basic Speculation Control feature support David Woodhouse
2018-01-25 16:14 ` [PATCH v5 1/7] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf David Woodhouse
2018-01-26 14:59   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-25 16:14 ` [PATCH v5 2/7] x86/cpufeatures: Add Intel feature bits for Speculation Control David Woodhouse
2018-01-26 15:00   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-25 16:14 ` [PATCH v5 3/7] x86/cpufeatures: Add AMD " David Woodhouse
2018-01-25 21:30   ` Borislav Petkov
2018-01-25 21:37     ` Thomas Gleixner
2018-01-25 21:41     ` Borislav Petkov
2018-01-26 15:00   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-26 18:41     ` [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits Borislav Petkov
2018-01-26 18:45       ` David Woodhouse
2018-01-26 18:49         ` Borislav Petkov
2018-01-26 21:06           ` Tom Lendacky
2018-01-26 21:52             ` Borislav Petkov
2018-01-26 21:59               ` David Woodhouse
2018-01-26 22:10                 ` Borislav Petkov
2018-01-26 23:14                   ` Tom Lendacky
2018-01-27  8:49                     ` David Woodhouse
2018-01-27  9:27                     ` David Woodhouse
2018-01-27  9:37                       ` Borislav Petkov [this message]
2018-01-27 10:32                         ` David Woodhouse
2018-01-27 13:18                           ` Borislav Petkov
2018-01-25 16:14 ` [PATCH v5 4/7] x86/msr: Add definitions for new speculation control MSRs David Woodhouse
2018-01-26 15:00   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-25 16:14 ` [PATCH v5 5/7] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown David Woodhouse
2018-01-25 18:10   ` Dave Hansen
2018-01-25 19:53     ` Dave Hansen
2018-01-25 22:00   ` Borislav Petkov
2018-01-26 15:01   ` [tip:x86/pti] x86/pti: Do not enable PTI on CPUs " tip-bot for David Woodhouse
2018-01-25 16:14 ` [PATCH v5 6/7] x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes David Woodhouse
2018-01-26 15:01   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-25 16:14 ` [PATCH v5 7/7] x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support David Woodhouse
2018-01-26 15:02   ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-01-26 16:18     ` David Woodhouse
2018-01-26 21:36   ` [PATCH v5 7/7] " Tim Chen

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=20180127093722.t6dn4sgocihjjq37@pd.tnic \
    --to=bp@alien8.de \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.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 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.