On 09/30/2015 10:44 PM, alvise rigo wrote:
On Wed, Sep 30, 2015 at 1:09 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
On 30 September 2015 at 10:24, alvise rigo
<a.r...@virtualopensystems.com> wrote:
On Wed, Sep 30, 2015 at 5:34 AM, Richard Henderson <r...@twiddle.net> wrote:
(1) I don't see why EXCL support should differ whether MMIO is set or not.
Either we support exclusive accesses on memory-mapped io like we do on ram
(in which case this is wrong) or we don't (in which case this is
unnecessary).
I was not sure whether or not we had to support also MMIO memory.
In theory there shouldn't be any issues for including also
memory-mapped io, I will consider this for the next version.
Worth considering the interaction between exclusives and other
cases for which we force the slowpath, notably watchpoints.
AFAIK, Alpha is the only target we have which specifies that any normal
memory access during a ll+sc sequence may fail the sc.
I will dig into it because I remember that the Alpha architecture
behaves like ARM in the handling of LDxL/STxC instructions.
ARM semantics are that a non-exclusive store by this CPU between
a ldrex and a strex might result in loss of the (local) monitor,
but non-exclusive loads by this CPU won't. (It's an IMPDEF
choice.)
Indeed, what is implemented by this patch series is one of the
permissible choices - very close to the one implemented by the current
TCG - that could match all the other architectures with similar
semantics
Except for the case I pointed out -- where a ldr to a page that conflicts with
the ldrex in the tlb will result in the replacement of the tlb entry, and thus
you'll see the outgoing tlb entry has TLB_EXCL set and set the dirty bit (i.e.
clear the lock bit) on the ldrex page.
I.e. this is a case that *must* pass on arm, but your implementation won't.
(now I'm not sure about Alpha).
Alpha is trivial, as always. Those guys wrote the spec such that anything hard
isn't guaranteed to work, but also isn't guaranteed to fail.
The rule is: no memory accesses of any kind, lest the lock flag be lost. In
practice, it's a test of the MESI state of the cacheline. Which, I assume is
what most other targets use.
Like having some per-architecture functions that, for each LoadLink,
set the size of the exclusive memory region to be protected
We probably do need that; I sort of assumed that simply be part of the
implementation on the instruction side, not done as a side-effect of the actual
load.
and decide whether a normal store/load will make one CPU's SC fail.
There's likely no need to do this. And certainly I don't think we should do it
right away.
r~
