On 2011-10-26 18:27, Andreas Färber wrote:
> Am 26.10.2011 18:02, schrieb Jan Kiszka:
>> On 2011-10-26 17:18, Peter Maydell wrote:
>>> On 26 October 2011 16:13, Jan Kiszka wrote:
My point is that it is fine to use for per-vcpu variables because:
- they are single-threaded in TCG mode
>>
Am 26.10.2011 18:02, schrieb Jan Kiszka:
> On 2011-10-26 17:18, Peter Maydell wrote:
>> On 26 October 2011 16:13, Jan Kiszka wrote:
>>> My point is that it is fine to use for per-vcpu variables because:
>>> - they are single-threaded in TCG mode
>>> - they are multi-threaded in KVM mode, but tha
On 2011-10-26 17:18, Peter Maydell wrote:
> On 26 October 2011 16:13, Jan Kiszka wrote:
>> My point is that it is fine to use for per-vcpu variables because:
>> - they are single-threaded in TCG mode
>> - they are multi-threaded in KVM mode, but that's only affecting Linux
>> hosts for which t
On 26 October 2011 16:13, Jan Kiszka wrote:
> My point is that it is fine to use for per-vcpu variables because:
> - they are single-threaded in TCG mode
> - they are multi-threaded in KVM mode, but that's only affecting Linux
> hosts for which this TLS wrapper is already usable
Oh, I see. Fe
On 2011-10-26 17:09, Peter Maydell wrote:
> On 26 October 2011 16:02, Jan Kiszka wrote:
>> On 2011-10-26 16:54, Peter Maydell wrote:
>>> On 26 October 2011 15:39, Paolo Bonzini wrote:
On 10/26/2011 04:03 PM, Peter Maydell wrote:
>
> For the record (since I think we only talked about
On 26 October 2011 16:02, Jan Kiszka wrote:
> On 2011-10-26 16:54, Peter Maydell wrote:
>> On 26 October 2011 15:39, Paolo Bonzini wrote:
>>> On 10/26/2011 04:03 PM, Peter Maydell wrote:
For the record (since I think we only talked about this on IRC):
* the POSIX TLS fallback code
On 2011-10-26 16:54, Peter Maydell wrote:
> On 26 October 2011 15:39, Paolo Bonzini wrote:
>> On 10/26/2011 04:03 PM, Peter Maydell wrote:
>>>
>>> For the record (since I think we only talked about this on IRC):
>>> * the POSIX TLS fallback code doesn't work on Linux hosts for
>>>linux-user e
On 10/26/2011 04:54 PM, Peter Maydell wrote:
On 26 October 2011 15:39, Paolo Bonzini wrote:
On 10/26/2011 04:03 PM, Peter Maydell wrote:
For the record (since I think we only talked about this on IRC):
* the POSIX TLS fallback code doesn't work on Linux hosts for
linux-user emulation (t
On 26 October 2011 15:39, Paolo Bonzini wrote:
> On 10/26/2011 04:03 PM, Peter Maydell wrote:
>>
>> For the record (since I think we only talked about this on IRC):
>> * the POSIX TLS fallback code doesn't work on Linux hosts for
>> linux-user emulation (the constructor is never called to set
On 10/26/2011 04:03 PM, Peter Maydell wrote:
For the record (since I think we only talked about this on IRC):
* the POSIX TLS fallback code doesn't work on Linux hosts for
linux-user emulation (the constructor is never called to set up
the TLS for the main thread, probably something to
On 5 October 2011 10:21, Paolo Bonzini wrote:
[tls patches]
> If interested people can test the patches more and submit them more
> formally, I'd be very glad. I wrote it for RCU, but of course that one is
> not really going to be 1.0 material (even for 9p).
For the record (since I think we only
On 10/07/2011 07:29 PM, David Gilbert wrote:
Hmm this got a bit more complex than the original patch; still it covers a lot
more bases.
Should this also replace the THREAD that's defined in
linux-user/qemu.h and bsd-user/qemu.h (that is __thread if built with
NPTL)?
It seems to only be there for
On 5 October 2011 10:21, Paolo Bonzini wrote:
> If interested people can test the patches more and submit them more
> formally, I'd be very glad. I wrote it for RCU, but of course that one is
> not really going to be 1.0 material (even for 9p).
Hmm this got a bit more complex than the original
On 10/05/2011 09:52 AM, Jan Kiszka wrote:
Yeah, it probably makes sense to build the abstractions around __thread
so that - one day - we can drop the legacy wrappers.
Just do not prepend "tls__" in the gcc model
Actually I did that on purpose so that people would not forget get_tls. :)
(ther
On 2011-10-05 09:08, Paolo Bonzini wrote:
> On 10/04/2011 07:26 PM, Jan Kiszka wrote:
>> Looks like a start. But I would avoid macros and go for (static inline)
>> functions where possible. And initialization should be explicit (so that
>> you can start using TLS already inside constructors).
>
>
On 10/04/2011 07:26 PM, Jan Kiszka wrote:
Looks like a start. But I would avoid macros and go for (static inline)
functions where possible. And initialization should be explicit (so that
you can start using TLS already inside constructors).
Here is the patch I wrote to do more or less the same
On 2011-10-04 17:10, Lluís Vilanova wrote:
> Jan Kiszka writes:
>
>> On 2011-10-03 18:33, Dr. David Alan Gilbert wrote:
>>> Make cpu_single_env thread local (Linux only for now)
>>> * Fixes some user space threading issues (esp those triggered
>>> by bug 823902)
>>>
>>> Against rev d11cf8cc..., te
Jan Kiszka writes:
> On 2011-10-03 18:33, Dr. David Alan Gilbert wrote:
>> Make cpu_single_env thread local (Linux only for now)
>> * Fixes some user space threading issues (esp those triggered
>> by bug 823902)
>>
>> Against rev d11cf8cc..., tested on ARM user mode, and ARM Vexpress
>> system mo
On 2011-10-03 18:33, Dr. David Alan Gilbert wrote:
> Make cpu_single_env thread local (Linux only for now)
> * Fixes some user space threading issues (esp those triggered
> by bug 823902)
>
> Against rev d11cf8cc..., tested on ARM user mode, and ARM Vexpress
> system mode (with Blue Swirl'
Make cpu_single_env thread local (Linux only for now)
* Fixes some user space threading issues (esp those triggered
by bug 823902)
Against rev d11cf8cc..., tested on ARM user mode, and ARM Vexpress
system mode (with Blue Swirl's fix from yesterday) - only
tested on Linux host. Lets me run
20 matches
Mail list logo
