Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp230587imu; Tue, 27 Nov 2018 11:30:14 -0800 (PST) X-Google-Smtp-Source: AJdET5ch3+Fqc0SOU8vOayV724RWznQOzSjeXHc0rgSUeILCcPdWFuR6OXCh5d7YoM8nl4Vb2naW X-Received: by 2002:a62:2bd4:: with SMTP id r203-v6mr34321881pfr.105.1543347014699; Tue, 27 Nov 2018 11:30:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543347014; cv=none; d=google.com; s=arc-20160816; b=L7bmPeP6uJz9ACnRYd/YYVLKx4iw7y8LPr2p0CECQLX2CzhXC31IJdCmM/S3YiHiwO +oIf5SX2uSGGvpATZPPh/FAsmwylw+pmeb3SWJVHMhIW1K07fAhXRs+SFSj7KZ0MVJ48 jcwDLe4ri1GscEHnxhTZWFbSIhO+OdExCk684XGDZrRc78NUs0YgNIB1TnznjYfiMtrK zqD2nPdJw544yfEYFoG9cJjLBAvzd32OTbjEBGZtdrIp6KUNkHO98VKf/sHFtQlKObn7 xliyVG5z2mhJdMmTEZ8C0qjZRYg1HvT61tTF16CLhxXRaUCSHAgXIEh+XAHvBHmET7j9 cpgQ== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=24wB8o9yeOrlXfiLJvH4k2tbDIfY5VU2bEKRSqp25ew=; b=TPZPEBq5ppydH9fKAzvQK4WpEj/oAUu/PQ8mOvtvcSFCpumikc/QdHH2KfvQunqjGr IIn3W5PHgWiZyAXlkhDS/sDmTRINZJJz40NyrfVXnpnd8Df/P//UHDOA/o7BgaL01W2Z GKYxXroSBKA8RfLPivy/p7EHjPxIE56mGgzUbyvKomJHbNy/3RNZnXRcNnyvHpPO2ZZM nSescAeOyfk4Tdx4C/8EgeIH+tjHzMOsPO0yOoP84pdubc3I/RwC+MgBpU/k2TgSbfmy ZZ+VXp0AD+znwA3QAxNjIiiHohRIF3PJ8cxCmlNXlvkuHldOdJtDWTopBn1yb5SIiQJz PiZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=s9fhQcrG; 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 r2si4401017pgk.389.2018.11.27.11.29.59; Tue, 27 Nov 2018 11:30:14 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=s9fhQcrG; 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 S1726812AbeK1GVe (ORCPT + 99 others); Wed, 28 Nov 2018 01:21:34 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:40084 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbeK1GVd (ORCPT ); Wed, 28 Nov 2018 01:21:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=24wB8o9yeOrlXfiLJvH4k2tbDIfY5VU2bEKRSqp25ew=; b=s9fhQcrG0zzOc5AJVBlXRFQRlq Xzrh4d4AfAD07j7rCT+S+yyhF2AEAg/b1zMyIFlg8Sd8Jqsrlqgcjwv+TSV7+RlankzN5ZiUmFMIj Qxxm3cgcrvUNJTu/cKYve9upcj7kayKvuV3xRsYd3ieULNSuWAuG+sbKnUzq+AKaqinuUGv0eQtSA Cm9rd8ZKFo2FV7CMFDzlwsQcK/iydp7H+zub1f4hJ3qg8fc1xWwpwfAMW4yIsTcTsWDaJisAalNYV 7r7n83xWYTBoJAvtzCg7B91LQhcXdbYvNcy0W3G20q2bR7ZNwGtwBMfal/CnZUELF6oX/MIiK6tvG V+xhMSTA==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1gRiwM-000712-NA; Tue, 27 Nov 2018 19:22:34 +0000 Date: Tue, 27 Nov 2018 11:22:34 -0800 From: Matthew Wilcox To: "Paul E. McKenney" Cc: Andrea Parri , Will Deacon , corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Benjamin Herrenschmidt , Arnd Bergmann , David Laight , Alan Stern , Peter Zijlstra Subject: Re: [PATCH] docs/memory-barriers.txt: Enforce heavy ordering for port I/O accesses Message-ID: <20181127192234.GF10377@bombadil.infradead.org> References: <1543251134-29867-1-git-send-email-will.deacon@arm.com> <20181126193349.GA3509@andrea> <20181127184021.GS4170@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20181127184021.GS4170@linux.ibm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 27, 2018 at 10:40:21AM -0800, Paul E. McKenney wrote: > On Mon, Nov 26, 2018 at 08:33:49PM +0100, Andrea Parri wrote: > > On Mon, Nov 26, 2018 at 04:52:14PM +0000, Will Deacon wrote: > > > David Laight explains: > > > > > > | A long time ago there was a document from Intel that said that > > > | inb/outb weren't necessarily synchronised wrt memory accesses. > > > | (Might be P-pro era). However no processors actually behaved that > > > | way and more recent docs say that inb/outb are fully ordered. > > > > No intention to diminish David Laight's authority of course, but I would > > have really appreciated a reference to these "recent docs" (section, pg. > > or the like, especially if a reference manual...) here... > > I would be inclined to cut Will a break given the research for his > recent talk on this topic, but it would be good to get an ack from > someone from Intel. And memory-model patches require an ack or better > in any case. ;-) Here's a quote from Section 18.6 of volume 1 of the Software Developer Manual, November 2018 edition: When the I/O address space is used instead of memory-mapped I/O, the situation is different in two respects: • The processor never buffers I/O writes. Therefore, strict ordering of I/O operations is enforced by the processor. (As with memory-mapped I/O, it is possible for a chip set to post writes in certain I/O ranges.) • The processor synchronizes I/O instruction execution with external bus activity (see Table 18-1). Table 18-1 says that in* delays execution of the current instruction until completion of pending stores, and out* delays execution of the _next_ instruction until completion of both pending stores and the current store.