[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d65cbf8c-27b6-63fb-23ce-d26017953245@intel.com>
Date: Mon, 30 Jul 2018 07:29:09 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Tim C Chen <tim.c.chen@...el.com>,
Ravi Shankar <ravi.v.shankar@...el.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] x86/speculation: Support Enhanced IBRS on future CPUs
On 07/30/2018 05:25 AM, Thomas Gleixner wrote:
> On Tue, 24 Jul 2018, Sai Praneeth Prakhya wrote:
>> From: Sai Praneeth <sai.praneeth.prakhya@...el.com>
>> Some future Intel processors may support "Enhanced IBRS" which is an
>> "always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and
>> never disabled. According to specification[1], this should simplify
>> software enabling and improve performance.
> SHOULD is not really helpful. The question is whether it does improve
> performance in practice or not. You really want to add numbers comparing
> retpoutine and enhanced IBRS.
One thing to remember from Intel's retpoline paper:
> Retpoline is known to be an effective branch target injection
> (Spectre variant 2) mitigation on Intel processors belonging to
> family 6 (enumerated by the CPUID instruction) that do not have
> support for enhanced IBRS. On processors that support enhanced IBRS,
> it should be used for mitigation instead of retpoline.
That's both a statement of "Intel would like you to use enhanced IBRS
over retpoline where available" and "retpoline provides less mitigation
on processors with enhanced IBRS compared to those without".
In other words, we can _do_ performance deltas, but they won't be as
meaningful because they won't really have apples-to-apples mitigation
properties.
Powered by blists - more mailing lists