From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrVxe-0007zE-86 for qemu-devel@nongnu.org; Thu, 11 Aug 2011 10:10:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrVxa-0002tG-5Q for qemu-devel@nongnu.org; Thu, 11 Aug 2011 10:10:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrVxZ-0002t1-S9 for qemu-devel@nongnu.org; Thu, 11 Aug 2011 10:10:10 -0400 Message-ID: <4E43E2BB.1020403@redhat.com> Date: Thu, 11 Aug 2011 16:10:03 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4E0CA885.2050308@siemens.com> <4E0ECDDB.9030001@web.de> <4E43C80B.1050300@redhat.com> <4E43D585.90907@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , TeLeMan , Jan Kiszka , qemu-devel , David Gilbert On 08/11/2011 03:31 PM, Peter Maydell wrote: >>> >>> Then it's a compiler bug, not smartness. Making env volatile >>> (or making a volatile copy if there is a performance impact) >>> should still be enough to work around it. > Yes. (It would have to be a volatile copy, I think, env is a function > parameter and I don't think you can make those volatile.) > https://bugs.launchpad.net/qemu/+bug/823902 includes some discussion > of the effects on the test of adding the volatile copy. I'm not sure about what to read from there: > If I make cpu_single_env thread local with __thread and leave > 0d101... in, then again it works reliably on 32bit Lucid, and is > flaky on 64 bit Oneiric (5/10 2 hangs, 3 segs) > > I've also tried using a volatile local variable in cpu_exec to hold > a copy of env and restore that rather than cpu_single_env. With this > it's solid on 32bit lucid and flaky on 64bit Oneirc; these failures > on 64bit OO look like it running off the end of the code buffer (all > 0 code), jumping to non-existent code addresses and a seg in > tb_reset_jump_recursive2. It looks like neither a thread-local cpu_single_env nor a volatile copy fix the bug?!? I cannot think off-hand of a reason why thread-local cpu_single_env should not work for iothread under Unix, BTW. Since cpu_single_env is only set/used by a thread at a time (under the global lock), its users cannot distinguish between a thread-local variable and a global. The only problem would be Windows, which runs cpu_signal in a thread different than the CPU thread. But that can be fixed easily in qemu_cpu_kick_thread. Paolo