[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.024 / U:10.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site