Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753566AbeAFVl6 (ORCPT + 1 other); Sat, 6 Jan 2018 16:41:58 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:40014 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751399AbeAFVl4 (ORCPT ); Sat, 6 Jan 2018 16:41:56 -0500 Date: Sat, 6 Jan 2018 16:41:38 -0500 From: Konrad Rzeszutek Wilk To: "Van De Ven, Arjan" Cc: Thomas Gleixner , "Hansen, Dave" , Konrad Rzeszutek Wilk , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , David Woodhouse , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature Message-ID: <20180106214138.GL19213@char.us.oracle.com> References: <20180106144110.GA2592@localhost.localdomain> <742ed1d9-7210-8443-0373-5af74f193ab9@intel.com> <0575AF4FD06DD142AD198903C74E1CC87A56C6FE@ORSMSX103.amr.corp.intel.com> <20180106213227.GJ19213@char.us.oracle.com> <0575AF4FD06DD142AD198903C74E1CC87A56C8AE@ORSMSX103.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A56C8AE@ORSMSX103.amr.corp.intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8766 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801060314 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Jan 06, 2018 at 09:34:01PM +0000, Van De Ven, Arjan wrote: > > I agree. But this is what customers are told to inspect to see if they > > are impacted. And if in the future versions this goes away or such - they > > will freak out and cause needless escalations. > > > it's a mistake though... retpoline is what people should be using .... > ... and only in super exception cases should IBRS even be considered Like on certain Skylake and Broadwell where using the retpoline won't suffice? As you can imagine having an heuristic that will figure out if: - The CPU is doing the correct thing, retpoline or IBRS is not needed at all. - The CPU can do retpoline, use that instead. - The CPU is unsafe to do retpoline, use IBRS. - The CPU can do retpoline, but MSRS are faster (is that even the case?) - The CPU hasn't been updated, the retpolines are unsafe, the only solution is to buy a new CPU. And have all of this nicely rolled out to customers in an 'sysfs' that will tell the customers - yes your are safe. All I m saying is that the 'ibrs_enabled' is a bad name, it should be something else altogether.