qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] Alpha: fix locked loads/stores
Date: Fri, 7 Nov 2008 17:47:01 +0100	[thread overview]
Message-ID: <200811071647.01965.paul@codesourcery.com> (raw)
In-Reply-To: <20081107151828.GA353@hall.aurel32.net>

> > > I don't agree with this part. The current code use a single variable
> > > for both address and lock_bit to spare a few tests. Basically it sets
> > > cpu_lock to -1 when not locked and stores the address when locked. Your
> > > patch does not compare the address, so it will break multi-threading.
> >
> > My understanding of the Alpha architecture manual is that
> > if the addresses don't meet certain criteria (which you
> > simplify to addresses comparison) then failure or success
> > of st_c is UNPREDICTABLE (I am not shouting, it's the way
> > they write it :-) unless some lock clearing occurred (cf
> > section 4.2.5).
>
> The manual is actually not really clear. Section 4.2.5 does not really
> speak about storing the locked address, while Section 3.1.4 explicitly
> mentions a "locked_physical_address register".

IIUC The whole point of these instructions is to implement syncronisation 
primitives. Typically this is a read-modify-write sequence and you want the 
write to fail if annother sequence happend in between the two operations.

The current code will probably work for UP guests because the OS will clear 
the exclusive lock on a context switch and in practice these instruction 
always occur in matched pairs.  

SMP guests are where things start to get interesting.  You need to ensure that 
multiple CPUs never have the same address locked. In theory this can be done 
with a single global lock token (that can only be held by one CPU at a time). 
In practice you tend to have finer grained address based locking so that you 
don't get contention between independent locks.

On ARM the lock is also broken if *any* instruction writes to the locked 
address. I don't know if this also applies to Alpha, or whether they 
restricted it to just st_c. My guess would be the latter.

Paul

      parent reply	other threads:[~2008-11-07 16:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07 11:34 [Qemu-devel] [PATCH] Alpha: fix locked loads/stores Laurent Desnogues
2008-11-07 14:00 ` Aurelien Jarno
2008-11-07 14:19   ` Laurent Desnogues
2008-11-07 15:18     ` Aurelien Jarno
2008-11-07 16:42       ` Laurent Desnogues
2008-11-07 17:44         ` Vince Weaver
2008-11-08  9:12           ` Aurelien Jarno
2008-11-08 14:11             ` Laurent Desnogues
2008-11-07 16:47       ` Paul Brook [this message]

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=200811071647.01965.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=aurelien@aurel32.net \
    --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 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).