[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce6c99be-b8ea-f789-ca7c-625c99b2a7a2@intel.com>
Date: Tue, 9 Jan 2018 18:02:53 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>,
David Woodhouse <dwmw@...zon.co.uk>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
Greg KH <gregkh@...uxfoundation.org>,
Andy Lutomirski <luto@...nel.org>,
Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
code
On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd {
> SPECTRE_V2_CMD_RETPOLINE,
> SPECTRE_V2_CMD_RETPOLINE_GENERIC,
> SPECTRE_V2_CMD_RETPOLINE_AMD,
> + SPECTRE_V2_CMD_IBRS,
> };
A few nits on this:
IBRS should not default on anywhere, which goes double when retpolines
are available.
I think I'd also prefer that we separate the IBRS and retpoline enabling
so that you can do both if you want. They do nearly the same thing in
practice, but I can't convince myself that you never ever need IBRS once
retpolines are in place.
Powered by blists - more mailing lists