[MODERATED] Re: [patch V11 05/16] SSB 5

[Andi Kleen <ak@linux.intel.com>]

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