Received: by 10.192.165.148 with SMTP id m20csp528955imm; Wed, 2 May 2018 04:43:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrSY0IlRuy8HRnzRJlyFqRed7qTS2wMoC+uhzF99s9pkP7Cy+Xo0dc27xL4COTmw+q6vSOQ X-Received: by 2002:a17:902:8d83:: with SMTP id v3-v6mr4909458plo.33.1525261384755; Wed, 02 May 2018 04:43:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525261384; cv=none; d=google.com; s=arc-20160816; b=gf/c2OPnyKcIioyZu05xOHRSHlzEIAuZK2ssJOjsLXKujYeGpbmSTuse4RGVMpQZ5M wquiqpkhUn/uun1CK/3msB17lxRSL3gXzFfNqiICZ2cQaOSlYJuQOm6QGS7QclhWfmZt en9KpnSpmpG7O/JLgISR0TGVSedj/d4LcDputb0rSSJkBXB+oU22lWassfoIiN+pKn9S OmGswLUm1lFFCRQM5xTYNRYAqDtaycf2yiFrDn7tsKa8Ne1JKKvz5Fo9aj31dkz5JASO WQXcad3b/eE537Z1jdS4HDEuLXcPFjSB+sd14HaeZCJFpVwFQ202v5GwGVy9I4Fs/nkc m0oQ== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=LbP5ZjMzIIsFxLXjpX4p7W4qapGMoj+MjjnoJ8SQyfI=; b=Ud7wFAPeBOBKGOFHmRMwWW/l5oD4e4mOj3qfcjnUw2k6MNFQ83OGugFh7RlvKYC2bN u2+W1LmPa8MvhF+CUtpKWerZzMKojWwZmVy3EcuE0z8jEFv8q5u03CnVJhfTC5ZxCLGW psslCK+Uh7zdrirITCywgzURan3G4Yt3xXoyTpEMtKiEkObcq1DU5h3IM0Qf6bEfPgUY mMvNXjRBke70JAaVTQQr/wJW6IHYFNqMPELxXtV/s1qEsHVsg+v54G9y5z5YQTehtqw2 5XdCKaCo4CvJeEXDU1TdI8Anws+qzqb0Sb94PIAfOQr9t8UehS3iws8XJgNtBd94MbI5 MYvQ== 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 b73-v6si9524128pga.106.2018.05.02.04.42.50; Wed, 02 May 2018 04:43:04 -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 S1751464AbeEBLlc convert rfc822-to-8bit (ORCPT + 99 others); Wed, 2 May 2018 07:41:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:35248 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbeEBLlb (ORCPT ); Wed, 2 May 2018 07:41:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 338A1AD5E; Wed, 2 May 2018 11:41:30 +0000 (UTC) Date: Wed, 2 May 2018 13:41:28 +0200 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: Michael Ellerman 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 Message-ID: <20180502134128.4a31b0fc@kitsune.suse.cz> In-Reply-To: <87vac7r5px.fsf@concordia.ellerman.id.au> References: <20180424041559.32410-1-mpe@ellerman.id.au> <20180424041559.32410-4-mpe@ellerman.id.au> <20180426180258.04e6bee6@kitsune.suse.cz> <87vac7r5px.fsf@concordia.ellerman.id.au> Organization: SUSE Linux X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-suse-linux-gnu) 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 On Tue, 01 May 2018 21:11:06 +1000 Michael Ellerman wrote: > 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. Right, I was looking at an older implementation which turned off both v1 and v2 with same parameter. In current kernel the v1 mitigation is not turned off at all. > > Which is not to say we can't add one, but I wasn't sure if it was > really worth it. The current thinking is that most performance relevant cases are covered with array_nospec which has little overhead. The less code we have for this the better ;-) Thanks Michal