Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Sep 2014 21:15:46 -0700
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        freebsd-ppc@freebsd.org
Subject:   Re: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following...
Message-ID:  <5420F3F2.4010202@freebsd.org>
In-Reply-To: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net>
References:  <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5420F3F2.4010202>