[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:
    > So does this mean that moving the user-visible cs/ds isn't likely to break
    > stuff, if it has been done before?

    Yes. I _think_ we could do it. It's been done before, and nobody noticed.

    That said, it may actually be that programs have since become much more
    aware of segments, for a rather perverse reason: the TLS stuff. Old
    programs are all very much coded and compiled for a totally flat model,
    and as such they really don't know _anything_ about segments. But with
    more TLS stuff, it's possible that a modern threded program is at least
    aware of _some_ of it.

    In other words - I _suspect_ we can move things around, but it would
    require some rather heavy testing, at least. Especially programs like Wine
    might react badly.

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

    Both. I think the APM BIOS callbacks use GDT#8 too. As long as it's not
    one of the really _core_ kernel segments, that's ok (you can swap it
    around and nobody will care). But it would be a total disaster (I suspect)
    if GDT#8 was the kernel code segment, for example. Suddenly the "switch
    things around temporarily" is not as trivial any more, and involves nasty
    nasty things.

    [ BUT! I haven't ever really had much to do with those BIOS callbacks, and
    I'm too lazy to check, so this is all from memory. ]

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

    Right. That's what I'm saying. We should move them all together, and we
    should keep them as aligned as they are now.

    > I'm thinking of putting together a patch to change the descriptor use to:
    > 8 - TLS #1
    > 9 - TLS #2
    > 10 - TLS #3

    So I'd not be surprised if movign the TLS segments around would break

    > 11 - Kernel PDA

    But you keep the four basic ones in the same place:

    > 12 - Kernel CS
    > 13 - Kernel DS
    > 14 - User CS
    > 15 - User DS

    So that's obviously ok at least for _those_.

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

    I don't like that one, exactly because now the four most common segments
    (which get accessed for all system calls) are no longer in the same
    32-byte cacheline.

    [ Unless we start playing games with offsetting the GDT or something..
    Quite frankly, I'd rather keep it simple and obvious. ]

    Now, most systems have a 64-byte cacheline these days (and some have a
    split 128-byte one), and maybe we'll never go back to the "good old days"
    with 32-byte lines, so maybe this is a total non-issue. But fitting in the
    same 32-byte aligned thing would still count as a "good thing" in my book.

    That said, numbers talk, bullshit walks. If the above just works a lot
    better for all modern CPU's that all have 64-byte cachelines (because now
    _everything_ is in that bigger cacheline), and if you can show that with
    numbers, and nothing breaks in practice, then hey..

    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:1.602 / U:6.420 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site