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:   Sat, 27 Jan 2018 10:37:22 +0100
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
Message-ID: <20180127093722.t6dn4sgocihjjq37@pd.tnic>
References: <tip-5d10cbc91d9eb5537998b65608441b592eec65e7@git.kernel.org>
 <20180126184139.rcfbtk7dvj7kmyfn@pd.tnic>
 <1516992318.30244.271.camel@infradead.org>
 <20180126184915.ioqewp56orj2qhrt@pd.tnic>
 <7094ed9b-40f7-ba2b-55a6-cc5ab0b06bb9@amd.com>
 <20180126215209.vqdxh5p672tcdst6@pd.tnic>
 <1517003984.30244.299.camel@infradead.org>
 <20180126221026.hc2hk23zsqbqhkif@pd.tnic>
 <2cea933f-7e06-26d5-95cf-41df8308a0f8@amd.com>
 <1517045268.30244.305.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1517045268.30244.305.camel@infradead.org>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.