From: Sandipan Das <hidden> Date: 2021-02-03 06:40:12
The Power ISA says that the fixed-point load and update
instructions must neither use R0 for the base address (RA)
nor have the destination (RT) and the base address (RA) as
the same register. In these cases, the instruction is
invalid. This applies to the following instructions.
* Load Byte and Zero with Update (lbzu)
* Load Byte and Zero with Update Indexed (lbzux)
* Load Halfword and Zero with Update (lhzu)
* Load Halfword and Zero with Update Indexed (lhzux)
* Load Halfword Algebraic with Update (lhau)
* Load Halfword Algebraic with Update Indexed (lhaux)
* Load Word and Zero with Update (lwzu)
* Load Word and Zero with Update Indexed (lwzux)
* Load Word Algebraic with Update Indexed (lwaux)
* Load Doubleword with Update (ldu)
* Load Doubleword with Update Indexed (ldux)
However, the following behaviour is observed using some
invalid opcodes where RA = RT.
An userspace program using an invalid instruction word like
0xe9ce0001, i.e. "ldu r14, 0(r14)", runs and exits without
getting terminated abruptly. The instruction performs the
load operation but does not write the effective address to
the base address register. Attaching an uprobe at that
instruction's address results in emulation which writes the
effective address to the base register. Thus, the final value
of the base address register is different.
To remove any inconsistencies, this adds an additional check
for the aforementioned instructions to make sure that they
are treated as unknown by the emulation infrastructure when
RA = 0 or RA = RT. The kernel will then fallback to executing
the instruction on hardware.
Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
Reviewed-by: Ravi Bangoria <redacted>
Signed-off-by: Sandipan Das <redacted>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20201119054139.244083-1-sandipan@linux.ibm.com/
Changes in v2:
- Jump to unknown_opcode instead of returning -1 for invalid
instruction forms.
---
arch/powerpc/lib/sstep.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
From: Sandipan Das <hidden> Date: 2021-02-03 06:41:25
The Power ISA says that the fixed-point store and update
instructions must not use R0 for the base address (RA).
In this case, the instruction is invalid. This applies
to the following instructions.
* Store Byte with Update (stbu)
* Store Byte with Update Indexed (stbux)
* Store Halfword with Update (sthu)
* Store Halfword with Update Indexed (sthux)
* Store Word with Update (stwu)
* Store Word with Update Indexed (stwux)
* Store Doubleword with Update (stdu)
* Store Doubleword with Update Indexed (stdux)
To remove any inconsistencies, this adds an additional check
for the aforementioned instructions to make sure that they
are treated as unknown by the emulation infrastructure when
RA = 0. The kernel will then fallback to executing the
instruction on hardware.
Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
Reviewed-by: Ravi Bangoria <redacted>
Signed-off-by: Sandipan Das <redacted>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20201119054139.244083-2-sandipan@linux.ibm.com/
Changes in v2:
- Jump to unknown_opcode instead of returning -1 for invalid
instruction forms.
---
arch/powerpc/lib/sstep.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
From: Sandipan Das <hidden> Date: 2021-02-03 06:42:32
Commit 8813ff49607e ("powerpc/sstep: Check instruction
validity against ISA version before emulation") introduced
a proper way to skip unknown instructions. This makes sure
that the same is used for the darn instruction when the
range selection bits have a reserved value.
Fixes: a23987ef267a ("powerpc: sstep: Add support for darn instruction")
Signed-off-by: Sandipan Das <redacted>
---
arch/powerpc/lib/sstep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Naveen N. Rao <hidden> Date: 2021-02-03 09:51:23
On 2021/02/03 12:08PM, Sandipan Das wrote:
The Power ISA says that the fixed-point load and update
instructions must neither use R0 for the base address (RA)
nor have the destination (RT) and the base address (RA) as
the same register. In these cases, the instruction is
invalid. This applies to the following instructions.
* Load Byte and Zero with Update (lbzu)
* Load Byte and Zero with Update Indexed (lbzux)
* Load Halfword and Zero with Update (lhzu)
* Load Halfword and Zero with Update Indexed (lhzux)
* Load Halfword Algebraic with Update (lhau)
* Load Halfword Algebraic with Update Indexed (lhaux)
* Load Word and Zero with Update (lwzu)
* Load Word and Zero with Update Indexed (lwzux)
* Load Word Algebraic with Update Indexed (lwaux)
* Load Doubleword with Update (ldu)
* Load Doubleword with Update Indexed (ldux)
However, the following behaviour is observed using some
invalid opcodes where RA = RT.
An userspace program using an invalid instruction word like
0xe9ce0001, i.e. "ldu r14, 0(r14)", runs and exits without
getting terminated abruptly. The instruction performs the
load operation but does not write the effective address to
the base address register.
While the processor (p8 in my test) doesn't seem to be throwing an
exception, I don't think it is necessarily loading the value. Qemu
throws an exception though. It's probably best to term the behavior as
being undefined.
Attaching an uprobe at that
instruction's address results in emulation which writes the
effective address to the base register. Thus, the final value
of the base address register is different.
To remove any inconsistencies, this adds an additional check
for the aforementioned instructions to make sure that they
are treated as unknown by the emulation infrastructure when
RA = 0 or RA = RT. The kernel will then fallback to executing
the instruction on hardware.
Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
Reviewed-by: Ravi Bangoria <redacted>
Signed-off-by: Sandipan Das <redacted>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20201119054139.244083-1-sandipan@linux.ibm.com/
Changes in v2:
- Jump to unknown_opcode instead of returning -1 for invalid
instruction forms.
---
arch/powerpc/lib/sstep.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
Wouldn't it be easier to just do the below at the end? Or, am I missing something?
Thanks that's much cleaner! We might need something similar for
the FP load/store and update instructions where an instruction is
invalid if RA is 0. I'll send a new revision with these changes.
- Sandipan
On Wed, Feb 03, 2021 at 03:19:09PM +0530, Naveen N. Rao wrote:
On 2021/02/03 12:08PM, Sandipan Das wrote:
quoted
The Power ISA says that the fixed-point load and update
instructions must neither use R0 for the base address (RA)
nor have the destination (RT) and the base address (RA) as
the same register. In these cases, the instruction is
invalid.
quoted
However, the following behaviour is observed using some
invalid opcodes where RA = RT.
An userspace program using an invalid instruction word like
0xe9ce0001, i.e. "ldu r14, 0(r14)", runs and exits without
getting terminated abruptly. The instruction performs the
load operation but does not write the effective address to
the base address register.
While the processor (p8 in my test) doesn't seem to be throwing an
exception, I don't think it is necessarily loading the value. Qemu
throws an exception though. It's probably best to term the behavior as
being undefined.
Power8 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
EA is placed into RT. The storage operand addressed by EA is
accessed, but the data returned by the load is discarded.
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The displacement
field is added to the data returned by the load and placed into RT.
Both UMs also say
Invalid Forms
In general, the POWER9 core handles invalid forms of instructions in
the manner that is most convenient for the particular case (within
the scope of meeting the boundedly-undefined definition described in
the Power ISA). This document specifies the behavior for these
cases. However, it is not recommended that software or other system
facilities make use of the POWER9 behavior in these cases because
such behavior might be different in another processor that
implements the Power ISA.
(or POWER8 instead of POWER9 of course). Always complaining about most
invalid forms seems wise, certainly if not all recent CPUs behave the
same :-)
Segher
From: Naveen N. Rao <hidden> Date: 2021-02-04 08:29:56
On 2021/02/03 03:17PM, Segher Boessenkool wrote:
On Wed, Feb 03, 2021 at 03:19:09PM +0530, Naveen N. Rao wrote:
quoted
On 2021/02/03 12:08PM, Sandipan Das wrote:
quoted
The Power ISA says that the fixed-point load and update
instructions must neither use R0 for the base address (RA)
nor have the destination (RT) and the base address (RA) as
the same register. In these cases, the instruction is
invalid.
quoted
quoted
However, the following behaviour is observed using some
invalid opcodes where RA = RT.
An userspace program using an invalid instruction word like
0xe9ce0001, i.e. "ldu r14, 0(r14)", runs and exits without
getting terminated abruptly. The instruction performs the
load operation but does not write the effective address to
the base address register.
While the processor (p8 in my test) doesn't seem to be throwing an
exception, I don't think it is necessarily loading the value. Qemu
throws an exception though. It's probably best to term the behavior as
being undefined.
Power8 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
EA is placed into RT. The storage operand addressed by EA is
accessed, but the data returned by the load is discarded.
I'm actually not seeing that. This is what I am testing with:
li 8,0xaaa
mr 6,1
std 8,64(6)
#ldu 6,64(6)
.long 0xe8c60041
And, r6 always ends up with 0xaea. It changes with the value I put into
r6 though.
Granted, this is all up in the air, but it does look like there is more
going on and the value isn't the EA or the value at the address.
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The displacement
field is added to the data returned by the load and placed into RT.
Both UMs also say
Invalid Forms
In general, the POWER9 core handles invalid forms of instructions in
the manner that is most convenient for the particular case (within
the scope of meeting the boundedly-undefined definition described in
the Power ISA). This document specifies the behavior for these
cases. However, it is not recommended that software or other system
facilities make use of the POWER9 behavior in these cases because
such behavior might be different in another processor that
implements the Power ISA.
(or POWER8 instead of POWER9 of course). Always complaining about most
invalid forms seems wise, certainly if not all recent CPUs behave the
same :-)
From: David Laight <hidden> Date: 2021-02-04 10:31:15
From: Segher Boessenkool
Sent: 03 February 2021 21:18
...
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Does that change the value of 0?
Rather reminds me of some 1960s era systems that had the small integers
at fixed (global) addresses.
FORTRAN always passes by reference, pass 0 and the address of the global
zero location was passed, the called function could change 0 to 1 for
the entire computer!
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The displacement
field is added to the data returned by the load and placed into RT.
Shame that isn't standard - could be used to optimise some code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Hi!
I didn't see this until now, almost a month later, sorry about that :-)
On Thu, Feb 04, 2021 at 01:57:53PM +0530, Naveen N. Rao wrote:
On 2021/02/03 03:17PM, Segher Boessenkool wrote:
quoted
Power8 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
EA is placed into RT. The storage operand addressed by EA is
accessed, but the data returned by the load is discarded.
I'm actually not seeing that. This is what I am testing with:
li 8,0xaaa
mr 6,1
std 8,64(6)
#ldu 6,64(6)
.long 0xe8c60041
And, r6 always ends up with 0xaea. It changes with the value I put into
r6 though.
That is exactly the behaviour specified for p8. 0aaa+0040=0aea.
Granted, this is all up in the air, but it does look like there is more
going on and the value isn't the EA or the value at the address.
That *is* the EA. The EA is the address the insn does the access at.
Segher
From: Naveen N. Rao <hidden> Date: 2021-03-04 13:46:13
On 2021/03/01 08:37PM, Segher Boessenkool wrote:
Hi!
I didn't see this until now, almost a month later, sorry about that :-)
No problem.
On Thu, Feb 04, 2021 at 01:57:53PM +0530, Naveen N. Rao wrote:
quoted
On 2021/02/03 03:17PM, Segher Boessenkool wrote:
quoted
Power8 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
EA is placed into RT. The storage operand addressed by EA is
accessed, but the data returned by the load is discarded.
I'm actually not seeing that. This is what I am testing with:
li 8,0xaaa
mr 6,1
std 8,64(6)
#ldu 6,64(6)
.long 0xe8c60041
And, r6 always ends up with 0xaea. It changes with the value I put into
r6 though.
That is exactly the behaviour specified for p8. 0aaa+0040=0aea.
quoted
Granted, this is all up in the air, but it does look like there is more
going on and the value isn't the EA or the value at the address.
That *is* the EA. The EA is the address the insn does the access at.
I'm probably missing something here. 0xaaa is the value I stored at an
offset of 64 bytes from the stack pointer (r1 is copied into r6). In the
ldu instruction above, the EA is 64(r6), which should translate to
r1+64. The data returned by the load would be 0xaaa, which should be
discarded per the description you provided above. So, I would expect to
see a 0xc0.. address in r6.
In fact, this looks to be the behavior documented for P9:
quoted
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The
displacement
field is added to the data returned by the load and placed into
RT.
On Wed, Mar 03, 2021 at 10:01:27PM +0530, Naveen N. Rao wrote:
On 2021/03/01 08:37PM, Segher Boessenkool wrote:
quoted
quoted
And, r6 always ends up with 0xaea. It changes with the value I put into
r6 though.
That is exactly the behaviour specified for p8. 0aaa+0040=0aea.
quoted
Granted, this is all up in the air, but it does look like there is more
going on and the value isn't the EA or the value at the address.
That *is* the EA. The EA is the address the insn does the access at.
I'm probably missing something here. 0xaaa is the value I stored at an
offset of 64 bytes from the stack pointer (r1 is copied into r6). In the
ldu instruction above, the EA is 64(r6), which should translate to
r1+64. The data returned by the load would be 0xaaa, which should be
discarded per the description you provided above. So, I would expect to
see a 0xc0.. address in r6.
Yes, I misread your code it seems.
In fact, this looks to be the behavior documented for P9:
quoted
quoted
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The
displacement
field is added to the data returned by the load and placed into
RT.
Yup. So on what cpu did you test?
Either way, the kernel should not emulate any particular cpu here, I'd
say, esp. since recent cpus do different things for this invalid form.
Segher
From: Naveen N. Rao <hidden> Date: 2021-03-05 10:11:39
On 2021/03/04 09:45AM, Segher Boessenkool wrote:
On Wed, Mar 03, 2021 at 10:01:27PM +0530, Naveen N. Rao wrote:
quoted
On 2021/03/01 08:37PM, Segher Boessenkool wrote:
quoted
quoted
And, r6 always ends up with 0xaea. It changes with the value I put into
r6 though.
That is exactly the behaviour specified for p8. 0aaa+0040=0aea.
quoted
Granted, this is all up in the air, but it does look like there is more
going on and the value isn't the EA or the value at the address.
That *is* the EA. The EA is the address the insn does the access at.
I'm probably missing something here. 0xaaa is the value I stored at an
offset of 64 bytes from the stack pointer (r1 is copied into r6). In the
ldu instruction above, the EA is 64(r6), which should translate to
r1+64. The data returned by the load would be 0xaaa, which should be
discarded per the description you provided above. So, I would expect to
see a 0xc0.. address in r6.
Yes, I misread your code it seems.
quoted
In fact, this looks to be the behavior documented for P9:
quoted
quoted
Power9 does:
Load with Update Instructions (RA = 0)
EA is placed into R0.
Load with Update Instructions (RA = RT)
The storage operand addressed by EA is accessed. The
displacement
field is added to the data returned by the load and placed into
RT.
Yup. So on what cpu did you test?
I tested this on two processors:
2.0 (pvr 004d 0200)
2.1 (pvr 004b 0201)
I guess the behavior changed some time during P8, but I don't have a P9
to test this on.
In any case, this souldn't matter too much for us as you rightly point
out:
Either way, the kernel should not emulate any particular cpu here, I'd
say, esp. since recent cpus do different things for this invalid form.