Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp970995img; Thu, 28 Feb 2019 10:46:27 -0800 (PST) X-Google-Smtp-Source: APXvYqwX09XMsr1V2g2DS+1txBlfCHMUMpM/j16t7Z7VbrOOo26+P7YWlYmJPTF2YMm6Y3DdmsWF X-Received: by 2002:a17:902:a414:: with SMTP id p20mr787371plq.289.1551379587876; Thu, 28 Feb 2019 10:46:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551379587; cv=none; d=google.com; s=arc-20160816; b=r18lf6hvrHCuj52pX6njWyQdulA4Oqgjj7YYghK85kVkHX+022hjMl0xJjXKVM4lvq IxaMWEuKsQfYgxrp1tOFUNft6nGJfX2WTYDmUOj/KuvpccKqHtkdvF7wwj1eDRn7LqQK gQRo3W5cYD/DPhd7cm23iAe6ZLiJksUeAY0JY/K8VnDuYBIH6j6UxJEHHMAnaip7Q2t/ wosh0cBt3OiVuDrHxKr4DGQbzJ7eyPTCIAcmro6OZdff4X+Y1CDznBN5a4g21e4pyEQr jbZmpKvzX9EZFOJzdU+K2tKzA9awz9jpgfYhy24MmPAgOLVzby2RW6i9jSEodqkVZBNr dJBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jqTSC3jMb1KVZ+74cQn/AHnKt4bCuX4HnuZQ4OeVpM0=; b=NAMRCDx1eqLblC+X+qKWHAGiNCH2m5MvNOzXtYcX+G4TLiVYngqLvX4C+ycGNqEM85 1CAiQcuFx8qjRSDLE5s48GW6yhDvvhp8a5U7jaokfsyb5TW80x6wjGRuxODUdSZpCax7 mK1WNgTv0oLWdpIX0Y1gDI85FSErjwKKcbAXBfB3XbZiurA7Wsxnr8ppx56LdZ3jpAgb ezVAIJYbnLFnQzZ+gOtyfrWJMNy4PN2MlDRPJMSq1037SGI1ZoP27/gPb91Rh6jQcrri tFja1HRjHMTgQS26ZkzraB1YUN6S64RiCCewe2gZ95q2HZFcdTUIRU6M8zU6XxR9VPtJ JPKQ== 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 d130si17853086pgc.232.2019.02.28.10.46.12; Thu, 28 Feb 2019 10:46:27 -0800 (PST) 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 S1732563AbfB1SVd (ORCPT + 99 others); Thu, 28 Feb 2019 13:21:33 -0500 Received: from foss.arm.com ([217.140.101.70]:52454 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbfB1SVc (ORCPT ); Thu, 28 Feb 2019 13:21:32 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED7D5EBD; Thu, 28 Feb 2019 10:21:31 -0800 (PST) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9329F3F5C1; Thu, 28 Feb 2019 10:21:29 -0800 (PST) Date: Thu, 28 Feb 2019 18:21:27 +0000 From: Catalin Marinas To: Suzuki K Poulose Cc: jeremy.linton@arm.com, linux-arm-kernel@lists.infradead.org, will.deacon@arm.com, marc.zyngier@arm.com, dave.martin@arm.com, shankerd@codeaurora.org, julien.thierry@arm.com, mlangsdo@redhat.com, stefan.wahren@i2e.com, andre.przywara@arm.com, linux-kernel@vger.kernel.org, corbet@lwn.net, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 01/10] arm64: Provide a command line to disable spectre_v2 mitigation Message-ID: <20190228182126.GA252518@arrakis.emea.arm.com> References: <20190227010544.597579-1-jeremy.linton@arm.com> <20190227010544.597579-2-jeremy.linton@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 28, 2019 at 06:14:34PM +0000, Suzuki K Poulose wrote: > On 27/02/2019 01:05, Jeremy Linton wrote: > > There are various reasons, including bencmarking, to disable spectrev2 > > mitigation on a machine. Provide a command-line to do so. > > > > Signed-off-by: Jeremy Linton > > Cc: Jonathan Corbet > > Cc: linux-doc@vger.kernel.org > > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > > index 9950bb0cbd52..d2b2c69d31bb 100644 > > --- a/arch/arm64/kernel/cpu_errata.c > > +++ b/arch/arm64/kernel/cpu_errata.c > > @@ -220,6 +220,14 @@ static void qcom_link_stack_sanitization(void) > > : "=&r" (tmp)); > > } > > +static bool __nospectre_v2; > > +static int __init parse_nospectre_v2(char *str) > > +{ > > + __nospectre_v2 = true; > > + return 0; > > +} > > +early_param("nospectre_v2", parse_nospectre_v2); > > + > > static void > > enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry) > > { > > @@ -231,6 +239,11 @@ enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry) > > if (!entry->matches(entry, SCOPE_LOCAL_CPU)) > > return; > > + if (__nospectre_v2) { > > + pr_info_once("spectrev2 mitigation disabled by command line option\n"); > > + return; > > + } > > + > > Could we not disable the "cap" altogether instead, rather than disabling the > work around ? Or do we need that information ? There are a few ideas here but I think we settled on always reporting in sysfs even if the mitigation is disabled in .config. So I guess we need the "cap" around for the reporting part. -- Catalin