From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id F1CA77D089 for ; Tue, 27 Nov 2018 19:22:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726340AbeK1GVd (ORCPT ); Wed, 28 Nov 2018 01:21:33 -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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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.