qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/10, v3] target-alpha improvements


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 00/10, v3] target-alpha improvements
Date: Fri, 26 Mar 2010 06:37:31 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

On 03/25/2010 06:52 PM, Jamie Lokier wrote:
I guess you are thinking to save the value loaded by load-locked,
and use it as the "old" for host cmpxchg at target's
store-conditional?

Yes.

It'll be fine when ll/sc are only used to provide single-word atomic
calculations, but I'm not sure those are the only uses to which they
are put by any code anywhere.  E.g. if I remember rightly, there was
some discussion of a planned unusual ll/sc use on the linux-arm
list, which involved a second word, but the idea wasn't ever
implemented.

"It is UNPREDICTABLE whether a processor's lock_flag is cleared by
that processor executing a normal load or store instruction."

So at least on Alpha your double-word update isn't supposed to work.

Now, what the cmpxchg *doesn't* handle is when the store isn't to
exactly the same address as the load.  The Alpha spec does allow the
store to be anywhere within the same 16-byte aligned block, and we
can't handle that.  That said, I'm pretty sure such a non-matching
store is never used on Linux.

So stop-the-world ought to remain in, but only as a last resort to
be used when the ll/sc sequence doesn't pass the no-funny-business
test.

The existing stop-the-world implementation is *exactly* cmpxchg.

It doesn't do what you want: stop the world at the ll, resume the
world at the sc (or other suitable subsequent condition e.g. taken
branch or N executed instructions).


r~




reply via email to

[Prev in Thread] Current Thread [Next in Thread]