All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Fedorov <serge.fdrv@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>,
	mttcg@listserver.greensocs.com, fred.konrad@greensocs.com,
	a.rigo@virtualopensystems.com, cota@braap.org
Cc: qemu-devel@nongnu.org, mark.burton@greensocs.com,
	pbonzini@redhat.com, jan.kiszka@siemens.com, rth@twiddle.net,
	peter.maydell@linaro.org, claudio.fontana@huawei.com,
	"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC v2 04/11] tcg: comment on which functions have to be called with tb_lock held
Date: Fri, 6 May 2016 21:22:05 +0300	[thread overview]
Message-ID: <572CE0CD.3040004@gmail.com> (raw)
In-Reply-To: <1459870344-16773-5-git-send-email-alex.bennee@linaro.org>

On 05/04/16 18:32, Alex Bennée wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> softmmu requires more functions to be thread-safe, because translation
> blocks can be invalidated from e.g. notdirty callbacks.  Probably the
> same holds for user-mode emulation, it's just that no one has ever
> tried to produce a coherent locking there.
>
> This patch will guide the introduction of more tb_lock and tb_unlock
> calls for system emulation.
>
> Note that after this patch some (most) of the mentioned functions are
> still called outside tb_lock/tb_unlock.  The next one will rectify this.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
(snip)
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 6931db9..13eeaae 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -306,7 +306,10 @@ struct CPUState {
>  
>      void *env_ptr; /* CPUArchState */
>      struct TranslationBlock *current_tb;
> +
> +    /* Writes protected by tb_lock, reads not thread-safe  */
>      struct TranslationBlock *tb_jmp_cache[TB_JMP_CACHE_SIZE];

What does "reads not thread-safe" mean? Where does it get read outside
of either actually held tb_lock or promised in a comment added by this
patch?

> +
>      struct GDBRegisterState *gdb_regs;
>      int gdb_num_regs;
>      int gdb_num_g_regs;
> diff --git a/tcg/tcg.h b/tcg/tcg.h
> index ea4ff02..a46d17c 100644
> --- a/tcg/tcg.h
> +++ b/tcg/tcg.h
> @@ -609,6 +609,7 @@ static inline bool tcg_op_buf_full(void)
>  
>  /* pool based memory allocation */
>  
> +/* tb_lock must be held for tcg_malloc_internal. */

How far are we ready to go in commenting such functions? The functions
can be divided into three categories:
 * extern
 * static, called only from another one function (for better code
structuring)
 * static, called from multiple other functions (for encapsulation of
common code)

I think we should decide how to comment locking requirements and follow
this consistently.

Concerning this particular case, I think there's no much point in making
tcg_malloc_internal() and tcg_malloc() externally visible and commenting
locking requirement for them. We'd better have a separate header file
under include/ for external TCG interface declarations and use this one
as internal only in tcg/.

>  void *tcg_malloc_internal(TCGContext *s, int size);
>  void tcg_pool_reset(TCGContext *s);
>  void tcg_pool_delete(TCGContext *s);
> @@ -617,6 +618,7 @@ void tb_lock(void);
>  void tb_unlock(void);
>  void tb_lock_reset(void);
>  
> +/* Called with tb_lock held.  */
>  static inline void *tcg_malloc(int size)
>  {
>      TCGContext *s = &tcg_ctx;
> diff --git a/translate-all.c b/translate-all.c
> index d923008..a7ff5e7 100644
> --- a/translate-all.c
> +++ b/translate-all.c
> @@ -248,7 +248,9 @@ static int encode_search(TranslationBlock *tb, uint8_t *block)
>      return p - block;
>  }
>  
> -/* The cpu state corresponding to 'searched_pc' is restored.  */
> +/* The cpu state corresponding to 'searched_pc' is restored.
> + * Called with tb_lock held.
> + */
>  static int cpu_restore_state_from_tb(CPUState *cpu, TranslationBlock *tb,
>                                       uintptr_t searched_pc)
>  {
> @@ -306,8 +308,10 @@ bool cpu_restore_state(CPUState *cpu, uintptr_t retaddr)

cpu_restore_state_from_tb() called right here also requires tb_lock().

>          if (tb->cflags & CF_NOCACHE) {
>              /* one-shot translation, invalidate it immediately */
>              cpu->current_tb = NULL;
> +            tb_lock();
>              tb_phys_invalidate(tb, -1);
>              tb_free(tb);
> +            tb_unlock();
>          }
>          return true;
>      }
> @@ -399,6 +403,7 @@ static void page_init(void)
>  }
>  
>  /* If alloc=1:
> + * Called with tb_lock held for system emulation.
>   * Called with mmap_lock held for user-mode emulation.

There's a number of functions where their comment states that tb_lock
should be held for system emulation but mmap_lock for user-mode
emulation. BTW, what is the purpose of mmap_lock? And how it is related
to tb_lock?

>   */
>  static PageDesc *page_find_alloc(tb_page_addr_t index, int alloc)
(snip)
> @@ -1429,7 +1446,9 @@ void tb_invalidate_phys_page_fast(tb_page_addr_t start, int len)
>      }
>      if (!p->code_bitmap &&
>          ++p->code_write_count >= SMC_BITMAP_USE_THRESHOLD) {
> -        /* build code bitmap */
> +        /* build code bitmap.  FIXME: writes should be protected by
> +         * tb_lock, reads by tb_lock or RCU.
> +         */

Probably, page_find() called earlier in this function requires tb_lock
held as well as tb_invalidate_phys_page_range() which can be called
later. Maybe tb_invalidate_phys_page_fast() is a good candidate to be
always called with tb_lock held.

>          build_page_bitmap(p);
>      }
>      if (p->code_bitmap) {
(snip)

A list of candidates (as of rth/tcg-next) to also have such a comment
includes:

    tb_find_physical()
    tb_find_slow()
    tb_hash_remove()
    tb_page_remove()
    tb_remove_from_jmp_list()
    tb_jmp_unlink()
    build_page_bitmap()
    tb_link_page()
    tb_invalidate_phys_range()
    tb_invalidate_phys_page_range()
    page_find()
    invalidate_page_bitmap()
    tb_invalidate_check()
    tb_invalidate_phys_page_fast()
    tb_invalidate_phys_page()
    tb_invalidate_phys_addr()
    cpu_io_recompile()

However, there's no sensible description of what is protected by tb_lock
and mmap_lock. I think we need to have a clear documented description of
the TCG locking scheme in order to be sure we do right things in MTTCG.

Kind regards,
Sergey

  parent reply	other threads:[~2016-05-06 18:22 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 15:32 [Qemu-devel] [RFC v2 00/11] Base enabling patches for MTTCG Alex Bennée
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 01/11] tcg: move tb_invalidated_flag to CPUState Alex Bennée
2016-04-05 15:44   ` Paolo Bonzini
2016-04-06 10:11     ` Sergey Fedorov
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 02/11] cpus: make all_vcpus_paused() return bool Alex Bennée
2016-04-11 12:48   ` Sergey Fedorov
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 03/11] docs: new design document multi-thread-tcg.txt (DRAFTING) Alex Bennée
2016-04-11 20:00   ` Sergey Fedorov
2016-05-25 15:48     ` Sergey Fedorov
2016-05-25 16:01       ` Alex Bennée
2016-05-25 18:03       ` Paolo Bonzini
2016-05-25 18:13         ` Sergey Fedorov
2016-05-06 11:25   ` Sergey Fedorov
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 04/11] tcg: comment on which functions have to be called with tb_lock held Alex Bennée
2016-05-05 14:19   ` Sergey Fedorov
2016-05-05 15:03     ` Alex Bennée
2016-05-05 15:25       ` Sergey Fedorov
2016-05-05 15:42         ` Sergey Fedorov
2016-05-06 18:22   ` Sergey Fedorov [this message]
2016-05-11 12:58     ` Paolo Bonzini
2016-05-11 13:36       ` Sergey Fedorov
2016-05-11 13:46         ` Paolo Bonzini
2016-05-12 19:32           ` Sergey Fedorov
2016-05-13  9:25             ` Paolo Bonzini
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 05/11] tcg: protect TBContext with tb_lock Alex Bennée
2016-05-11 12:45   ` Sergey Fedorov
2016-05-11 12:52     ` Paolo Bonzini
2016-05-11 13:42       ` Sergey Fedorov
2016-06-01 10:30     ` Alex Bennée
2016-06-02 14:37       ` Sergey Fedorov
2016-04-05 15:32 ` [RFC v2 06/11] target-arm/psci.c: wake up sleeping CPUs Alex Bennée
2016-04-05 15:32   ` [Qemu-devel] " Alex Bennée
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 07/11] tcg: cpus rm tcg_exec_all() Alex Bennée
2016-05-26 11:03   ` Sergey Fedorov
2016-05-26 13:10     ` Alex Bennée
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 08/11] tcg: add options for enabling MTTCG Alex Bennée
2016-04-11 20:50   ` Sergey Fedorov
2016-04-12 11:48     ` Alex Bennée
2016-04-12 11:59       ` Peter Maydell
2016-04-12 12:42         ` Sergey Fedorov
2016-04-12 12:50           ` KONRAD Frederic
2016-04-12 13:00             ` Sergey Fedorov
2016-04-12 13:03               ` Pavel Dovgalyuk
2016-04-12 13:19                 ` Sergey Fedorov
2016-04-12 14:23                 ` Alex Bennée
2016-05-09 10:47                   ` Paolo Bonzini
2016-04-12 12:48       ` Sergey Fedorov
2016-05-09 10:45     ` Paolo Bonzini
2016-05-09 11:50       ` Alex Bennée
2016-04-12 13:23   ` Sergey Fedorov
2016-04-12 14:28     ` Alex Bennée
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 09/11] tcg: add kick timer for single-threaded vCPU emulation Alex Bennée
2016-04-11 21:39   ` Sergey Fedorov
2016-06-02 16:00     ` Alex Bennée
2016-06-02 16:05       ` Sergey Fedorov
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 10/11] tcg: drop global lock during TCG code execution Alex Bennée
2016-05-24 21:28   ` Sergey Fedorov
2016-05-25 10:33     ` Paolo Bonzini
2016-05-25 11:07       ` Alex Bennée
2016-05-25 12:46         ` Paolo Bonzini
2016-04-05 15:32 ` [Qemu-devel] [RFC v2 11/11] tcg: enable thread-per-vCPU Alex Bennée
2016-05-27 13:57   ` Sergey Fedorov
2016-05-27 14:55     ` Paolo Bonzini
2016-05-27 15:07       ` Sergey Fedorov
2016-05-27 15:25         ` Paolo Bonzini
2016-05-27 18:54           ` Sergey Fedorov
2016-06-02 16:36             ` Alex Bennée

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=572CE0CD.3040004@gmail.com \
    --to=serge.fdrv@gmail.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=afaerber@suse.de \
    --cc=alex.bennee@linaro.org \
    --cc=claudio.fontana@huawei.com \
    --cc=cota@braap.org \
    --cc=crosthwaite.peter@gmail.com \
    --cc=fred.konrad@greensocs.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mark.burton@greensocs.com \
    --cc=mttcg@listserver.greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.