From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVaKR-0001SX-Qi for qemu-devel@nongnu.org; Sat, 29 Aug 2015 03:13:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVaKO-0002eJ-KL for qemu-devel@nongnu.org; Sat, 29 Aug 2015 03:13:31 -0400 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:32819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVaKO-0002e5-Cr for qemu-devel@nongnu.org; Sat, 29 Aug 2015 03:13:28 -0400 Received: by wicne3 with SMTP id ne3so3115461wic.0 for ; Sat, 29 Aug 2015 00:13:27 -0700 (PDT) Sender: Paolo Bonzini References: <1439397664-70734-1-git-send-email-pbonzini@redhat.com> <1439397664-70734-7-git-send-email-pbonzini@redhat.com> From: Paolo Bonzini Message-ID: <55E15B99.8000908@redhat.com> Date: Sat, 29 Aug 2015 09:13:29 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 06/10] tcg: code_bitmap is not used by user-mode emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: mttcg@greensocs.com, QEMU Developers , =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= 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