Le 26/07/2022 à 15:44, Segher Boessenkool a écrit :

On Tue, Jul 26, 2022 at 11:02:59AM +0200, Arnd Bergmann wrote:

quoted

On Tue, Jul 26, 2022 at 10:34 AM Pali Rohár [off-list ref] wrote:

quoted

On Monday 25 July 2022 16:54:16 Segher Boessenkool wrote:

quoted

The EH field in larx insns is new since ISA 2.05, and some ISA 1.x cpu
implementations actually raise an illegal insn exception on EH=1.  It
appears P2020 is one of those.

P2020 has e500 cores. e500 cores uses ISA 2.03. So this may be reason.
But in official Freescale/NXP documentation for e500 is documented that
lwarx supports also eh=1. Maybe it is not really supported.
https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf (page 562)

(page 6-186)

quoted

quoted

At least there is NOTE:
Some older processors may treat EH=1 as an illegal instruction.

And the architecture says
   Programming Note
   Warning: On some processors that comply with versions of the
   architecture that precede Version 2.00, executing a Load And Reserve
   instruction in which EH = 1 will cause the illegal instruction error
   handler to be invoked.

quoted

In commit d6ccb1f55ddf ("powerpc/85xx: Make sure lwarx hint isn't set on ppc32")
this was clarified to affect (all?) e500v1/v2,

   e500v1/v2 based chips will treat any reserved field being set in an
   opcode as illegal.

while the architecture says

   Reserved fields in instructions are ignored by the processor.

Whoops :-)  We need fixes for processor implementation bugs all the
time of course, but this is a massive *design* bug.  I'm surprised this
CPU still works as well as it does!

"Programming Environments Manual for 32-Bit Implementations of the
PowerPC™ Architecture" §4.1.2.2.2 says: "Invalid forms result when a bit 
or operand is coded incorrectly, for example, or when a reserved bit 
(shown as ‘0’) is coded as ‘1’."

Even the venerable PEM (last updated in 1997) shows the EH field as
reserved, always treated as 0.

quoted

this one apparently
fixed it before,
but Christophe's commit effectively reverted that change.

I think only the simple_spinlock.h file actually uses EH=1

That's right afaics.

quoted

and this is not
included in non-SMP kernels, so presumably the only affected machines were
the rare dual-core e500v2 ones (p2020, MPC8572, bsc9132), which would
explain why nobody noticed for the past 9 months.

Also people using an SMP kernel on older cores should see the problem,
no?  Or is that patched out?  Or does this use case never happen :-)

Maybe unlike e500, older cores ignore the EH bit and don't mind when 
it's set to 1 ?

Chritophe