On 28/08/2015 16:57, Peter Maydell wrote: >> > More #ifdefs are not nice, but this clarifies why its usage is not >> > protected by tb_lock. > Does it? I thought the idea of this series was to add locking > which we needed for adding multi-threading to softmmu, in > which case presumably we need to protect this with a lock > of some kind whether we're using softmmu or usermode.
No, the idea of the series was to base softmmu multi-threading on user-mode multi-threading, and document what else needs to be done with respect to common code. Adding the necessary locks for softmmu only comes in the "extra" patches 11 and 12, and protecting code_bitmap with a lock (presumably tb_lock, or its own lock, I don't know) would belong there. However I left this job to Fred, and similarly for breakpoints. I'm not sure if it makes sense to add locking (like patches 11 and 12) in the absence of actual multi-threading. On one hand it would make it simpler to commit the MTTCG work in steps. On the other hand it risks bitrotting. The possibility of bitrot is another point in favor of making more code #ifdef CONFIG_SOFTMMU; it would clearly identify areas where locking correctness never matters in practice, and thus bugs may be hidden. Paolo
