From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fHAdu-0000ll-IJ for speck@linutronix.de; Fri, 11 May 2018 18:11:40 +0200 Date: Fri, 11 May 2018 09:11:35 -0700 From: Andi Kleen Subject: [MODERATED] Re: [patch V11 05/16] SSB 5 Message-ID: <20180511161135.GM13616@tassilo.jf.intel.com> References: <20180502215102.192655950@linutronix.de> <20180502215416.459915781@linutronix.de> <20180510175257.GD13616@tassilo.jf.intel.com> <20180510183058.GJ27358@char.us.oracle.com> <20180510190850.GE13616@tassilo.jf.intel.com> <20180510212232.GT27358@char.us.oracle.com> <20180510222533.GH13616@tassilo.jf.intel.com> <20180510235056.GA27882@char.us.oracle.com> MIME-Version: 1.0 In-Reply-To: <20180510235056.GA27882@char.us.oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 10, 2018 at 07:50:56PM -0400, speck for Konrad Rzeszutek Wilk wrote: > On Thu, May 10, 2018 at 03:25:33PM -0700, speck for Andi Kleen wrote: > > > It is actually slower. I tried doing it last time with the spectre/meltdown > > > and the performance was way slower than doing it this way. I can dig up the patches > > > - as I think we did the tests on Broadwell but hadn't tried Skylake or such > > > (or maybe it was the other way around). > > > > Was this with MSR lists unconditionally, or with MSR list combined with > > the "wait for the first write" approach? > > It was the unconditional. The patch went through a bunch of iterations and this My suspicion is that a combination of the two would be best: first wait for the first intercept so no overhead for the case of the guest not using IBRS at all then use the msr save/restore list this is the most efficient way to do save/restore With the new "rare MSR use" we may end up with SSB on Linux it may also be worth to time out the save/restore and go back to intercept, so if SSB is only used temporarily for a short time the exits wouldn't be slower forever just because someone used it temporarily. > It won't apply to 'master' as this was against our heavily backported 4.1 kernel > but you get the idea. Also ignore some of the commit description as we did > eventually figure out the 'very fragile' case. Right that's unconditional. So the "never use MSR" case is definitely slower, which is likely what you saw. -Andi