Re: Assignment of GDT entries

[Jeremy Fitzhardinge <jeremy@goop.org>]

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

So does this mean that moving the user-visible cs/ds isn't likely to 
break stuff, if it has been done before?

> 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.
>   

Yep, I'm aware of that constraint.

> 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.
>   

Do you mean that something like dosemu/Wine needs to be able to use GDT 
#8?  Or is it only used in kernel code?

> 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,

Why's that?  That cacheline (assuming 64 byte line size) already 
contains the user/kernel/cs/ds descriptors.

I'm thinking of putting together a patch to change the descriptor use to:

    8  - TLS #1
    9  - TLS #2
    10 - TLS #3
    11 - Kernel PDA
    12 - Kernel CS
    13 - Kernel DS
    14 - User CS
    15 - User DS
      

This has the advantage of leaving the user cs/ds unchanged.  From what 
people had said so far, this should be OK, other than making the heavily 
used TLS #1 share the BIOS common area entry number.  If this needs to 
be usable by userspace for something special, then making it TLS #1 
won't fly...

Alternatively, maybe:

    0  - NULL
    1  - Kernel PDA
    2  - Kernel CS
    3  - Kernel DS
    4  - User CS
    5  - User DS
    6  - TLS #1
    7  - TLS #2
      

which moves the user cs/ds, but avoids #8.

    J