qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] using thread local storage (TLS) instead of the fs register


From: Rafael Ávila de Espíndola
Subject: [Qemu-devel] using thread local storage (TLS) instead of the fs register
Date: Fri, 10 Sep 2004 21:54:19 -0300
User-agent: KMail/1.7

Currently qemu uses a fixed entry (1) in the ldt and the fs register to save 
esp register during the execution of code generated by code coping. This does 
not work with multiples threads created with the CLONE_VM option because the 
child will overwrite the data of the parent in the entry 1 of the ldt.

One possible solution would be to use multiple entries in the ldt. One for 
each thread. Glibc did this some time ago: http://lwn.net/Articles/5851/

Another one would be to use thread local storage 
(http://people.redhat.com/drepper/tls.pdf).  Internally (on IA-32) the gs 
segment will be used but the kernel mantains a differten gdt for each thread. 
I think this is a better solution since it is one step closer to make the 
implementation of code copy possible in other architectures.

I am having some trouble in implementing this solution. The first one is that 
I don't know how to find how much memory is necessary for TLS in a 
dynamically linked app. In a statically linked one can read 
_dl_tls_static_size. The second one is that the generated code that 
previously referred to an offset from fs now refers to a global addres that 
depends on which thread the code was generated!  So the code generated in one 
thread cannot be used in another.

I have hacked the code to do the following:
1) Remove the fs prefix from the generated code
2) Don't change the ldt
3) Do not allocate a new cpustate in cpu_init. Just return a pointer to a 
thread local variable.
4) call cpu_init from within the new thread
5) call clone with CLONE_SETTLS

It does not work yet (maybe because of invalid reuse of generated code). In 
fact the behaviour of qemu becomes very dependant of any delay (sleep for 
example) introduced just before calling cpu_loop. I am submitting the patch 
in the hope that someone will be able to explain some of the problems that I 
am having or at least prove that TLS is not applicable to qemu (the sooner 
the better :) ).

Thanks for any comment.

Rafael

Attachment: qemu.patch.gz
Description: GNU Zip compressed data

Attachment: pgp32K1MhyJVB.pgp
Description: PGP signature


reply via email to

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