Re: Assignment of GDT entries

[Linus Torvalds <torvalds@osdl.org>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/