From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Richard Henderson' <richard.henderson@linaro.org>,
'Pavel Dovgalyuk' <Pavel.Dovgaluk@ispras.ru>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com,
"'Peter Maydell'" <peter.maydell@linaro.org>,
war2jordan@live.com, "'Juan Quintela'" <quintela@redhat.com>,
ciro.santilli@gmail.com, "'Jason Wang'" <jasowang@redhat.com>,
"'Michael S. Tsirkin'" <mst@redhat.com>,
zuban32s@gmail.com, maria.klimushenkova@ispras.ru,
"'Gerd Hoffmann'" <kraxel@redhat.com>,
boost.lists@gmail.com, thomas.dullien@googlemail.com,
"'Paolo Bonzini'" <pbonzini@redhat.com>,
"'Alex Bennée'" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v7 22/22] tcg: fix cpu_io_recompile
Date: Fri, 16 Mar 2018 14:42:37 +0300 [thread overview]
Message-ID: <002301d3bd1b$e2a3f940$a7ebebc0$@ru> (raw)
In-Reply-To: <CAFXwXrn75c3YzborcLYeKmopxVanzBuGxgYJ2+fOxsKA9sKx1w@mail.gmail.com>
> From: Richard Henderson [mailto:richard.henderson@linaro.org]
> On 27 February 2018 at 17:53, Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> wrote:
> >
> > cpu_io_recompile() function was broken by
> > the commit 9b990ee5a3cc6aa38f81266fb0c6ef37a36c45b9. Instead of regenerating
> > the block starting from PC of the original block, it just set the instruction
> > counter for TCG. In most cases this was unnoticed, but in icount mode
> > there was an exception for incorrect usage of CF_LAST_IO flag.
> > This patch recovers recompilation of the original block and also
> > configures translation for executing single IO instruction which
> > caused a recompilation.
> >
> > Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
> > ---
> > accel/tcg/translate-all.c | 18 +++++++++++++++---
> > 1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> > index 67795cd..5ad1b91 100644
> > --- a/accel/tcg/translate-all.c
> > +++ b/accel/tcg/translate-all.c
> > @@ -1728,7 +1728,8 @@ void cpu_io_recompile(CPUState *cpu, uintptr_t retaddr)
> > CPUArchState *env = cpu->env_ptr;
> > #endif
> > TranslationBlock *tb;
> > - uint32_t n;
> > + uint32_t n, flags;
> > + target_ulong pc, cs_base;
> >
> > tb_lock();
> > tb = tb_find_pc(retaddr);
> > @@ -1766,8 +1767,14 @@ void cpu_io_recompile(CPUState *cpu, uintptr_t retaddr)
> > cpu_abort(cpu, "TB too big during recompile");
> > }
> >
> > - /* Adjust the execution state of the next TB. */
> > - cpu->cflags_next_tb = curr_cflags() | CF_LAST_IO | n;
> > + pc = tb->pc;
> > + cs_base = tb->cs_base;
> > + flags = tb->flags;
> > + tb_phys_invalidate(tb, -1);
> > +
> > + /* Execute one IO instruction without caching
> > + instead of creating large TB. */
> > + cpu->cflags_next_tb = curr_cflags() | CF_LAST_IO | CF_NOCACHE | 1;
> >
> > if (tb->cflags & CF_NOCACHE) {
> > if (tb->orig_tb) {
> > @@ -1778,6 +1785,11 @@ void cpu_io_recompile(CPUState *cpu, uintptr_t retaddr)
> > tb_remove(tb);
> > }
> >
> > + /* Generate new TB instead of the current one. */
> > + /* FIXME: In theory this could raise an exception. In practice
> > + we have already translated the block once so it's probably ok. */
> > + tb_gen_code(cpu, pc, cs_base, flags, curr_cflags() | CF_LAST_IO | n);
>
> This isn't right. The whole point of the patch that you reference as
> having broken
> things is that calls to tb_gen_code which ignore their return value
> are by definition
> relying on the side effect of altering the TB cache, and are therefore
> by definition racy.
I see.
> That is exactly the point of cpu->cflags_next_tb, that when we next
> arrive in cpu_exec
> we look up (or generate) the next TB with the given flags. At which
> point we will *not*
> be relying on the TB cache, and we'll execute the generated TB right away.
Well, as a ineffective solution, we can just omit tb_gen_code, but still
make
+ cpu->cflags_next_tb = curr_cflags() | CF_LAST_IO | CF_NOCACHE | 1;
Then the recompilation will occur every time, because the translation
for the original address is not limited by some counter.
> I do not have enough context within this patch to determine what the
> proper solution is.
The context is here:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04818.html
Pavel Dovgalyuk
next prev parent reply other threads:[~2018-03-16 11:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 9:51 [Qemu-devel] [ PATCH v7 00/22] replay additions Pavel Dovgalyuk
2018-02-27 9:51 ` [Qemu-devel] [PATCH v7 01/22] cpu-exec: fix exception_index handling Pavel Dovgalyuk
2018-02-27 9:51 ` [Qemu-devel] [PATCH v7 02/22] block: implement bdrv_snapshot_goto for blkreplay Pavel Dovgalyuk
2018-02-27 9:51 ` [Qemu-devel] [PATCH v7 03/22] blkreplay: create temporary overlay for underlaying devices Pavel Dovgalyuk
2018-02-27 9:51 ` [Qemu-devel] [PATCH v7 04/22] replay: disable default snapshot for record/replay Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 05/22] replay: fix processing async events Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 06/22] replay: fixed replay_enable_events Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 07/22] replay: fix save/load vm for non-empty queue Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 08/22] replay: added replay log format description Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 09/22] replay: save prior value of the host clock Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 10/22] replay/replay.c: bump REPLAY_VERSION again Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 11/22] replay/replay-internal.c: track holding of replay_lock Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 12/22] replay: make locking visible outside replay code Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 13/22] replay: push replay_mutex_lock up the call tree Pavel Dovgalyuk
2018-03-12 13:02 ` Paolo Bonzini
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 14/22] replay: don't destroy mutex at exit Pavel Dovgalyuk
2018-02-27 9:52 ` [Qemu-devel] [PATCH v7 15/22] replay: check return values of fwrite Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 16/22] replay: avoid recursive call of checkpoints Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 17/22] scripts/replay-dump.py: replay log dumper Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 18/22] replay: don't process async events when warping the clock Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 19/22] replay: save vmstate of the asynchronous events Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 20/22] replay: don't drain/flush bdrv queue while RR is working Pavel Dovgalyuk
2018-03-12 13:06 ` Paolo Bonzini
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 21/22] replay: update documentation Pavel Dovgalyuk
2018-02-27 9:53 ` [Qemu-devel] [PATCH v7 22/22] tcg: fix cpu_io_recompile Pavel Dovgalyuk
2018-03-16 11:35 ` Richard Henderson
2018-03-16 11:42 ` Pavel Dovgalyuk [this message]
2018-03-12 10:32 ` [Qemu-devel] [ PATCH v7 00/22] replay additions Pavel Dovgalyuk
2018-03-12 10:44 ` Ciro Santilli
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='002301d3bd1b$e2a3f940$a7ebebc0$@ru' \
--to=dovgaluk@ispras.ru \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=boost.lists@gmail.com \
--cc=ciro.santilli@gmail.com \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=maria.klimushenkova@ispras.ru \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=thomas.dullien@googlemail.com \
--cc=war2jordan@live.com \
--cc=zuban32s@gmail.com \
/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).