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 (now I'm not sure about Alpha). In this regard, I was wondering, should these semantics be somehow target-* dependent? Like having some per-architecture functions that, for each LoadLink, set the size of the exclusive memory region to be protected and decide whether a normal store/load will make one CPU's SC fail. Thank you, alvise > > thanks > -- PMM
