On 11 August 2011 15:10, Paolo Bonzini <pbonz...@redhat.com> wrote: > 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?!?
My guess is that we're running into the various other problems qemu has with significantly multithreaded programs in user-mode, which makes it a bit hard to disentangle this specific regression. (In particular segfaults in tb_reset_jump_recursive2 are almost certainly bug 668799.) > 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. Thanks for the clarification. As you say, as long as we don't ever try to access it from another thread we're fine... > 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. ...and we just need to fix this. -- PMM