Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Sep 2014 18:25:42 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>
Subject:   Re: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following...
Message-ID:  <AFA742B2-20E9-4ABF-95E9-4F3BC5173B44@dsl-only.net>
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
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=20=

> implemented on all POWER ISA compliant CPUs (see e.g. page 886 of the=20=

> 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/F7E732FF811F7831=
87256FDD004D3797

It is the current document of its type as far as I can tell. The title =
is:
> PowerPC=AE Microprocessor Family:
>=20
> The Programming Environments Manual for 64-bit Microprocessors
>=20
> Version 3.0
>=20
> 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:
>=20
> PowerPC user instruction set architecture (UISA)=97The 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.=20
> PowerPC virtual environment architecture (VEA)=97The 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.=20
> PowerPC operating environment architecture (OEA)=97The 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.=20
> 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.=20
> 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.=20
> 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.=20


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

On Sep 22, 2014, at 7:00 PM, Mark Millard <markmi@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.=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?AFA742B2-20E9-4ABF-95E9-4F3BC5173B44>