[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180123232235.GT7844@tassilo.jf.intel.com>
Date: Tue, 23 Jan 2018 15:22:35 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: "Woodhouse, David" <dwmw@...zon.co.uk>
Cc: "thomas.lendacky@....com" <thomas.lendacky@....com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"ashok.raj@...el.com" <ashok.raj@...el.com>,
"Raslan, KarimAllah" <karahmed@...zon.de>,
"arjan.van.de.ven@...el.com" <arjan.van.de.ven@...el.com>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"bp@...e.de" <bp@...e.de>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Janakarajan.Natarajan@....com" <Janakarajan.Natarajan@....com>,
"tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"joro@...tes.org" <joro@...tes.org>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"aarcange@...hat.com" <aarcange@...hat.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"luto@...nel.org" <luto@...nel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"dave.hansen@...el.com" <dave.hansen@...el.com>,
"luto@...capital.net" <luto@...capital.net>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"asit.k.mallick@...el.com" <asit.k.mallick@...el.com>,
"jun.nakajima@...el.com" <jun.nakajima@...el.com>,
"labbott@...hat.com" <labbott@...hat.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
Indirect Branch Speculation
On Tue, Jan 23, 2018 at 11:14:36PM +0000, Woodhouse, David wrote:
> On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote:
> > > Not sure. Maybe to start, the answer might be to allow it to be set for
> > > the ultra-paranoid, but in general don't enable it by default. Having it
> > > enabled would be an alternative to someone deciding to disable SMT, since
> > > that would have even more of a performance impact.
> >
> > I agree. A reasonable strategy would be to only enable it for
> > processes that have dumpable disabled. This should be already set for
> > high value processes like GPG, and allows others to opt-in if
> > they need to.
>
> That seems to make sense, and I think was the solution we were
> approaching for IBPB on context switch too, right?
Right.
-Andi
Powered by blists - more mailing lists