[Qemu-devel] sparc64 lazy conditional codes evaluation

[Igor Kovalenko]

Hi!

There is an issue with lazy conditional codes evaluation where
we return from trap handler with mismatching conditionals.

I seldom reproduce it here when dragging qemu window while
machine is working through silo initialization. I use gentoo minimal cd
install-sparc64-minimal-20100322.iso but I think anything with silo boot
would experience the same. Once in a while it would report crc error,
unable to open cd partition or it would fail to decompress image.

Pattern that fails appears to require a sequence of compare insn
possibly followed by a few instructions which do not touch conditionals,
then conditional branch insn. If it happens that we trap while processing
conditional branch insn so it is restarted after return from trap then
seldom conditional codes are calculated incorrectly.

I cannot point to exact cause but it appears that after trap return
we may have CC_OP and CC_SRC* mismatch somewhere,
since adding more cond evaluation flushes over the code helps.

We already tried doing flush more frequently and it is still not
complete, so the question is how to finally do this once and right :)

Obviously I do not get the design of lazy evaluation right, but
the following list appears to be good start. Plan is to prepare
a change to qemu and find a way to test it.

1. Since SPARC* is a RISC CPU it seems to be not profitable to
   use DisasContext->cc_op to predict if flags should be not evaluated
   due to overriding insn. Instead we can drop cc_op from disassembler
   context and simplify code to only use cc_op from env.
   Another point is that we always write to env->cc_op when
translating *cc insns
   This should solve any issue with dc->cc_op prediction going
   out of sync with env->cc_op and cpu_cc_src*

2. We must flush lazy evaluation back to CC_OP_FLAGS in a few cases when
   a. conditional code is required by insn (like addc, cond branch etc.)
      - here we can optimize by evaluating specific bits (carry?)
      - not sure if it works in case we have two cond consuming insns,
        where first needs carry another needs the rest of flags
   b. CCR is read by rdccr (helper_rdccr)
      - have to compute all flags
   c. trap occurs and we prepare trap level context (saving pstate)
      - have to compute all flags
   d. control goes out of tcg runtime (so gdbstub reads correct value from env)
      - have to compute all flags
   ...

-- 
Kind regards,
Igor V. Kovalenko