Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 4/7/20 10:35 AM, Peter Maydell wrote:
> On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
>> & ASE_MIPS16) we get:
>>
>>    $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
>>    $ qemu-system-mipsel -bios cop1x.bin
>>    unknown branch 0x13000
>>    Aborted (core dumped)
> 
>> This is because this COP1X instruction generates a Reserved
>> Instruction when used with this core, however we are in a delay
>> slot, and exceptions in delay slot are architecturally unpredictable.
>>
>> Core dumps confunse users. Instead, report a friendlier error message:
>>
>>    $ qemu-system-mipsel -bios cop1x.bin
>>    qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE
> 
> UNPREDICTABLE behaviour should not in QEMU include
> causing QEMU to exit. You can log it with LOG_GUEST_ERROR
> if you like but you should do something plausible (ideally what
> some bit of real hardware does when this situation happens).

OK. I have no clue how real 24Kf deals with it - I don't own one -, it 
is not in my list of interests (and my list of interests - which I can 
reproduce - is not modeled in QEMU).

> 
> PS: does MIPS use the "UNPREDICTABLE" terminology? I
> thought it was an Arm-ism, but maybe it's caught on more widely.

At least it appears in my MIPS32 ISA Vol II (Revision 0.95) copy from 2001:

1.2  UNPREDICTABLE and UNDEFINED

1.2.1  UNPREDICTABLE
UNPREDICTABLE results may vary from processor implementation to 
implementation, instruction to instruction, oras a function of time on 
the same implementation or instruction. Software can never depend on 
results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a 
result to be generated or not. If a result is generated,it is 
UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions.
UNPREDICTABLE results or operations have several implementation 
restrictions:
• Implementations of operations generating UNPREDICTABLE results must 
not depend on any data source (memory or internal state) which is 
inaccessible in the current processor mode
• UNPREDICTABLE operations must not read, write, or modify the contents 
of memory or internal state which is inaccessible in the current 
processor mode. For example, UNPREDICTABLE operations executed in user 
mode must not access memory or internal state that is only accessible in 
Kernel Mode or Debug Mode or in another process
• UNPREDICTABLE operations must not halt or hang the processor

1.2.2  UNDEFINED
UNDEFINED operations or behavior may vary from processor implementation 
to implementation, instruction to instruction, or as a function of time 
on the same implementation or instruction. UNDEFINED operations or 
behavior may vary from nothing to creating an environment in which 
execution can no longer continue. UNDEFINED operations or behavior may 
cause data loss.
UNDEFINED operations or behavior has one implementation restriction:
• UNDEFINED operations or behavior must not cause the processor to hang 
(that is, enter a state from which there is no exit other than powering 
down the processor). The assertion of any of the reset signals must 
restore the processorto an operational state

Then:

Jump and Link Register (JALR)

Processor operation is UNPREDICTABLE if a branch, jump, ERET, DERET, or 
WAIT instruction is placed in the delay slot of a branch or jump.

---

On Vol I Rev 6.01:

5.3.2.1  Control Transfer Instructions in Delay Slots and Forbidden Slots

In MIPS architectures prior to Release 6. if a control transfer 
instruction (CTI) is placed in a branch delay slot, the operation of 
both instructions is UNPREDICTABLE. In Release 6, if a CTI is placed in 
a branch delay slot or a compact branch forbidden slot, implementations 
are required to signal a Reserved Instruction exception.

The following instructions are forbidden in branch delay slots and 
forbidden slots: any CTI, including branches and jumps, ERET, ERETNC, 
DERET, WAIT, and PAUSE. Their occurrence is required to signal a 
Reserved Instruction exception.

5.3.2.2  Exceptions and Delay and Forbidden Slots

If an exception or interrupt prevents the completion of an instruction 
in a delay slot or forbidden slot, the hardware reports an Exception PC 
(CP0 EPC) of the branch, with a status bit set (StatusBD) to indicate 
that the exception was for the instruction in the delay slot of the branch.
By convention, if an exception or interrupt prevents the completion of 
an instruction in a branch delay or forbidden slot, the branch 
instruction is re-executed and branch instructions must be restartable 
to permit this. In particular, procedure calls must be restartable. To 
insure that a procedure call is restartable, procedure calls that have a 
delay slot or forbidden slot (branch/jump-and-link instructions) should 
not use the register in which the return link is stored (usu-ally GPR 
31) as a source register. This applies to all branch/jump-and-link 
instructions that have both a slot (delay or forbidden) and source 
registers, both for conditions (e.g., BGEZAL or BGEZALC) or for jump 
targets (JALR).

---

I would have expected the behavior match the UNDEFINED description, as 
Yongbok Kim commented here:
https://bugs.launchpad.net/qemu/+bug/1663287/comments/3

   branches in a delay slot is "undefined" in the pre-Release
   6 architecture. MIPS architectre release 6 defines to signal
   Reserved Instruction exceptions for such cases.

But it really appears as UNPREDICTABLE.