Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3894303imm; Mon, 6 Aug 2018 12:28:44 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcYrMCLmpqEXAsiL7xSbbqOyQEI/gAF01H0rFK9oUAOhGKVTr7z/LATkQWN4r6Ql2IzSM9w X-Received: by 2002:a17:902:bd4a:: with SMTP id b10-v6mr15119654plx.209.1533583724357; Mon, 06 Aug 2018 12:28:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533583724; cv=none; d=google.com; s=arc-20160816; b=rEXtLsChpiM2kUcZn/TpoinGgr19PZEwFUS2w1pPtVqeblrEiT9TzYBvaYsTE/ffZ6 MnpveI/81I+DjcJHm3S/yj/qfzmDOqiBjIMK77rm36OszqKiUCMgn/2sDbfjPN6RKDIC pyLxo+nkT/EWNKjjyPL3sgFy8ljJRbl0Ek2+iyl0HSugDGry/qFHMuwcg5D3KAZ+zkcp U+BFgtu9hZMKMnecjMIsTMmhf6ZM3vMlkCVmQbkqnMFiNPa7QppyYZM30l3Vqy7qievv SyKdlSQGcCmLyhDT7Xa54auRASuZEiE1PjCGBzoSlwAlW+NcDyZn1kPlA4jPq8tQu3YJ rL2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=og55HE4hlGpsSAfftRfbzLhcNwVrXOhmkjhoQYF4bDY=; b=p+nzY4M3DLVQLVuv0EJLyVL4ls5kAQJI6fpwYKx+y4AnQAOnHpUsuVOrWdWFqwdxYS HBEr8D/2k+EPtAxJyzkGf0GtBFwVxZFMXjSknH0lUy1NQCAFSGg6TIKZSD8znsqOWnse wXo39wMvQOwyB2KO0qx184EJZmNEhvzVDQoAGCf6DiM6ROCXkeLKy2q9qHyUzPTVsT9C 59D/ampzRFh+2kYM8drTtKU43/DXUwNAO5YkE/St6gGNxo83F7q1PGUk2J0DJlN6tO49 Xjc5WuM0bCKMP9IHklvs1UflSYHLPtQ6g+1A31Vo/1bTof3FbyFzKnXn4zaShlf9uni6 KPMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Vyw8gubQ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k17-v6si14846277pfj.321.2018.08.06.12.28.28; Mon, 06 Aug 2018 12:28:44 -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; dkim=pass header.i=@linaro.org header.s=google header.b=Vyw8gubQ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732659AbeHFTbm (ORCPT + 99 others); Mon, 6 Aug 2018 15:31:42 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:45518 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726279AbeHFTbm (ORCPT ); Mon, 6 Aug 2018 15:31:42 -0400 Received: by mail-io0-f170.google.com with SMTP id k16-v6so11632217iom.12 for ; Mon, 06 Aug 2018 10:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=og55HE4hlGpsSAfftRfbzLhcNwVrXOhmkjhoQYF4bDY=; b=Vyw8gubQnZT5Jdo8eLAB8vXWWv31wdn7WFl4EzJzodNzPf+8Ic8QTAJSplMFKznGUW VXr9Q67xuR/GagjMJGOQCbj8B9KrMMczWPv1+WqSM0x7TYN5Prhc026f+vH5jJWtopG2 itjuSatjDkj7U8Onl7W6Icwwosk+ZHYGLiqzo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=og55HE4hlGpsSAfftRfbzLhcNwVrXOhmkjhoQYF4bDY=; b=DMPyWxqzNzd2Wvjie9TnvDpjI0v4qErXGXaOt4L/+gJw4XQp8KQIwjqqNOsf1Zfbr1 Mh+Etlsu58jQ9GUwamcuOLXDJDdie3a2LleS+M/PaCcgs2m2/kaqNDkLKNpfvSeR2JQp JX6KkbGqtwef5bzd3qY9C3Ff8yJqshH2+JHwpzfudLnZdiNNbmfKwXeHC9UAa6oHWHTm DzmGLCmoua55N57c/aWqrnz6CMde4q/hJ9Q6+8KONKclOySbfpw2Ystdg1hNMZuGmdX3 Agv0/JzGmbFLO3VoXoeN32jfp2L18OiQf4/0y+4S4muFHw6OuDUK6LUxVGNyCd90QsDF JvYw== X-Gm-Message-State: AOUpUlHflRPvgfCc9hTddyGXcRUknG90uZ1gpLNtdahYgNfK6eUaK76w F7EedGM7NApIgWqEwkJ7EWAQ06dKwhozxtVAMA2b0A== X-Received: by 2002:a6b:5208:: with SMTP id g8-v6mr16616138iob.60.1533576098187; Mon, 06 Aug 2018 10:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:ac05:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 10:21:37 -0700 (PDT) In-Reply-To: References: <20180803094129.GB17798@arm.com> <99fff4fe-afa9-f12f-a518-472a9dd1c530@arm.com> From: Ard Biesheuvel Date: Mon, 6 Aug 2018 19:21:37 +0200 Message-ID: Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64 To: Mikulas Patocka Cc: Robin Murphy , Thomas Petazzoni , Joao Pinto , linux-pci , Jingoo Han , Will Deacon , Russell King , Linux Kernel Mailing List , Matt Sealey , Catalin Marinas , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6 August 2018 at 19:09, Mikulas Patocka wrote: > > > On Mon, 6 Aug 2018, Ard Biesheuvel wrote: > >> On 6 August 2018 at 14:42, Robin Murphy wrote: >> > On 06/08/18 11:25, Mikulas Patocka wrote: >> > [...] >> >>> >> >>> None of this explains why some transactions fail to make it across >> >>> entirely. The overlapping writes in question write the same data to >> >>> the memory locations that are covered by both, and so the ordering in >> >>> which the transactions are received should not affect the outcome. >> >> >> >> >> >> You're right that the corruption couldn't be explained just by reordering >> >> writes. My hypothesis is that the PCIe controller tries to disambiguate >> >> the overlapping writes, but the disambiguation logic was not tested and it >> >> is buggy. If there's a barrier between the overlapping writes, the PCIe >> >> controller won't see any overlapping writes, so it won't trigger the >> >> faulty disambiguation logic and it works. >> >> >> >> Could the ARM engineers look if there's some chicken bit in Cortex-A72 >> >> that could insert barriers between non-cached writes automatically? >> > >> > >> > I don't think there is, and even if there was I imagine it would have a >> > pretty hideous effect on non-coherent DMA buffers and the various other >> > places in which we have Normal-NC mappings of actual system RAM. >> > >> >> Looking at the A72 manual, there is one chicken bit that looks like it >> may be related: >> >> CPUACTLR_EL1 bit #50: >> >> 0 Enables store streaming on NC/GRE memory type. This is the reset value. >> 1 Disables store streaming on NC/GRE memory type. >> >> so putting something like >> >> mrs x0, S3_1_C15_C2_0 >> orr x0, x0, #(1 << 50) >> msr S3_1_C15_C2_0, x0 >> >> in __cpu_setup() would be worth a try. > > It won't boot. > > But if i write the same value that was read, it also won't boot. > > I created a simple kernel module that reads this register and it has bit > 32 set, all other bits clear. But when I write the same value into it, the > core that does the write is stuck in infinite loop. > > So, it seems that we are writing this register from a wrong place. > Ah, my bad. I didn't look closely enough at the description: """ The accessibility to the CPUACTLR_EL1 by Exception level is: EL0 - EL1(NS) RW (a) EL1(S) RW (a) EL2 RW (b) EL3(SCR.NS = 1) RW EL3(SCR.NS = 0) RW (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0. """ so you'll have to do this from ARM Trusted Firmware. If you're comfortable rebuilding that: diff --git a/include/lib/cpus/aarch64/cortex_a72.h b/include/lib/cpus/aarch64/cortex_a72.h index bfd64918625b..a7b8cf4be0c6 100644 --- a/include/lib/cpus/aarch64/cortex_a72.h +++ b/include/lib/cpus/aarch64/cortex_a72.h @@ -31,6 +31,7 @@ #define CORTEX_A72_ACTLR_EL1 S3_1_C15_C2_0 #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH (1 << 56) +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING (1 << 50) #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA (1 << 49) #define CORTEX_A72_ACTLR_DCC_AS_DCCI (1 << 44) #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH (1 << 32) diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S index 55e508678284..5914d6ee3ba6 100644 --- a/lib/cpus/aarch64/cortex_a72.S +++ b/lib/cpus/aarch64/cortex_a72.S @@ -133,6 +133,15 @@ func cortex_a72_reset_func orr x0, x0, #CORTEX_A72_ECTLR_SMP_BIT msr CORTEX_A72_ECTLR_EL1, x0 isb + + /* --------------------------------------------- + * Disables store streaming on NC/GRE memory type. + * --------------------------------------------- + */ + mrs x0, CORTEX_A72_ACTLR_EL1 + orr x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING + msr CORTEX_A72_ACTLR_EL1, x0 + isb ret x19 endfunc cortex_a72_reset_func