qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] tls.h: Enable TLS on FreeBSD


From: Peter Maydell
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] tls.h: Enable TLS on FreeBSD
Date: Mon, 24 Jun 2013 22:30:21 +0100

On 24 June 2013 22:15, Paolo Bonzini <address@hidden> wrote:
> Il 24/06/2013 21:21, Ed Maste ha scritto:
>> Signed-off-by: Ed Maste <address@hidden>
>> ---
>> I have had this in a local tree for some time, and it is needed by the
>> BSD-user work that is now being proposed.
>
> At this time, qemu/tls.h is really just for cpu_single_env, so I think
> this patch should be applied together with the bsd-user patches that
> need it.

This patch has arrived because I suggested splitting it out from
those ;-) System mode qemu is multi-threaded, so moving more host
OSes into the fold of "these variables behave like the linux host
which is where the bulk of testing happens" sounds like a good idea
to me.

>> As an aside, an abstraction was recently proposed for Open vSwtich that
>> can use any of _Thread_local, __thread, or pthread_getspecific() which
>> may make a convenient reference for someone wishing to implement one of
>> the TODOs: http://openvswitch.org/pipermail/dev/2013-June/028665.html
>
> I and Stefan Hajnoczi have almost the same idea implemented in QEMU
> (except that get_foo() returns a pointer to the variable).  But
> pthread_get/setspecific would be too slow for cpu_single_env, so we're
> just switching to __thread for cpu_single_env (for Linux in our patches,
> but you can add FreeBSD too once it's needed).

I would really like cpu_single_env (and the other thread variables)
to have consistent semantics everywhere (which means "always thread
local"), even if that means "sometimes suboptimal performance".
Reasoning about a variable that might or might not be per-thread
is just painful. Alternatively, we could just drop support for any
host OS that doesn't provide reasonably efficient per-thread data.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]