Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu

[Jamie Lokier <jamie@shareable.org>]

Jan Kiszka wrote:
> Glauber Costa wrote:
> > On Mon, Aug 31, 2009 at 01:04:52PM +0100, Jamie Lokier wrote:
> >> Glauber Costa wrote:
> >>> On Sat, Aug 29, 2009 at 02:22:27AM +0100, Jamie Lokier wrote:
> >>>> Anthony Liguori wrote:
> >>>>> Glauber Costa wrote:
> >>>>> Since we already keep the tid in the vcpu structure, it seems to make 
> >>>>> more sense to ask "am I this vcpu thread" by doing gettid() == env->tid 
> >>>>> than by maintaining a new global tls variable.
> >>>> Note that a tls variable will be much faster than gettid().  Don't
> >>>> know if you're talking about a hot path.
> >>> just to be sure, TLS is not supported on all our linux target hosts, right?
> >>>
> >>> We can probably wrap it into a function that uses gettid on linux (or whatever
> >>> in other platforms), and uses a TLS variable where available. (and if needed).
> >>>
> >>> I can agree with anthony that although TLS is in fact faster, we might not need it.
> >>> I doubt that anything that communicates using signals will be the hot path for anything.
> >> I was going to say just use pthread_self()!  It's fast like TLS on all
> >> hosts, and more portable then gettid().
> >>
> >> But then you mentioned signals.  I'm not sure if the code in question
> >> is inside signal handlers.
> > Signals are just used to wake up the other cpu. I think it is pretty valid
> > to rule out usage insigne signal handlers (mention in comments, etc).
> > 
> > I'll propose that switch on qemu-kvm, which already uses tls variables, and see
> > what the response is.
> > 
> 
> To my experience, TLS can cause a lot of problems, but only when used
> close to inline assembly (gcc is still horribly broken then, clobbering
> or "optimizing" register content, specifically on ARM). I do not expect
> problems for our standard use cases.
> 
> But in case someone still does not feel well about it:
> pthread_get/set_specific can serve as a "safer" alternative that is also
> syscall-free (where possible).

Just so y'all know, pthread_get/set_specific are also unsafe inside
signal handlers for the same reason as pthread_self is unsafe.

-- Jamie