|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp |
Date: | Thu, 11 Aug 2011 16:10:03 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |