From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA36BC10F13 for ; Fri, 12 Apr 2019 02:41:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C12CD2083E for ; Fri, 12 Apr 2019 02:41:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726755AbfDLClZ (ORCPT ); Thu, 11 Apr 2019 22:41:25 -0400 Received: from bilbo.ozlabs.org ([203.11.71.1]:41967 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726656AbfDLClY (ORCPT ); Thu, 11 Apr 2019 22:41:24 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 44gMbP2hcyz9s5c; Fri, 12 Apr 2019 12:41:21 +1000 (AEST) From: Michael Ellerman To: Josh Poimboeuf , Thomas Gleixner Cc: Borislav Petkov , linux-kernel@vger.kernel.org, x86@kernel.org, Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Jiri Kosina , Waiman Long , Andrea Arcangeli , Jon Masters , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, Martin Schwidefsky , Heiko Carstens , linux-s390@vger.kernel.org, Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Greg Kroah-Hartman , Tyler Hicks , Linus Torvalds Subject: Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options In-Reply-To: <20190411131540.754t5t4tp55i6vjq@treble> References: <20190405131211.GE23348@zn.tnic> <20190405142048.burthk2jnpcvi2om@treble> <20190405152059.GG23348@zn.tnic> <20190405160136.GI23348@zn.tnic> <20190405161852.nmpk22omgiety4df@treble> <87sguqwgu7.fsf@concordia.ellerman.id.au> <20190411131540.754t5t4tp55i6vjq@treble> Date: Fri, 12 Apr 2019 12:41:21 +1000 Message-ID: <878swguer2.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Josh Poimboeuf writes: > On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote: >> On Wed, 10 Apr 2019, Michael Ellerman wrote: >> > Josh Poimboeuf writes: >> > >> > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: >> > >> Thinking about this more, we can shave off the first 4 chars and have it >> > >> be: >> > >> >> > >> spec_mitigations= >> > >> >> > >> I think it is painfully clear which speculation mitigations we mean. And >> > >> the other switches don't have "cpu_" prefixes too so... >> > > >> > > Sure, I'm ok with renaming it to that, if there are no objections. >> > >> > What about when we have a mitigation for a non-speculation related bug :) >> >> Those kind of silicon bugs are usually mitigated unconditionally. > > Right. > > But at least "mitigations=" is nice and short. We could clarify in the > documentation that it doesn't apply to *all* mitigations, only the ones > which are optional and which can affect performance. > > And it would give us the freedom to include any future "optional" > mitigations, spec or not. > > I kind of like it. But I could go either way. Some of the published SMT attacks are not speculation based. And arguably we already have an optional mitigation for those, ie. nosmt. cheers