powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following...

[Mark Millard]

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 <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 ‘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.)




===
Mark Millard
markmi at dsl-only.net