From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV9GV-000845-Kx for qemu-devel@nongnu.org; Thu, 27 Aug 2015 22:19:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV9GS-0004t5-HX for qemu-devel@nongnu.org; Thu, 27 Aug 2015 22:19:39 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:33934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV9GS-0004s5-8z for qemu-devel@nongnu.org; Thu, 27 Aug 2015 22:19:36 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5F75C2034C for ; Thu, 27 Aug 2015 22:19:31 -0400 (EDT) Date: Thu, 27 Aug 2015 22:19:54 -0400 From: "Emilio G. Cota" Message-ID: <20150828021954.GA25092@flamenco> References: <1440548265-4755-1-git-send-email-pbonzini@redhat.com> <1440548265-4755-7-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440548265-4755-7-git-send-email-pbonzini@redhat.com> Subject: Re: [Qemu-devel] [PATCH 6/9] tcg: synchronize cpu->exit_request and cpu->tcg_exit_req accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, qemu-devel@nongnu.org, rth@twiddle.net On Wed, Aug 26, 2015 at 02:17:42 +0200, Paolo Bonzini wrote: > Signed-off-by: Paolo Bonzini > --- > cpu-exec.c | 6 +++++- > qom/cpu.c | 2 ++ > 2 files changed, 7 insertions(+), 1 deletion(-) I like this patch. Are we making sure that other writes to tcg_exit_req are preceded by a write barrier? For instance: qom/cpu.c-116- cpu->exit_request = 1; qom/cpu.c:117: cpu->tcg_exit_req = 1; translate-all.c-1478- } else { translate-all.c:1479: cpu->tcg_exit_req = 1; translate-all.c-1643- cpu->interrupt_request |= mask; translate-all.c:1644: cpu->tcg_exit_req = 1; Current master certainly doesn't have them, but I wonder if you have barriers at those places in the tree you're working on. If not I'd expand this patch to add them. And while at it, can we pleeease get rid of the hideous 'volatile sigatomic_t' type for tcg_exit_req? Thanks, Emilio