Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation

[alvise rigo]

Hi Paolo,


Thank you for your feedback.

On Mon, Dec 14, 2015 at 10:33 AM, Paolo Bonzini <address@hidden> wrote:
>
>
>
> On 14/12/2015 09:41, Alvise Rigo wrote:
> > In theory, the provided implementation of TCG LoadLink/StoreConditional
> > can be used to properly handle atomic instructions on any architecture.
>
> No, _in theory_ this implementation is wrong.  If a normal store can
> make a concurrent LL-SC pair fail, it's provably _impossible_ to handle
> LL/SC with a wait-free fast path for normal stores.
>
> If we decide that it's "good enough", because the race is incredibly
> rare and doesn't happen anyway for spinlocks, then fine.  But it should
> be represented correctly in the commit messages.


I did not yet commented extensively this issue since this is still the
"single-threaded" version of the patch series.
As soon as the next version of mttcg will be released, I will rebase
this series on top of the multi-threaded code.

In any case, what I proposed in the mttcg based v5 was:
- A LL ensures that the TLB_EXCL flag is set on all the CPU's TLB.
This is done by querying a TLB flush to all (not exactly all...) the
CPUs. To be 100% safe, probably we should also wait that the flush is
actually performed
- A TLB_EXCL flag set always forces the slow-path, allowing the CPUs
to check for possible collision with a "exclusive memory region"

Now, why the fact of querying the flush (and possibly ensuring that
the flush has been actually done) should not be enough?

Thank you,
alvise

>
>
> Paolo