Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964884AbeAJNKO (ORCPT + 1 other); Wed, 10 Jan 2018 08:10:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57410 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751165AbeAJNKN (ORCPT ); Wed, 10 Jan 2018 08:10:13 -0500 Date: Wed, 10 Jan 2018 14:10:10 +0100 From: Andrea Arcangeli To: David Woodhouse Cc: Jiri Kosina , Peter Zijlstra , Dave Hansen , Thomas Gleixner , LKML , Linus Torvalds , x86@kernel.org, Borislav Petkov , Tim Chen , Andi Kleen , Greg KH , Andy Lutomirski , Arjan Van De Ven Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code Message-ID: <20180110131010.GK9706@redhat.com> References: <1515585534.22302.122.camel@infradead.org> <20180110120158.GB9706@redhat.com> <1515586174.22302.126.camel@infradead.org> <20180110121755.GD9706@redhat.com> <1515587384.22302.132.camel@infradead.org> <20180110124119.GG9706@redhat.com> <1515588673.22302.139.camel@infradead.org> <20180110130202.GI9706@redhat.com> <20180110130551.GJ9706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110130551.GJ9706@redhat.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 10 Jan 2018 13:10:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 10, 2018 at 02:05:51PM +0100, Andrea Arcangeli wrote: > Also note, the slowdown of setting IBRS varies with older CPUs being To give a further detail, older CPUs to provide IBRS semantics have to do something even less finegrined that doesn't just restricts speculation across IBRS less privileged prediction level, that doesn't just restrict speculation across indirect branches, that doesn't just restrict indirect branch prediction, but that shuts down a whole block of the CPU to achieve those super finegrined theoretical IBRS semantics that matches future silicon. IBRS is doing a lot more than what it would be needed because there was no other way to achieve it on some microcode implementations. Which is why ibrs_enabled 1 is needed to achieve better performance as you don't want to run slower while in user mode, much better to pay the cost of setting IBRS and shutting down that part of the CPU. It's still incredibly faster to shutdown part of the CPU temporarily than to flush its internal state as a whole with IBPB. If it wouldn't be the case ibrs_enabled 0 ibpb_enabled 2 special mode would perform better (but that's only enabled by default if SPEC_CTRL is not available and only IBPB_SUPPORT is). Thanks, Andrea