Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp744563imu; Fri, 25 Jan 2019 10:10:21 -0800 (PST) X-Google-Smtp-Source: ALg8bN56psB7rH/nD6fZAaeJu6dwH3hg0CydbQWWBtqVZxWVI5RGONwlModdJN9eqyFGYdwceRj2 X-Received: by 2002:a63:5d55:: with SMTP id o21mr10636334pgm.92.1548439820955; Fri, 25 Jan 2019 10:10:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548439820; cv=none; d=google.com; s=arc-20160816; b=yOQ1GvGdcl4B/y08pF7syjZ/nnQbmkLh5pu3bVqjBtHpgZ85BGa3LoT1iIMvH44Q8B JEQ2fZqQDoHtjz2VX1QKNV68tJmZ0z+t1ha3qwCHNA+Hv2NpaatGxefGY+0dtXTVOuLl VouQcGHvJzgzkiHyQbCAFZRqdhqZY4ISZQ0cUIRq1I9tXlWDeohrY2qjLzfjjqtCsl5r Mvf/MDAoJeGDwkFGJNgtW3mhFBgfvcEOAqG37EBhdvPZuTeT+Sn6KjKe0VJvPcpbZADH 8jN+jLEfpN0JaRkwa/CGsrm90xtDlcN/XXqXfVQtgnw4qSKZ/Vt4ZN6WIt1+iOQLQBgN iw2Q== 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=0fgXYBXbvf0NQqvfuSWQeLHce3/z9bx83k5RIBu3pXQ=; b=KIPW5vRsiXn5jp2NG6V63NWG+7VQlo1JCygO3xatwE3zaPW1TT5PPxXTAqi/lvXFj5 QSNu5eOmpsIAXS7nfuG21V6oH3HvIhARvaXZvV37AkINzDJ6lqJgnMB+1BY0vqVrOBBv YA9h+Qmxnkgk8uSQwBrjYwF3U59SrkmaPD8YrrdF3jZ3xcg8HjAnXhP7FyeFKIDgjzQX T2RFaap3CwP4Cwro5viC3ycutg/EhSAY3kz5KCQ3PoJCPpS4VmY/1rQioAnuaW80lu+H 0O9RvARNAsjn/n3zQDByEVFkNKd9AOvYAbdL2W1h6Oxs+iVVN9hEimNTcmGMGdg6m8b0 2xpw== 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 n78si25472689pfi.235.2019.01.25.10.10.05; Fri, 25 Jan 2019 10:10:20 -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 S1729559AbfAYSIT (ORCPT + 99 others); Fri, 25 Jan 2019 13:08:19 -0500 Received: from foss.arm.com ([217.140.101.70]:52006 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729531AbfAYSIS (ORCPT ); Fri, 25 Jan 2019 13:08:18 -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 951841596; Fri, 25 Jan 2019 10:08:17 -0800 (PST) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.113]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 85BE93F5AF; Fri, 25 Jan 2019 10:08:16 -0800 (PST) Date: Fri, 25 Jan 2019 18:08:14 +0000 From: Catalin Marinas To: "Zhang, Lei" Cc: 'Mark Rutland' , "'linux-arm-kernel@lists.infradead.org'" , "'will.deacon@arm.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [PATCH v2 1/1] arm64: Add workaround for Fujitsu A64FX erratum 010001 Message-ID: <20190125180813.GM25901@arrakis.emea.arm.com> References: <8898674D84E3B24BA3A2D289B872026A6A2A32D6@G01JPEXMBKW03> <8898674D84E3B24BA3A2D289B872026A6A2A32EB@G01JPEXMBKW03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8898674D84E3B24BA3A2D289B872026A6A2A32EB@G01JPEXMBKW03> 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 Tue, Jan 22, 2019 at 08:54:33AM +0000, Zhang, Lei wrote: > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > index efb7b2c..37e4f18 100644 > --- a/arch/arm64/mm/fault.c > +++ b/arch/arm64/mm/fault.c > @@ -666,6 +666,28 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) > return 0; > } > > +static int do_bad_unknown_63(unsigned long addr, unsigned int esr, struct pt_regs *regs) > +{ > + /* > + * On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), > + * memory accesses may spuriously trigger data aborts with > + * DFSC=0b111111. > + */ > + if (IS_ENABLED(CONFIG_FUJITSU_ERRATUM_010001)) { > + if (cpus_have_cap(ARM64_WORKAROUND_FUJITSU_A64FX_0100001)) { > + return 0; > + } else { /* cpu capabilities maybe not ready*/ > + unsigned int current_cpu_midr = read_cpuid_id(); > + const struct midr_range fujitsu_a64fx_midr_range = { > + MIDR_FUJITSU_A64FX, MIDR_CPU_VAR_REV(0, 0), MIDR_CPU_VAR_REV(1, 0) > + }; > + if (is_midr_in_range(current_cpu_midr, &fujitsu_a64fx_midr_range) == TRUE) > + return 0; > + } > + } > + return do_bad(addr, esr, regs); > +} IIUC, this can happen very early when the errata framework isn't yet ready. Given that this is not on a fast path (you already took a fault), I don't think it's worth optimising for cpus_have_cap() (and ARM64_WORKAROUND_FUJITSU_A64FX_0100001). I've seen Mark's comments on why checking MIDR in a preemptible context is not a good idea but I suspect your platform is homogeneous (i.e. not big.LITTLE). -- Catalin