From: Michael Eager <eager@eagerm.com>
To: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] cpu_io_recompile, icount, and re-issued instructions
Date: Sun, 30 Apr 2017 18:57:35 -0700 [thread overview]
Message-ID: <5906960F.2050305@eagerm.com> (raw)
I'm working with an emulation for a proprietary processor on an older QEMU source base. It looks
like the problem I am seeing in the old sources would still be present in the current source base.
I'm seeing incorrect values when there is a write to a memory-mapped I/O device when icount is set.
What I see happening is that a TB with ~20 instructions is executed which contains a write to the
MM I/O address. When it gets to the io_write routine, can_do_io is false, which results in a call
to cpu_io_recompile.
cpu_io_recompile does what it (sort of) says it is supposed to do: it builds a new TB with the I/O
instruction as the last instruction in the block, then re-issues the TB. The problem is that the
new TB contains the instructions before the I/O instruction, so they are executed a second time.
There is a note in cpu_io_recompile which mentions the situation where the I/O instruction is not
the first in the TB has not been handled:
/* TODO: If env->pc != tb->pc (i.e. the faulting instruction was not
* the first in the TB) then we end up generating a whole new TB and
* repeating the fault, which is horribly inefficient.
* Better would be to execute just this insn uncached, or generate a
* second new TB.
I'm a bit unclear what this is saying. A new TB is generated which is issued setting can_do_io, and
which passes through io_write without a problem. I'm not sure what fault is repeated.
It seems to me that what cpu_io_recompile should do is create a new TB with the n instructions which
were already executed and cache it. Then it should create a TB with only the I/O instruction,
setting can_do_io, and re-issue this TB.
Am I understanding this correctly?
This code has been around for a long, long time. Has anyone noticed this problem in the past?
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
next reply other threads:[~2017-05-01 1:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-01 1:57 Michael Eager [this message]
2017-05-02 7:59 ` [Qemu-devel] cpu_io_recompile, icount, and re-issued instructions Paolo Bonzini
2017-05-02 17:59 ` Michael Eager
-- strict thread matches above, loose matches on Subject: below --
2017-05-01 0:55 Michael Eager
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=5906960F.2050305@eagerm.com \
--to=eager@eagerm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.