On 18/07/2016 19:07, Sergey Fedorov wrote: > On 18/07/16 20:00, Paolo Bonzini wrote: >> >> On 18/07/2016 18:57, Sergey Fedorov wrote: >>> On 18/07/16 19:53, Paolo Bonzini wrote: >>>> On 18/07/2016 18:52, Sergey Fedorov wrote: >>>>> So how are we going to use them? >>>> Instead of atomic_read/atomic_set when marking invalid TBs. >>> But shouldn't they be atomic to avoid reading torn writes? >> A torn write would probably fail to match anyway, but even if it doesn't >> it is indistinguishable from a race, isn't it? > > I'm afraid, torn write can happen to be a false match against a wrong > TB. In case of a race with atomic access we either get the right TB or > an invalid one which couldn't match any valid CPU state. Probably, we > have to make sure (and document this) that TB invalidation process > cannot make a partially invalidated TB which can match any meaningful > CPU state.
x86 is atomic (because flags are 32-bit); those that have cs_base==0 are safe against torn writes too. Only SPARC perhaps could use "tb->cs_base|=1" instead in case 0xffffffff........ matches another TB. Paolo >> >> By the way, tb_cmp should also use volatile_read. > > You are right, we must user the save type of access in tb_cmp(). > > Thanks, > Sergey >
