[Qemu-devel] Re: sparc32 FPU SP Invalid CEXC Test

[Blue Swirl]

On 4/21/10, Artyom Tarasenko <address@hidden> wrote:
> 2010/4/16 Artyom Tarasenko <address@hidden>:
>
> > 2010/4/15 Artyom Tarasenko <address@hidden>:
>  >> 2010/4/15 Blue Swirl <address@hidden>:
>  >>> On 4/15/10, Artyom Tarasenko <address@hidden> wrote:
>  >>>> 2010/4/15 Artyom Tarasenko <address@hidden>:
>  >>>>
>  >>>> > One of LX's tests crashes pretty hard, causing qemu abort.
>  >>>>  > I've tried to look how does the execution flow works with -d in_asm.
>  >>>>  > Does the address in the log show the guest's PC register?
>  >>>>
>  >>>>
>  >>>> It's probably sort of a "timing" issue.
>  >>>>
>  >>>>  Can we check exceptions not just on jumps, but also on floating poit
>  >>>>  operations which may cause a trap?
>  >>>>  These traps are supposed to be syncronous.
>  >>>
>  >>> Yes, the bug is that PC and NPC are not saved before executing FPU
>  >>> instructions. Please try this patch.
>  >>
>  >> The patch gets it a couple of tests further:
>  >>
>  >> FPU SP Invalid CEXC Test
>  >> FPU SP Overflow CEXC Test
>  >> FPU SP Divide-by-0 CEXC Test
>  >> FPU SP Inexact CEXC Test
>  >> FPU SP Trap Priority >  Test Unassigned mem write access of 4 bytes to
>  >> 000000008421f000 from 700030f8
>  >>
>  >> FPU SP Trap Priority <  Test
>  >>     ERROR : Unexpected Synchronous Trap Taken, Trap Type = 00000008,
>  >> PSR = 414010c4, PC = 70003190, TBR = 00000080
>  >>     STATUS : Entering scope loop .... Press <A> key to Abort!qemu:
>  >> fatal: Trap 0x03 while interrupts disabled, Error state
>  >> pc: 0000217c  npc: 00003170
>  >> General Registers:
>  >> %g0-7: 00000000 00003170 00000055 00000001 00000002 00000000 00000000 
> 00000000
>  >>
>  >> Current Register Window:
>  >> %o0-7: 00000000 00000999 00000000 00000000 00000000 00000000 0001fba0 
> 7000971c
>  >> %l0-7: 0002fff8 00000000 00000000 00000000 00000000 ffffffff 00000000 
> 00000000
>  >> %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> 00000000
>  >>
>  >> Floating Point Registers:
>  >> %f00: 000000002.890625 000000025.000000 000000000.000000 000000000.000000
>  >> %f04: 000000002.890625 000000000.000000 000000002.890625 000000000.000000
>  >> %f08: 000000003.390625 000000000.000000 000000002.250000 000000000.000000
>  >> %f12: 000000002.890625 000000000.000000 000000002.312500 000000000.000000
>  >> %f16: 000000002.312500 000000000.000000 000000002.890625 000000000.000000
>  >> %f20: 000000002.718750 000000000.000000 000000002.562500 000000000.000000
>  >> %f24: 000000002.890625 000000000.000000 000000002.968750 000000000.000000
>  >> %f28: 000000002.312500 000000000.000000 000000002.890625 000000000.000000
>  >> psr: 41000000 (icc: ---- SPE: ---) wim: 00000002
>  >> fsr: 0f884002 y: 00000000
>  >> Aborted
>  >>
>  >>
>  >> The code:
>  >>
>  >>   0x70003174:  sethi  %hi(0x41c80000), %l3
>  >>   0x70003178:  add  %l4, 2, %l5
>  >>   0x7000317c:  st  %l3, [ %l4 ]
>  >>   0x70003180:  ld  [ %l4 ], %f1
>  >>   0x70003184:  clr  [ %l4 ]
>  >>   0x70003188:  ld  [ %l4 ], %f2
>  >>   0x7000318c:  mov  7, %g5
>  >>   0x70003190:  fdivs  %f1, %f2, %f3
>  >
>  > And what is even more strange it looks in qemu.log like if trap is taken,
>  > gdb doesn't stop at the 0x080 breakpoint after this operation.
>  > Whether I do a stepi or nexti, it just continues up to the crash.
>  > Let me know if I can provide more information.
>  >
>  > Breakpoint 2, 0x00000080 in ?? ()
>  > (gdb) cont
>  > Continuing.
>  >
>  > Breakpoint 6, 0x70003190 in ?? ()
>  > (gdb) stepi
>  > Remote connection closed
>  > (gdb)
>
>
> The trick was not to set the breakpoint at 0x70003190. Then the
>  breakpoint at 0x80 works.
>  And I think I found a hint:
>
>  http://www.cmpe.boun.edu.tr/courses/cmpe511/fall2004/Ozan Aktan -
>  Supersparc Architecture.doc
>
>  "One unique feature of the floating-point unit is that dependent
>  floating-point instructions may be issued in the same instruction
>  group as the dependent floating-point operation. As an example, the
>  following instructions can issue in a single clock cycle:
>  LDD                   [%i0 + %i1], %f2
>  FMULD              %f2, %f4, %f6   "
>
>  We also have a dependent instructions
>
> 0x700030f4:  fdivs  %f1, %f2, %f3
>  0x700030f8:  st  %f3, [ %l6 ]
>
>
> which must produce two traps simultaneously: division by zero and
>  unaligned access. Unaligned access is a higher priority trap, so it
>  must be processed first.
>
>  In the previous test (which passed) the store produces a data access
>  exception which has lower priority than division by zero. The test
>  passes because it is bad.

Currently QEMU executes the IU/FPU instructions synchronously and the
IU/FPU traps always arrive in the issue order. What you are describing
is called deferred traps in the V8 manual chapter Traps. STDFQ
description gives other hints and also Appendix L describes the queue.

But I think it would be very hard to model this accurately, you'd have
to take into account the instruction execution times, which are then
subject to the cache/memory model (in)accuracies.