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".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
