From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 23 00:18:28 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A01522E5 for ; Tue, 23 Sep 2014 00:18:28 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BED7D4B for ; Tue, 23 Sep 2014 00:18:27 +0000 (UTC) Received: (qmail 9372 invoked from network); 23 Sep 2014 00:18:26 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 23 Sep 2014 00:18:26 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 22 Sep 2014 20:18:26 -0400 (EDT) Received: (qmail 21923 invoked from network); 23 Sep 2014 00:18:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Sep 2014 00:18:26 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 61C741C402C; Mon, 22 Sep 2014 17:18:20 -0700 (PDT) From: Mark Millard Subject: powerpc64/GENERIC64 use of dcbst vs. dcbf: is the dcbst use really okay? Anyone know? Message-Id: <19413BD4-88D5-4897-B50C-48C47F5E2ACA@dsl-only.net> Date: Mon, 22 Sep 2014 17:18:21 -0700 To: FreeBSD PowerPC ML , Nathan Whitehorn , Justin Hibbits Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 00:18:28 -0000 Anyone know why the following is true in FreeBSD (10.1-BETA2, for = example) for kernel vs. openfirmware transitions (in both directions) = for powerpc64/GENERIC64? (And some other places are noted.) The issue is = dcbst vs. dcbf instruction usage. (I later quote from pem_64_bit_v3.0.2005jul2005.pdf (from IBM).) Some context first... Apple's published BootX-81 always saves and restored the Exception = Vectors when going between openfirmware and the kernel: it maintains = separate vectors for the two contexts. In addition it carefully uses = dcbf and icbi no matter if copies to that area at address 0 or to a save = area. And that is followed by isync. (And more, sync and eieio: Apple = seems paranoid.) Apple used dcbf instead of dcbst. IBM writes of dcbst vs. dcbf: > Instruction caches, if they exist, are not required to be consistent = with data caches, memory, or I/O data trans- fers. Software must use the = appropriate cache management instructions to ensure that instruction = caches are kept coherent when instructions are modified by the processor = or by input data transfer. When a processor alters a memory location = that may be contained in an instruction cache, software must ensure that = updates to memory are visible to the instruction fetching mechanism. = Although the instructions to enforce consistency vary among = implementations, the following sequence for a uniprocessor system is = typical:=20 > 1. dcbst (update memory) > 2. sync (wait for update) > 3. icbi (invalidate copy in instruction cache) 4. isync (perform = context synchronization)=20 > Note: Most operating systems will provide a system service for this = function. These operations are neces- sary because the memory may be = designated as write-back. Since instruction fetching may bypass the data = cache, changes made to items in the data cache may not otherwise be = reflected in memory until after the instruction fetch completes.=20 > For implementations used in multiprocessor systems, variations on this = sequence may be recommended. For example, in a multiprocessor system = with a unified instruction/data cache (at any level), if instructions = are fetched without coherency being enforced, the preceding instruction = sequence is inadequate. Because the icbi instruction does not invalidate = blocks in a unified cache, a dcbf instruction should be used instead of = a dcbst instruction for this case. >=20 Then the point given that background information... FreeBSD's powerpc64/GENERIC64 seems to have a mix of dcbst and dcbf use. = The following have dcbst (unless patched separately at run time): 000000000086c1e8 <.agp_apple_unbind_page+0x60> dcbst r0,r0 000000000086c27c <.agp_apple_bind_page+0x64> dcbst r0,r0 00000000008b1b78 <.elf_reloc_internal+0x12c> dcbst r0,r30 00000000008bcd30 <.__syncicache+0x38> dcbst r0,r0 That last is used during the openfirmware vs. kernel transitions. The = above are from "objdump -d --prefix-address /boot/kernel/kernel". Is the dcbst use risky because of any unified caches at any level on any = of the processors that powerpc64/GENERIC64 is supposed to handle? =3D=3D=3D Mark Millard markmi at dsl-only.net