[lkml]   [2006]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Assignment of GDT entries

On Wed, 13 Sep 2006, Jeremy Fitzhardinge wrote:
> *
> * 4 - unused <==== new cacheline
> * 5 - unused

These _used_ to be the "user CS/DS" respectively, but that got changed
around by me when did the "sysenter" support.

The sysenter logic (or, more properly, the sysexit one) requires that the
user code segment number is the same as the kernel code segment +2 (ie
"+16" in actual selector term). And the user data segment needs to be +3.

So with sysenter, we needed a block of four contiguous segments: kernel
code, kernel data, user code, user data (in that order).

There are other possible things to do, but what we did was to move the
user segments up to just above the kernel ones (which we left in place).

> * 6 - TLS segment #1 [ glibc's TLS segment ]
> * 7 - TLS segment #2 [ Wine's %fs Win32 segment ]
> * 8 - TLS segment #3
> * 9 - reserved
> * 10 - reserved
> * 11 - reserved

These are really reserved, I think we left them that way on purpose so
that if we wanted to, we can allow more of the contiguous per-thread
state. And segment #8 (ie 0x40) is special (TLS segment #3), of course.
Anybody who wants to emulate windows or use the BIOS needs to use that for
their "common BIOS area" thing, iirc.

I think it's generally a good idea to keep the low segment reserved (or at
least free to use for whatever user code), since if there are any special
magic segment descriptor numbers, they tend to be in that low range. The
#8/0x40 thing is just an example.

> What are entries 1-3 and 9-11 reserved for? Must they be unused for some
> reason, or is there some proposed use that has not been impemented yet?
> Also, is there a particular reason kernel GDT entries start at 12? Would
> there be a problem in using either 4 or 5 for a kernel GDT descriptor?

See above. The kernel and user segments have to be moved as a block of
four, and obviously we'd like to keep them in the same cacheline too.
Also, the cacheline that contains segment #8/0x40 is not available, so
that together with keeping low segments for user space explains why it's
at segment numbers #12-15 (selectors 0x60/0x68/0x73/0x7b).

But I don't think anything but 0x40 is "set in stone".

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.187 / U:3.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site