Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp

[Peter Maydell]

On 11 August 2011 15:10, Paolo Bonzini <address@hidden> 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