qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alvise Rigo <a.rigo@virtualopensystems.com>, qemu-devel@nongnu.org
Cc: mttcg@greensocs.com, jani.kokkonen@huawei.com,
	tech@virtualopensystems.com, claudio.fontana@huawei.com
Subject: Re: [Qemu-devel] [RFC 0/5] Slow-path for atomic instruction translation
Date: Wed, 06 May 2015 17:51:11 +0200	[thread overview]
Message-ID: <554A386F.9030804@redhat.com> (raw)
In-Reply-To: <1430926687-25875-1-git-send-email-a.rigo@virtualopensystems.com>

On 06/05/2015 17:38, Alvise Rigo wrote:
> This patch series provides an infrastructure for atomic
> instruction implementation in QEMU, paving the way for TCG multi-threading.
> The adopted design does not rely on host atomic
> instructions and is intended to propose a 'legacy' solution for
> translating guest atomic instructions.
> 
> The underlying idea is to provide new TCG instructions that guarantee
> atomicity to some memory accesses or in general a way to define memory
> transactions. More specifically, a new pair of TCG instructions are
> implemented, qemu_ldlink_i32 and qemu_stcond_i32, that behave as
> LoadLink and StoreConditional primitives (only 32 bit variant
> implemented).  In order to achieve this, a new bitmap is added to the
> ram_list structure (always unique) which flags all memory pages that
> could not be accessed directly through the fast-path, due to previous
> exclusive operations. This new bitmap is coupled with a new TLB flag
> which forces the slow-path exectuion. All stores which take place
> between an LL/SC operation by other vCPUs in the same memory page, will
> fail the subsequent StoreConditional.
> 
> In theory, the provided implementation of TCG LoadLink/StoreConditional
> can be used to properly handle atomic instructions on any architecture.
> 
> The new slow-path is implemented such that:
> - the LoadLink behaves as a normal load slow-path, except for cleaning
>   the dirty flag in the bitmap. The TLB entries created from now on will
>   force the slow-path. To ensure it, we flush the TLB cache for the
>   other vCPUs
> - the StoreConditional behaves as a normal store slow-path, except for
>   checking the state of the dirty bitmap and returning 0 or 1 whether or
>   not the StoreConditional succeeded (0 when no vCPU has touched the
>   same memory in the mean time).
> 
> All those write accesses that are forced to follow the 'legacy'
> slow-path will set the accessed memory page to dirty.
> 
> In this series only the ARM ldrex/strex instructions are implemented.
> The code was tested with bare-metal test cases and with Linux, using
> upstream QEMU.
> 
> This work has been sponsored by Huawei Technologies Dusseldorf GmbH.
> 
> Alvise Rigo (5):
>   exec: Add new exclusive bitmap to ram_list
>   Add new TLB_EXCL flag
>   softmmu: Add helpers for a new slow-path
>   tcg-op: create new TCG qemu_ldlink and qemu_stcond instructions
>   target-arm: translate: implement qemu_ldlink and qemu_stcond ops

That's pretty cool.

Paolo

  parent reply	other threads:[~2015-05-06 15:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 15:38 [Qemu-devel] [RFC 0/5] Slow-path for atomic instruction translation Alvise Rigo
2015-05-06 15:38 ` [Qemu-devel] [RFC 1/5] exec: Add new exclusive bitmap to ram_list Alvise Rigo
2015-05-07 17:12   ` Richard Henderson
2015-05-11  7:48     ` alvise rigo
2015-05-06 15:38 ` [Qemu-devel] [RFC 2/5] Add new TLB_EXCL flag Alvise Rigo
2015-05-07 17:25   ` Richard Henderson
2015-05-11  7:47     ` alvise rigo
2015-05-06 15:38 ` [Qemu-devel] [RFC 3/5] softmmu: Add helpers for a new slow-path Alvise Rigo
2015-05-07 17:56   ` Richard Henderson
2015-05-11  8:07     ` alvise rigo
2015-05-06 15:38 ` [Qemu-devel] [RFC 4/5] tcg-op: create new TCG qemu_ldlink and qemu_stcond instructions Alvise Rigo
2015-05-07 17:58   ` Richard Henderson
2015-05-11  8:12     ` alvise rigo
2015-05-06 15:38 ` [Qemu-devel] [RFC 5/5] target-arm: translate: implement qemu_ldlink and qemu_stcond ops Alvise Rigo
2015-05-06 15:51 ` Paolo Bonzini [this message]
2015-05-06 16:00   ` [Qemu-devel] [RFC 0/5] Slow-path for atomic instruction translation Mark Burton
2015-05-06 16:21     ` alvise rigo
2015-05-06 15:55 ` Mark Burton
2015-05-06 16:19   ` alvise rigo
2015-05-06 16:20     ` Mark Burton
2015-05-08 15:22 ` Alex Bennée
2015-05-11  9:08   ` alvise rigo
2015-05-08 18:29 ` Emilio G. Cota
2015-05-11  9:10   ` alvise rigo
2015-05-26 21:51     ` Emilio G. Cota
2015-05-27  7:20       ` alvise rigo
2015-05-27  8:51         ` 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=554A386F.9030804@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=claudio.fontana@huawei.com \
    --cc=jani.kokkonen@huawei.com \
    --cc=mttcg@greensocs.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tech@virtualopensystems.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).