linuxolator: tls_test results amd64

Jung-uk Kim jkim at FreeBSD.org
Tue Jan 23 22:59:04 UTC 2007


On Tuesday 23 January 2007 05:43 pm, Tijl Coosemans wrote:
> On Tuesday 23 January 2007 21:55, Jung-uk Kim wrote:
> > On Tuesday 23 January 2007 03:13 pm, Tijl Coosemans wrote:
> > > On Tuesday 23 January 2007 20:00, Jung-uk Kim wrote:
> > > > Second problem is MSR_KGSBASE is scrubbed by something during
> > > > context switch, i.e., it becomes 0 some times.
> > >
> > > You mean:
> > >
> > > *kernel sets gsbase and switches back to user mode
> > > *user program does things
> >
> > Yes.  BTW, glibc seems to use movw instead of movl to load %gs. 
> > I don't know if that makes difference, though.  It may have some
> > effect when glibc is built with -mtls-direct-seg-refs flag.  Need
> > confirmation.
>
> I think there's no difference between movw and movl. The first
> stores a 16 bit value in %gs, the second stores the lower 16 bits
> of a 32 bit value.
>
> That flag is interesting, but I think it only relates to using %gs
> after it has been set up for tls.
>
> > > *back in kernel mode, save gsbase into pcb and it appears to be
> > > 0 now?
> >
> > Saved pcb_gsbase seems always correct.  MSR_KGSBASE is not, which
> > is supposedly swapped with MSR_GSBASE via swapgs.  Maybe I am
> > confused, or maybe my CPU is too old (it's C0 stepping and I know
> > there are some segmentation issues with the revision) but that's
> > what I see. I need more time for testing (or resting?).
>
> Ok, I understand why pcb_gsbase is always correct. It is never
> written to except for cpu_set_user_tls, i386_set_gsbase and
> set_thread_area. cpu_switch only reads from it to restore gsbase.
> At least, that's what cpu_switch does in case of 64 bit programs,
> not 32 bit it seems. Why is that? Why is there a jmp on line 186 in
> sys/amd64/amd64/cpu_switch.S?

I believe it was part of peter and davidxu's micro optimizations, 
though.  I was experimenting with the cpu_switch.S but it might be 
hard to correct it without reverting the optimizations. :-(  We can 
probably add another pcb_flag?

Jung-uk Kim


More information about the freebsd-emulation mailing list