From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 16:04:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3382D935; Fri, 12 Oct 2012 16:04:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 08D398FC14; Fri, 12 Oct 2012 16:04:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B5C3C46B09; Fri, 12 Oct 2012 12:04:27 -0400 (EDT) Date: Fri, 12 Oct 2012 17:04:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin Subject: Re: No bus_space_read_8 on x86 ? In-Reply-To: <201210121131.46373.jhb@freebsd.org> Message-ID: References: <506DC574.9010300@intel.com> <201210091154.15873.jhb@freebsd.org> <5075EC29.1010907@intel.com> <201210121131.46373.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Carl Delsey X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:04:28 -0000 On Fri, 12 Oct 2012, John Baldwin wrote: >>>> I believe it was because bus reads weren't guaranteed to be atomic on >>>> i386. don't know if that's still the case or a concern, but it was an >>>> intentional omission. >>> True. If you are on a 32-bit system you can read the two 4 byte values >>> and then build a 64-bit value. For 64-bit platforms we should offer >>> bus_read_8() however. >> >> I believe there is still no way to perform a 64-bit read on a i386 (or at >> least without messing with SSE instructions), but if you have to read a >> 64-bit register, you are stuck with doing two 32-bit reads and >> concatenating them. I figure we may as well provide an implementation for >> those who have to do that as well as the implementation for 64-bit. > > I think the problem though is that the way you should glue those two 32-bit > reads together is device dependent. I don't think you can provide a > completely device-neutral bus_read_8() on i386. We should certainly have it > on 64-bit platforms, but I think drivers that want to work on 32-bit > platforms need to explicitly merge the two words themselves. Indeed -- and on non-x86, where there are uncached direct map segments, and TLB entries that disable caching, reading 2x 32-bit vs 1x 64-bit have quite different effects in terms of atomicity. Where uncached I/Os are being used, those differences may affect semantics significantly -- e.g., if your device has a 64-bit memory-mapped FIFO or registers, 2x 32-bit gives you two halves of two different 64-bit values, rather than two halves of the same value. As device drivers depend on those atomicity semantics, we should (at the busspace level) offer only the exactly expected semantics, rather than trying to patch things up. If a device driver accessing 64-bit fields wants to support doing it using two 32-bit reads, it can figure out how to splice it together following bus_space_read_region_4(). Robert