All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elie Richa <richa@adacore.com>
To: qemu-devel@nongnu.org
Cc: Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH] PPC: Fix sync instructions problem in SMP
Date: Thu, 04 Aug 2011 12:34:19 +0200	[thread overview]
Message-ID: <4E3A75AB.1000707@adacore.com> (raw)
In-Reply-To: <1311350319-29706-1-git-send-email-richa@adacore.com>

bump.

Anybody have opinions on this?
I can provide a more thorough explanation of the problem if needed. I 
wrote the test case in Ada for an MPC8641D processor (2 e600 cores) on a 
board that is not yet submitted to the list, therefore I cannot provide 
a ready to run binary. I can submit my board if needed.

Even though my patch is rather harsh, it has the advantage of solving
the problem for any number of CPUs without touching the translation
code. And it does not affect normal execution as I explained in the
previous mail.

Regards,
Elie

On 07/22/2011 05:58 PM, Elie Richa wrote:
> In the current emulation of the load-and-reserve (lwarx) and
> store-conditional (stwcx.) instructions, the internal reservation
> mechanism is taken into account, however each CPU has its own
> reservation information and this information is not synchronized between
> CPUs to perform proper synchronization.
> The following test case with 2 CPUs shows that the semantics of the
> "lwarx" and "stwcx." instructions are not preserved by the emulation.
> The test case does the following :
> 	- CPU0: reserve a memory location
> 	- CPU1: reserve the same memory location
> 	- CPU0: perform stwcx. on the location
> The last store-conditional operation succeeds while it is supposed to
> fail since the reservation was supposed to be lost at the second reserve
> operation.
>
> This (one line) patch fixes this problem in a very simple manner by
> removing the reservation of a CPU every time it is scheduled (in
> cpu_exec()). While this is a harsh workaround, it does not affect the
> guest code much because reservations are usually held for a very short
> time, that is an lwarx is almost always followed by an stwcx. a few
> instructions below. Therefore, in most cases, the reservation will be
> taken and consumed before a CPU switch occurs. However in the rare case
> where a CPU switch does occur between the lwarx and its corresponding
> stwcx.  this patch solves a potential erroneous behavior of the
> synchronization instructions.
>
> Signed-off-by: Elie Richa<richa@adacore.com>
> ---
>   cpu-exec.c |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index de0d716..d1ac3b0 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -216,6 +216,7 @@ int cpu_exec(CPUState *env)
>   #elif defined(TARGET_ARM)
>   #elif defined(TARGET_UNICORE32)
>   #elif defined(TARGET_PPC)
> +    env->reserve_addr = -1;
>   #elif defined(TARGET_LM32)
>   #elif defined(TARGET_MICROBLAZE)
>   #elif defined(TARGET_MIPS)

  reply	other threads:[~2011-08-04 10:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 15:58 [Qemu-devel] [PATCH] PPC: Fix sync instructions problem in SMP Elie Richa
2011-08-04 10:34 ` Elie Richa [this message]
2011-08-09 12:44   ` Alexander Graf

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=4E3A75AB.1000707@adacore.com \
    --to=richa@adacore.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.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 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.