Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935052AbeAOQ5O (ORCPT + 1 other); Mon, 15 Jan 2018 11:57:14 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:35003 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935045AbeAOQ5N (ORCPT ); Mon, 15 Jan 2018 11:57:13 -0500 X-Google-Smtp-Source: ACJfBovmE4rWsNtWDtZSrQAnHnkeQp7fc5s3Naac2d82/W7LVPG9U6FyqBQcz45Tta9TjdSoUUW9IA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Improve retpoline for Skylake From: Andy Lutomirski X-Mailer: iPhone Mail (15C202) In-Reply-To: <985f979e-0740-5d8a-d6b8-b023105aa021@jonmasters.org> Date: Mon, 15 Jan 2018 08:57:10 -0800 Cc: Henrique de Moraes Holschuh , Andi Kleen , David Woodhouse , tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, pjt@google.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org, peterz@infradead.org, thomas.lendacky@amd.com, arjan.van.de.ven@intel.com Content-Transfer-Encoding: 8BIT Message-Id: References: <20180112184550.6573-1-andi@firstfloor.org> <1515784373.22302.492.camel@infradead.org> <20180112192126.su2evwfefdfeaa6g@two.firstfloor.org> <20180112220349.7dorb3lde4tffsjm@khazad-dum.debian.net> <985f979e-0740-5d8a-d6b8-b023105aa021@jonmasters.org> To: Jon Masters Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > On Jan 15, 2018, at 12:26 AM, Jon Masters wrote: > >> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: >> On Fri, 12 Jan 2018, Andi Kleen wrote: >>>> Skylake still loses if it takes an SMI, right? >>> >>> SMMs are usually rare, especially on servers, and are usually >>> not very predictible, and even if you have >> >> FWIW, a data point: SMIs can be generated on demand by userspace on >> thinkpad laptops, but they will be triggered from within a kernel >> context. I very much doubt this is a rare pattern... > > Sure. Just touch some "legacy" hardware that the vendor emulates in a > nasty SMI handler. It's definitely not acceptable to assume that SMIs > can't be generated under the control of some malicious user code. > > Our numbers on Skylake weren't bad, and there seem to be all kinds of > corner cases, so again, it seems as if IBRS is the safest choice. > And keep in mind that SMIs generally hit all CPUs at once, making them extra nasty. Can we get firmware vendors to refill the return buffer just before RSM?