Date: Mon, 22 Sep 2014 19:00:07 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following... Message-ID: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net>
next in thread | raw e-mail | index | archive | help
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 = <kernbase+0x1120> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A754BA9-544A-408F-B45C-691627DCA4ED>