On 18 September 2018 at 19:42, Emilio G. Cota <c...@braap.org> wrote: > We already have these. For instance: > > - sTLB lookups can happen concurrently with invalidations > to the same sTLB from another core (via tlb_reset_dirty) > > - icount_decr is written to by cpu_exit, and is read > at the beginning of each TB (with a tcg_gen_ld_32 generated > by gen_tb_start). > > The latter is always a 32-bit access, so all hosts can generate > it atomically. The former can be a 64-bit access if the guest > is 64-bit, which cannot be done if !CONFIG_ATOMIC64. But we > already disable mttcg for those combinations (we define > TCG_OVERSIZED_GUEST for this).
Does libatomic give us a firm guarantee that for 32-bit types it will definitely produce an inline atomic access insn that will interwork with what we're using? At the moment our guard against this going wrong is that we don't link against libatomic (so we get a compile failure if the compiler decides to do something weird and out of line). thanks -- PMM
