From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 23 04:15:54 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 B68714C1 for ; Tue, 23 Sep 2014 04:15:54 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 811D47B6 for ; Tue, 23 Sep 2014 04:15:54 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8N4FkGP019616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 22 Sep 2014 21:15:47 -0700 Message-ID: <5420F3F2.4010202@freebsd.org> Date: Mon, 22 Sep 2014 21:15:46 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Re: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following... References: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net> In-Reply-To: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVZohAgrvx6SjfFPepgXTmUNrE3nzo9GSLCoCROt68PL1bKl5QNsydpPA0raL1g+BWlzFJBsEHoYuj3hVlbZHWg0FGIv/TvSDhk= X-Sonic-ID: C;4LMfS9hC5BGQtzZXoK8kYw== M;Js6RS9hC5BGQtzZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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 04:15:54 -0000 On 09/22/14 19:00, Mark Millard wrote: > 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. > 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. This one was missing. Nice catch! This is among the first instructions the CPU executes, so it cannot be the cause of any hangs that happen after display anything on the screen. > 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 ‘0’, and perform synchronization as if L were ‘1’. Therefore software that uses mtmsrd and runs on such processors must obey the following rules. >> >> If L= ’1’, the contents of bits of register rS other than bits [48] and [62] must be such that if L were ‘0’ the instruction would not alter the contents of the corresponding MSR bits. >> If L = ‘0’ 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. >> 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 = ’0’ as a no-op, thereby avoiding the performance penalty of a second context synchronization.) >> > > > 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. > 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.) > > I think you are looking at very old documentation. The 32-bit mtmsr is implemented on all POWER ISA compliant CPUs (see e.g. page 886 of the 2.07 document). -Nathan