From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 23 02:00:11 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F62F466 for ; Tue, 23 Sep 2014 02:00:11 +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 2400B87D for ; Tue, 23 Sep 2014 02:00:10 +0000 (UTC) Received: (qmail 17585 invoked from network); 23 Sep 2014 02:00:09 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 23 Sep 2014 02:00:09 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 22 Sep 2014 22:00:09 -0400 (EDT) Received: (qmail 16807 invoked from network); 23 Sep 2014 02:00:09 -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 02:00:09 -0000 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 F25651C402C for ; Mon, 22 Sep 2014 19:00:02 -0700 (PDT) From: Mark Millard Subject: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following... Message-Id: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net> Date: Mon, 22 Sep 2014 19:00:07 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 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 02:00:11 -0000 Context: 10.1-BETA2 powerpc64/GENERIC64 (with option DDB and option = GDB). (I later quote from pem_64_bit_v3.0.2005jul2005.pdf (from IBM).) IBM writes of mtmsr/mtmsrd: > For software that will run on processors that comply with = earlier versions of the architecture, a context synchronizing = instruction is required after the mtmsr[d] instruction.=20 That sort of principle does not seem to be followed by one example in = powerpc64/GENERIC64: 0000000000102168 <.__start+0x78> rldimi r9,r8,63,0 000000000010216c <.__start+0x7c> mtmsrd r9 0000000000102170 <.__start+0x80> bl 0000000000101120 = 0000000000102174 <.__start+0x84> ld r2,40(r1) 0000000000102178 <.__start+0x88> lis r3,16 000000000010217c <.__start+0x8c> addi r3,r3,0 ... There other mtmsr's/mtmsrd's that I found had one or two isync's = following, proving the context synchronization instruction. IBM also reports: > Processors designed prior to Version 2.01 of the architecture ignore = the L field. These processors set the MSR as if L were =910=92, and = perform synchronization as if L were =911=92. Therefore software that = uses mtmsrd and runs on such processors must obey the following rules. >=20 > If L=3D =921=92, the contents of bits of register rS other than bits = [48] and [62] must be such that if L were =910=92 the instruction would = not alter the contents of the corresponding MSR bits.=20 > If L =3D =910=92 and the instruction alters the contents of any of the = MSR bits listed below, the instruction must be followed by a context = synchronizing instruction or event in order to ensure that the context = alteration caused by the mtmsrd instruction has taken effect on such = processors.=20 > To obtain the best performance on processors, if the context = synchronizing instruction is isync the isync should immediately follow = the mtmsrd. (Some such processors treat an isync instruction that = immediately follows an mtmsrd instruction having L =3D =920=92 as a = no-op, thereby avoiding the performance penalty of a second context = synchronization.) >=20 Another interesting IBM note for mtmsr (not mtmsrd), but effectively = just a side note here: > The mtmsr instruction, which is otherwise illegal in the 64-bit = architecture may optionally be imple- mented in 64-bit bridge = implementations.=20 FreeBSD powerpc64/GENERIC64 seems to use mtmsr fairly freely. (k_trap, = trapexit, asttrapexit, .breakpoint, dbtrap, dbleave, ichss_set, = prof_clock_cnt, hardclock_cpu, kdb_trap, powerpc_interrupt, = flush_disabnle_caches, spinlock_exit, spin_lock_enter, powerpc_init, = cpu_sleep, moea64_add_ofw_mappings, moea64_late_bootstrap, = moea64_mid_bootstrap, moea64_cpu_bootstrap_native, = moea64_bootstrap_native, write_scom, read_scom, pcr_set, = openfirmware_core, save_vec, enable_vec, configure_final, = cpu_est_clockrage, cpu_idle_60x, save_fpu, enable_fpu, = mps3_cpu_bootstrap. Apple also used mtmsr (not mtmsrd) in the = openfirmware vs. kernel transitions in the published BootX-81 source = code.) =3D=3D=3D Mark Millard markmi at dsl-only.net