Hi Paolo,
Thank you for your feedback. On Mon, Dec 14, 2015 at 10:33 AM, Paolo Bonzini <pbonz...@redhat.com> 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
