[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0575AF4FD06DD142AD198903C74E1CC87A572A2C@ORSMSX103.amr.corp.intel.com>
Date: Wed, 10 Jan 2018 18:47:08 +0000
From: "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
Tim Chen <tim.c.chen@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
David Woodhouse <dwmw@...zon.co.uk>,
"Williams, Dan J" <dan.j.williams@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 3/5] x86/enter: Use IBRS on syscall and interrupts
> On SKL+ retpoline is mostly there, but has a few dinky holes in and it
> _might_ make sense to use IBRS.
>
> But I feel it needs explaining what the exact holes are (pjt and dwmw2
> had a fair enumeration IIRC) such that people can judge the risk.
you are correct to need and want this.
the problem is one of patch sequencing a bit;
as retpoline is now it has more of these dinky holes, in the next few days
patches will flow that will fix a bunch of these.
I would like to suggest we do the documentation part after a few days once
we know how much of these we can reasonable pre-plug.
but yes we must do this tradeoff documentation.
Powered by blists - more mailing lists