Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4705898imc; Mon, 25 Feb 2019 09:29:56 -0800 (PST) X-Google-Smtp-Source: AHgI3IYXKlQK5iP1q6SbFq8iFpxczl6O/lAeDB/j4aLljY+n5baF5lplQNOGxMgulgw2MFAtfj4U X-Received: by 2002:a63:ca:: with SMTP id 193mr20195863pga.288.1551115796861; Mon, 25 Feb 2019 09:29:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551115796; cv=none; d=google.com; s=arc-20160816; b=DxbocXi0RKVHhIxQzI5obNCEVKycOdnkCRIon8OoKZFcAszU16q+FlWsUZVtSe1JLo bM3ARL+fYMXZQ9C1IE86Dec51DAM2oOm6xAuchBPgA1AHQ4nBXmRb5QW5ClyzynmgMgy cTaoMt3S79UTechkF20Fc9nhs9RkdPXibr5sb3oDYqnmO8j98HAk4lj2gTZ5lMMJa8rE daNQhqcbofataUrPvcZm6mGOwJ6Ed0Tm7dlKOdem7foGDc7FjIqy/5BJCyjm3YgdbyzU qqBB5AnFvyGf99h0QD304DGdG00qUgdZ1/29sFU0va9BhJg3mj8FPuqf9M0hCkODoORh 7JLg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=ZiG5QUsS4wZZxHO1FhSxpaAYZTrdGRy4aFDQhrjdNBs=; b=xH52U2cm0caVG9durVF7y5hoIhmWRYpVeKLEnVXQhreL7UK/W0Qny5Ol5p/n2BH3SA uFcCXCr6CtiT7unTm/VsPyODRmqXaFXx8c/mzDdlr/Hw7b1LAJ0+QZVb0FedWizjEWKt +z6nZx9omZJSJWhDFhTp8jkh3SqV65VH+wuO5g3isD6MFYIKVf/iHLVmpFp0nTjY4t2Z jcdbQB3Rqq3wxYxGsNHWiJphL0NvtDCnhnSN8pc+lhFHe0qyOgMsstWAdLQLPK0xncvu DdWmyXQJx5sAo1U/9ENu/1LxbL9ycoT/j4u86fRaX32OsRCDwfSfkLmvIRn4BKTa6h6X /QRw== 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 j39si10333447plb.272.2019.02.25.09.29.41; Mon, 25 Feb 2019 09:29:56 -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 S1728748AbfBYR3K (ORCPT + 99 others); Mon, 25 Feb 2019 12:29:10 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35420 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728400AbfBYR3K (ORCPT ); Mon, 25 Feb 2019 12:29:10 -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 DFDA880D; Mon, 25 Feb 2019 09:29:09 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CEF673F703; Mon, 25 Feb 2019 09:29:08 -0800 (PST) Subject: Re: [PATCH v4] arm64: Add workaround for Fujitsu A64FX erratum 010001 To: "Zhang, Lei" Cc: Mark Rutland , 'Catalin Marinas' , 'Will Deacon' , "'linux-kernel@vger.kernel.org'" , "'linux-arm-kernel@lists.infradead.org'" References: <8898674D84E3B24BA3A2D289B872026A6A311EAE@G01JPEXMBKW03> <20190214155605.GC27547@lakrids.cambridge.arm.com> <90347cf4-4d7b-d553-d4db-1bacd000ff75@arm.com> <8898674D84E3B24BA3A2D289B872026A6A313313@G01JPEXMBKW03> <8898674D84E3B24BA3A2D289B872026A6A319D26@G01JPEXMBKW03> From: James Morse Message-ID: Date: Mon, 25 Feb 2019 17:29:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <8898674D84E3B24BA3A2D289B872026A6A319D26@G01JPEXMBKW03> Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zhang, On 23/02/2019 13:06, Zhang, Lei wrote: > Zhang, Lei wrote: >> I think you mean it may be a problem to modify the KPTI trampoline because >> some patches about KPTI will be merged to mainline in the near future. >> I understood that. >> I should discuss with my colleagues whether we can set NFDx=0 all of time on >> A64FX. > > The result of our investigation also supports your suggestion. > We surely agree with you that your proposed method (never set NFDx=1 on A64FX) > is the best to resolve this erratum. > > For this erratum, James's patch should be merged to mainline > instead of my previous patches (v1 to v4). > Since KPTI fully covers the effect of NFD1 for A64FX, KPTI is > recommended to be used in conjunction with James’s patch. >> And thanks for your patch. >> If we can set NFDx=0 all of time, I will review, test and report the result. > > I have already tested James's patch on A64FX, and the result is no problem at all. > > Tested-by:zhang.lei Thanks, I'll post it properly with this tag. >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index >> a4168d366127..b0b7f1c4e816 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -643,6 +643,25 @@ config QCOM_FALKOR_ERRATUM_E1041 >> >> If unsure, say Y. >> >> +config FUJITSU_ERRATUM_010001 >> + bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly" >> + default y >> + help >> + This option adds workaround for Fujitsu-A64FX erratum E#010001. >> + On some variants of the Fujitsu-A64FX cores version (1.0, 1.1), memory >> + accesses may cause undefined fault (Data abort, DFSC=0b111111). >> + This fault occurs under a specific hardware condition when a >> + load/store instruction performs an address translation using: >> + case-1 TTBR0_EL1 with TCR_EL1.NFD0 == 1. >> + case-2 TTBR0_EL2 with TCR_EL2.NFD0 == 1. >> + case-3 TTBR1_EL1 with TCR_EL1.NFD1 == 1. >> + case-4 TTBR1_EL2 with TCR_EL2.NFD1 == 1. >> + >> + The workaround is to ensure these bits are clear in TCR_ELx. >> + The workaround only affect the Fujitsu-A64FX. > > I think it is better to add a notice here as follows: > > Recommend to enable KPTI (UNMAP_KERNEL_AT_EL0 = y). That unmap option is on by default, you can't turn it off without CONFIG_EXPERT. While I agree, I don't think we need to spell this out. Thanks, James