[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2018 14:03:56 +0000
From: "Lendacky, Thomas" <Thomas.Lendacky@....com>
To: Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>
CC: "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Jiri Kosina <jkosina@...e.cz>, Ingo Molnar <mingo@...hat.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH v2] x86/speculation: Add support for STIBP always-on
preferred mode
On 12/11/2018 09:37 PM, Thomas Gleixner wrote:
> On Wed, 12 Dec 2018, Borislav Petkov wrote:
>> On Tue, Dec 11, 2018 at 10:46:16PM +0000, Lendacky, Thomas wrote:
>>> + /*
>>> + * At this point, an STIBP mode other than "off" has been set.
>>> + * If STIBP support is not being forced, check if STIBP always-on
>>> + * is preferred.
>>> + */
>>> + if (mode != SPECTRE_V2_USER_STRICT &&
>>> + boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON)) {
>>> + stibp_always_on = true;
>>> + mode = SPECTRE_V2_USER_STRICT;
>>> + pr_info("mitigation: STIBP always-on is preferred\n");
>>> + }
>>> +
>>> /* Initialize Indirect Branch Prediction Barrier */
>>> if (boot_cpu_has(X86_FEATURE_IBPB)) {
>>> setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
>>> @@ -1088,7 +1102,8 @@ static char *stibp_state(void)
>>> case SPECTRE_V2_USER_NONE:
>>> return ", STIBP: disabled";
>>> case SPECTRE_V2_USER_STRICT:
>>> - return ", STIBP: forced";
>>> + return stibp_always_on ? ", STIBP: always-on"
>>> + : ", STIBP: forced";
>>
>> I still don't like that separate stibp_always_on variable when we can do
>> all the querying just by using mode and X86_FEATURE_AMD_STIBP_ALWAYS_ON.
>
> Hmmm. I've not seen the V1 of this (it's not in my inbox) but the v1->v2
> changes contain:
That's strange, you were on the cc: list. Anyway, here's a link to the
first version: https://lkml.org/lkml/2018/12/11/1248
>
>>> - Removed explicit SPECTRE_V2_USER_STRICT_PREFERRED mode
>
> Now I really have to ask why?
>
> Neither the extra variable nor the cpu feature check are pretty. An
> explicit mode is way better in terms of code clarity and you get the proper
> printout via spectre_v2_user_strings.
>
> Hmm?
That is what the first version did. See if that's in-line with what
you're thinking.
Thanks,
Tom
>
> tglx
>
Powered by blists - more mailing lists