Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5988872imu; Wed, 30 Jan 2019 07:01:18 -0800 (PST) X-Google-Smtp-Source: AHgI3IYKolGs1CXAGl4cd5n7rdhdf9HqKJgOIHKro8RDtTSnOsXE+M0aqdWQPvIUs/kc+T+eOQTK X-Received: by 2002:a63:287:: with SMTP id 129mr4554186pgc.332.1548860478619; Wed, 30 Jan 2019 07:01:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548860478; cv=none; d=google.com; s=arc-20160816; b=vFk71gQ45zg8vw65tAWJO4sI1g8zK0wcykIlpsBHx5cNtB4hbesSA2c6SfmWTBwYmW kNvI28kxp/Vc1p7j8jUYzmFiWc4NJMn8q/A65R7QnF+RK081bWAkRE1o/lUl2iP2G0rZ 6AqCDGmGjoXaIxyhU3Rs6hHyUB4UiHOEqx7gUuuedHOUIFZuxbBwsHrs31sVCNfgbtgq gHQiG1WQtwhxKUKAI4ITJF8L7dxT5GFQD9RwHglM29RHEJTjOL+J3e9xMvUKmUXUDOV6 35VZaIP1MWrzYY+kTei9ZRnp8QIeVvLi6otcfF3VAXEOSYWflR0fULguegzmGJSF4lq/ 6BRg== 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:cc:from:references:to:subject; bh=hjvuISBj2ztoeQO6MLVgR0uD61GzcdHXqFPQpyydub4=; b=j9jQMMSVTHp/qptbXwNSqJGzfLWaLTppKSNt6fyAMRWFxIn1adGiyNp5633b/6jNKI gjbSuzwoKAtQr8XjF9VnQ8wmOJfT29bPN6VV3uOqwprWb08tNz7A/rt8DkH2FPFBnYFN CEtkkfMCR/xZ+m1z+EFV5SzJCAase6gOIN81W1WYwHft1VUZ8mt4bzqh+skUrmHkrm8U SaGNIcTgMs7jQwaSToEBPQzgvIIpe623JzaKufJsa1qByRpC6hv2GRR0hSA30NvkQBYC 0x9gosf+C/97UakUMxzHPI2/vsU68y1wpdcqISKE4ZE/h5BSZo7KOamt9kAEo1YKsZTw r/iw== 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 p64si1683570pfg.79.2019.01.30.07.00.58; Wed, 30 Jan 2019 07:01:18 -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 S1731283AbfA3PAc (ORCPT + 99 others); Wed, 30 Jan 2019 10:00:32 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55694 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727162AbfA3PAb (ORCPT ); Wed, 30 Jan 2019 10:00:31 -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 9CAC7EBD; Wed, 30 Jan 2019 07:00:31 -0800 (PST) Received: from [10.37.9.196] (unknown [10.37.9.196]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D38463F589; Wed, 30 Jan 2019 07:00:29 -0800 (PST) Subject: Re: [PATCH v3 0/1] arm64: Add workaround for Fujitsu A64FX erratum 010001 To: "Zhang, Lei" References: <8898674D84E3B24BA3A2D289B872026A6A2C04E6@G01JPEXMBKW03> From: James Morse Cc: 'Catalin Marinas' , "'linux-kernel@vger.kernel.org'" , 'Mark Rutland' , "'linux-arm-kernel@lists.infradead.org'" , "'will.deacon@arm.com'" Message-ID: Date: Wed, 30 Jan 2019 15:00:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8898674D84E3B24BA3A2D289B872026A6A2C04E6@G01JPEXMBKW03> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On 01/29/2019 12:29 PM, Zhang, Lei wrote: > On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), > memory accesses may cause undefined fault (Data abort, DFSC=0b111111). > This problem will be fixed by next version of Fujitsu-A64FX. > > This fault occurs under a specific hardware condition > when a load/store instruction perform 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. > And this fault occurs completely spurious. > > Since TCR_ELx.NFD1 is set to '1' at the kernel in versions > past 4.17, the case-3 or case-4 may happen. e03e61c3173c ("arm64: kaslr: Set TCR_EL1.NFD1 when CONFIG_RANDOMIZE_BASE=y") ? So you'd never see it if you disabled CONFIG_RANDOMIZE_BASE? Thanks, James