All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.