Re: [Qemu-devel] [RFC v5 2/6] softmmu: Add new TLB_EXCL flag

[Richard Henderson]

On 09/30/2015 10:44 PM, alvise rigo wrote:
> On Wed, Sep 30, 2015 at 1:09 PM, Peter Maydell <address@hidden> wrote:
> > On 30 September 2015 at 10:24, alvise rigo
> > <address@hidden> wrote:
> > > On Wed, Sep 30, 2015 at 5:34 AM, Richard Henderson <address@hidden> 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~