qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sergey Fedorov <serge.fdrv@gmail.com>,
	sergey.fedorov@linaro.org, qemu-devel@nongnu.org
Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate
Date: Mon, 28 Mar 2016 23:21:21 +0200	[thread overview]
Message-ID: <56F9A051.9090907@redhat.com> (raw)
In-Reply-To: <56F94B59.80905@gmail.com>



On 28/03/2016 17:18, Sergey Fedorov wrote:
> The use pattern of 'tb_invalidated_flag' is a bit intricate; correct me,
> if I'm wrong about the following. Basically, 'tb_invalidated_flag' was
> meant to catch two events:
>  * some TB has been invalidated by tb_phys_invalidate();

This is patch 4.

>  * the whole translation buffer has been flushed by tb_flush().

This is patch 5.

> Then it is checked to ensure:
>  * the last executed TB can be safely patched to directly call the next
>    one in cpu_exec();
>  * the original TB should be provided for further possible invalidation
>    along with the temporarily generated TB when in cpu_exec_nocache().
>
> [...] I would suggest the following solution:
>  (1) Use 'tb->pc' as an indicator of whether TB is valid; check for it
>      in cpu_exec() when deciding on whether to patch the last executed
>      TB or not
>  (2) Use 'tcg_ctx.tb_ctx.tb_flush_count' to check for translation buffer
>      flushes; capture it before calling tb_gen_code() and compare to it
>      afterwards to check if tb_flush() has been called in between

Of course that would work, but it would be slower.  I think it is
unnecessary for two reasons:

1) There are two calls to cpu_exec_nocache.  One exits immediately with
"break;", the other always sets "next_tb = 0;".  Therefore it is safe in
both cases for cpu_exec_nocache to hijack cpu->tb_invalidated_flag.

2) if it were broken, it would _also_ be broken before these patches
because cpu_exec_nocache always runs with tb_lock taken.  So I think
documenting the assumptions is better than changing them at the same
time as doing other changes.


Your observation that tb->pc==-1 is not necessarily safe still holds of
course.  Probably the best thing is an inline that can do one of:

1) set cs_base to an invalid value (anything nonzero is enough except on
x86 and SPARC; SPARC can use all-ones)

2) sets the flags to an invalid combination (x86 can use all ones)

3) sets the PC to an invalid value (no one really needs it)

Paolo

  reply	other threads:[~2016-03-28 21:21 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 13:46 [Qemu-devel] [PATCH 0/5] tcg: Misc clean-up patches from Paolo sergey.fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 1/5] tcg: code_bitmap is not used by user-mode emulation sergey.fedorov
2016-03-17 14:56   ` Peter Maydell
2016-03-17 15:03     ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 2/5] tcg: reorganize tb_find_physical loop sergey.fedorov
2016-03-17 14:59   ` Peter Maydell
2016-03-22 14:59   ` Alex Bennée
2016-03-22 15:00     ` Paolo Bonzini
2016-03-29 13:19     ` Sergey Fedorov
2016-03-29 13:26       ` Paolo Bonzini
2016-03-29 14:05         ` Sergey Fedorov
2016-03-29 14:26           ` Alex Bennée
2016-03-29 14:37             ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 3/5] tcg: always keep jump target and tb->jmp_next consistent sergey.fedorov
2016-03-17 17:57   ` Richard Henderson
2016-03-17 19:31     ` Paolo Bonzini
2016-03-17 20:45       ` Sergey Fedorov
2016-03-17 20:46         ` Richard Henderson
2016-03-18 10:29           ` Sergey Fedorov
2016-03-18 10:32         ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate sergey.fedorov
2016-03-17 15:09   ` Paolo Bonzini
2016-03-17 15:14     ` Sergey Fedorov
2016-03-28 15:18       ` Sergey Fedorov
2016-03-28 21:21         ` Paolo Bonzini [this message]
2016-03-29 10:03           ` Sergey Fedorov
2016-03-29 10:37             ` Paolo Bonzini
2016-03-29 12:31               ` Sergey Fedorov
2016-03-29 13:43                 ` Alex Bennée
2016-04-14 14:45               ` Sergey Fedorov
2016-04-14 15:13                 ` Paolo Bonzini
2016-04-14 15:36                   ` Sergey Fedorov
2016-04-14 17:27                     ` Paolo Bonzini
2016-04-14 18:29                   ` Sergey Fedorov
2016-04-14 18:37                   ` Sergey Fedorov
2016-03-28 18:42   ` Sergey Fedorov
2016-03-28 20:58     ` Paolo Bonzini
2016-03-29  0:17       ` Richard Henderson
2016-03-17 13:46 ` [Qemu-devel] [PATCH 5/5] tcg: move tb_invalidated_flag to CPUState sergey.fedorov
2016-03-22 15:07   ` Alex Bennée
2016-03-22 15:11     ` Sergey Fedorov

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=56F9A051.9090907@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=serge.fdrv@gmail.com \
    --cc=sergey.fedorov@linaro.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).