From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from baldur.buserror.net (baldur.buserror.net [165.227.176.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 40xhNw535TzDrYj for ; Fri, 1 Jun 2018 08:05:52 +1000 (AEST) Message-ID: <1527804215.30674.35.camel@buserror.net> From: Scott Wood To: Diana Madalina Craciun , Michael Ellerman , "linuxppc-dev@lists.ozlabs.org" Cc: Leo Li Date: Thu, 31 May 2018 17:03:35 -0500 In-Reply-To: References: <1526973031-9543-1-git-send-email-diana.craciun@nxp.com> <1527020969.30674.13.camel@buserror.net> <1527621245.30674.30.camel@buserror.net> <87wovjykh8.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Subject: Re: [RFC PATCH] powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book E List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2018-05-31 at 14:35 +0000, Diana Madalina Craciun wrote: > On 5/31/2018 5:21 PM, Michael Ellerman wrote: > > > > We can add a nospectre_v1 command line option if necessary. > > What about nobarrier_nospec (or similar) instead of nospectre_v1 command > line? We are not disabling all the v1 mitigations, the masking part will > remain unchanged. I think nospectre_v1 makes more sense as it's about the user's intentions rather than the implementation. The user is giving the kernel permission to not defend against spectre v1, and it's up to the implementation which mitigations (if any) to disable in response to that, same as any other optimization. -Scott