PERFORCE change 75366 for review

[David Xu]

John Baldwin wrote:

>
> On Apr 17, 2005, at 6:42 AM, David Xu wrote:
>
>> http://perforce.freebsd.org/chv.cgi?CH=75366
>>
>> Change 75366 by davidxu at davidxu_alona on 2005/04/17 10:42:05
>>
>>     Implement cpu_set_user_tls for sparc64.
>>
>> Affected files ...
>>
>> .. 
>> //depot/projects/davidxu_thread/src/sys/sparc64/sparc64/vm_machdep.c#6 
>> edit
>>
>> Differences ...
>>
>> ==== 
>> //depot/projects/davidxu_thread/src/sys/sparc64/sparc64/vm_machdep.c#6 
>> (text+ko) ====
>>
>> @@ -194,6 +194,15 @@
>>      td->td_retval[1] = tf->tf_out[1];
>>  }
>>
>> +void
>> +cpu_set_user_tls(struct thread *td, void *tls_base, size_t tls_size,
>> +        int tls_seg __unused)
>> +{
>> +    if (td == curthread)
>> +        flushw();
>> +    td->td_frame->tf_global[7] = tls_base;
>> +}
>> +
>
>
> I think for at least this one and Alpha you might want a critical 
> section in the curthread case like you do on i386 and amd64 since 
> calling the Alpha PAL and setting tls_base + flushw() are more than 
> one instruction long.
>
If this is true, why don't set_mcontext on sparc64 and alpha enter
critical region ?
I enter critical region on i386 and amd64, because I have to write
global register (amd64 MSR) or gdt on i386, if thread is preempted,
then it may be in intermediate state, for example on amd64:
         td->td_pcb->pcb_fsbase = (register_t)tls_base;
--->
         wrmsr(MSR_FSBASE, td->td_pcb->pcb_fsbase);

if thread is preempted at ---->, a rdmsr in cpu_switch() will overwrite
the value I set before I can write it into MSR_FSBASE register.

David Xu