From: Igor Kovalenko <igor.v.kovalenko@gmail.com>
To: qemu-devel <qemu-devel@nongnu.org>, Blue Swirl <blauwirbel@gmail.com>
Subject: [Qemu-devel] sparc64 lazy conditional codes evaluation
Date: Mon, 3 May 2010 11:17:41 +0400 [thread overview]
Message-ID: <q2rb2fa41d61005030017vacbfb9dcq65a905ff38bc1ef9@mail.gmail.com> (raw)
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
next reply other threads:[~2010-05-03 7:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 7:17 Igor Kovalenko [this message]
2010-05-03 19:24 ` [Qemu-devel] Re: sparc64 lazy conditional codes evaluation Blue Swirl
2010-05-03 19:46 ` Igor Kovalenko
2010-05-03 19:54 ` Blue Swirl
2010-05-03 20:03 ` Igor Kovalenko
2010-05-04 20:21 ` Blue Swirl
2010-05-05 20:24 ` Igor Kovalenko
2010-05-06 18:51 ` Blue Swirl
2010-05-08 6:41 ` Igor Kovalenko
2010-05-09 20:22 ` Blue Swirl
2010-05-10 9:40 ` Mark Cave-Ayland
2010-05-10 18:33 ` Blue Swirl
2010-05-15 12:56 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=q2rb2fa41d61005030017vacbfb9dcq65a905ff38bc1ef9@mail.gmail.com \
--to=igor.v.kovalenko@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).