From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95E66C46470 for ; Wed, 8 Aug 2018 13:01:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55694219E8 for ; Wed, 8 Aug 2018 13:01:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55694219E8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727304AbeHHPUx convert rfc822-to-8bit (ORCPT ); Wed, 8 Aug 2018 11:20:53 -0400 Received: from eu-smtp-delivery-211.mimecast.com ([146.101.78.211]:41631 "EHLO eu-smtp-delivery-211.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727274AbeHHPUx (ORCPT ); Wed, 8 Aug 2018 11:20:53 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-127-zYzYkRyqPYe78HSMLppyOA-1; Wed, 08 Aug 2018 14:01:14 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Aug 2018 14:02:54 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 8 Aug 2018 14:02:54 +0100 From: David Laight To: 'Catalin Marinas' , Matt Sealey CC: Mikulas Patocka , Thomas Petazzoni , Joao Pinto , Ard Biesheuvel , linux-pci , Jingoo Han , Will Deacon , Russell King , "Linux Kernel Mailing List" , linux-arm-kernel Subject: RE: framebuffer corruption due to overlapping stp instructions on arm64 Thread-Topic: framebuffer corruption due to overlapping stp instructions on arm64 Thread-Index: AQHULxGqyzS7gP0u+Em6lFS72D3AkaS10FEA Date: Wed, 8 Aug 2018 13:02:54 +0000 Message-ID: References: <20180803094129.GB17798@arm.com> <20180808121641.GB24736@iMac.local> In-Reply-To: <20180808121641.GB24736@iMac.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] MIME-Version: 1.0 X-MC-Unique: zYzYkRyqPYe78HSMLppyOA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Catalin Marinas > Sent: 08 August 2018 13:17 ... > I think hazarding is what goes wrong here, especially since with > overlapping unaligned addresses. However, I disagree that it is > impossible to implement this properly on a platform with PCIe so that > Normal NC mappings can be used. I've been trying to follow this discussion... Is the problem just that reads don't snoop/flush the write-combining buffer? Aligned writes that end on an appropriate boundary will leave the write combining buffer empty. But if the buffer isn't emptied the PCIe read gets ahead of the PCIe write. ISTR even x86 requires a fence instruction in some sequence associated with write-combining writes. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)