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

Wed Sep 24 01:25:52 UTC 2014

Nathan Whitehorn wrote of the use of the document that I was referencing:

> 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

I think we may be using different documents rather than different versions of the same document. I may need to find what Nathan is using and its time frame (PowerPC Architecture 2.07?). But he may want to check what I've been referencing. So...

pem_64bit_v3.0.2005jul15.pdf is Version 3.0 and directly from the IBM site and has 657 pages...

https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/F7E732FF811F783187256FDD004D3797

It is the current document of its type as far as I can tell. The title is:
> PowerPC® Microprocessor Family:
> 
> The Programming Environments Manual for 64-bit Microprocessors
> 
> Version 3.0
> 
> July 15, 2005.

It is described on its web page as:

> This manual is to help programmers provide software that is compatible across the family of PowerPC processors. This book provides a general description of features common to PPC processors and indicates those features that are optional or that may be implemented differently in the design of each processor. This book is for only 64-bit processors.

It is different from other architecture documents in that it also documents the Operating Environment Architecture (supervisor level/privileged-state resources for operating systems), not just the UISA and VEA. The document warns that while the UISA is always adhered to there can be VEA and OEA variations that the document does not cover. But it also says that the "general-purpose" PowerPC microprocessors comply with the document. In its own words...

> The three levels of the PowerPC Architecture are defined as follows:
> 
> PowerPC user instruction set architecture (UISA)—The UISA defines the level of the architecture to which user-level (referred to as problem state in the architecture specification) software should conform. The UISA defines the base user-level instruction set, user-level registers, data types, floating-point mem- ory conventions and exception model as seen by user programs, and the memory and programming models. The icon shown in the margin identifies text that is relevant with respect to the UISA. 
> PowerPC virtual environment architecture (VEA)—The VEA defines additional user-level functionality that falls outside typical user-level software requirements. The VEA describes the memory model for an envi- ronment in which multiple devices can access memory, defines aspects of the cache model, defines cache control instructions, and defines the time base facility from a user-level perspective. The icon shown in the margin identifies text that is relevant with respect to the VEA. 
> PowerPC operating environment architecture (OEA)—The OEA defines supervisor-level (referred to as privileged state in the architecture specification) resources typically required by an operating system. The OEA defines the PowerPC memory management model, supervisor-level registers, synchronization requirements, and the exception model. The OEA also defines the time base feature from a supervisor- level perspective. The icon shown in the margin identifies text that is relevant with respect to the OEA. 
> Implementations that adhere to the VEA level are guaranteed to adhere to the UISA level, but may not neces- sarily adhere to the OEA level; likewise, implementations that conform to the OEA level are also guaranteed to conform to the UISA and the VEA levels. 
> All PowerPC devices adhere to the UISA, offering compatibility among all PowerPC application programs. However, there may be different versions of the VEA and OEA than those described here. For example, some devices, such as embedded controllers, may not require some of the features as defined by this VEA and OEA, and may implement a simpler or modified version of those features. 
> The general-purpose PowerPC microprocessors comply both with the UISA and with the VEA and OEA discussed here. In this book, these three levels of the architecture are referred to collectively as the PowerPC Architecture. The distinctions between the levels of the PowerPC Architecture are maintained clearly throughout this manual, using the conventions described in the Section Conventions on page 25. 

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

On Sep 22, 2014, at 7:00 PM, Mark Millard <markmi at dsl-only.net> 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.

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