qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in dela


From: Philippe Mathieu-Daudé
Subject: Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE
Date: Tue, 7 Apr 2020 11:32:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 4/7/20 11:23 AM, Philippe Mathieu-Daudé wrote:
On 4/7/20 10:35 AM, Peter Maydell wrote:
On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <address@hidden> 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.

Which also means this patch is incorrect for CPUs implementing the Release 6 (which I'm not familiar with).


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]