Received: by 10.192.165.148 with SMTP id m20csp4801277imm; Tue, 1 May 2018 04:11:36 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpyKdIhkFGtC7e+hp6c2d5/nHAUPdnRz4Tc9v37p7HvtNsZycsrKLdHqNe95Z8ytM5eFlwP X-Received: by 10.98.33.151 with SMTP id o23mr15382172pfj.202.1525173096938; Tue, 01 May 2018 04:11:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525173096; cv=none; d=google.com; s=arc-20160816; b=TmgnT/sg3yQPpACqtmciyjE2/CRpcBgYNjAHlhKKRCIwZ9sCLXVEV+7cE4nb936B5o EsJBkzcJ4P7GXduXxTCEju0xSZyMP7QVwn8rz2LaaxB98cZFLlOkX7qPgzze9cmh6F94 qFODzjqciDppNuZrCWBb7QemdCX3ailBtE+TyBZl9cnNz4ZQemz2U9o7U2fRqMKK/xXR BW3O8o4Gdpgh7L+v5v7bNARRBC5tlwRBFXwLw0YZh0YXNeuh1dtjN2cRX27Bnb8utFMp UxKZqCOXVapLceY2KCiFyBjQJBDrobplze5ipK4tjGXnL9xyJ341tuDnrgJBSLvDrppV DMBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :arc-authentication-results; bh=wvJddpQPWBOGqp0ZIVx0vt9paSlH128CaaPn/uB86xU=; b=RqDdAx4a9r0CqPyxRM0LEI0Et0O1iycSHgBs8gtCvSBqgOYt7s+LvZ9tTG+qR8ECVf WYaWMRTT94x0YIIc4O3vZKhAqF8l0HXEunnBBMGOLA+mIdOeQlQYLyW9npiVYl2AHATw qH0e0ZSfBh2b4YTLW9cFwzpuzTosCpXtlGqwyLUeYWcr6lvoXxb1A60IVKMCoHYICUkp sNCUifdrlMHM+wgwWWQu76YaqOoWhNF3X0DDLBXwT1amsDKPVoj4v2kXKLtG7Pty+RCt UyXK9yVLEu4LvoYTCcXAahL+v6sBsw01+Vr+fzSG+Uc4/T9NGIbPF4mSsxj15xUUm8qh 4jHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n4-v6si7690810pgu.687.2018.05.01.04.11.22; Tue, 01 May 2018 04:11:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754523AbeEALLM convert rfc822-to-8bit (ORCPT + 99 others); Tue, 1 May 2018 07:11:12 -0400 Received: from ozlabs.org ([203.11.71.1]:48289 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753856AbeEALLK (ORCPT ); Tue, 1 May 2018 07:11:10 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 40ZzHJ2DSKz9s2k; Tue, 1 May 2018 21:11:08 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Michal =?utf-8?Q?Such=C3=A1nek?= Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org, npiggin@gmail.com Subject: Re: [PATCH 4/6] powerpc/64s: Enable barrier_nospec based on firmware settings In-Reply-To: <20180426180258.04e6bee6@kitsune.suse.cz> References: <20180424041559.32410-1-mpe@ellerman.id.au> <20180424041559.32410-4-mpe@ellerman.id.au> <20180426180258.04e6bee6@kitsune.suse.cz> Date: Tue, 01 May 2018 21:11:06 +1000 Message-ID: <87vac7r5px.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Suchánek writes: > Hello, > > On Tue, 24 Apr 2018 14:15:57 +1000 > Michael Ellerman wrote: > >> From: Michal Suchanek >> >> Check what firmware told us and enable/disable the barrier_nospec as >> appropriate. >> >> We err on the side of enabling the barrier, as it's no-op on older >> systems, see the comment for more detail. >> >> Signed-off-by: Michael Ellerman ... > > I am missing the option for the barrier to be disabled by a kernel > commandline argument here. > > It does make sense to add a kernel parameter that is checked on boot to > be compatible with other platforms that implement one. No other platforms have an option to disable variant 1 mitigations, so there isn't an existing parameter we can use. Which is not to say we can't add one, but I wasn't sure if it was really worth it. But I guess we should add one, I might do it as a follow-up patch. cheers