[haiku-commits] Re: BRANCH xyzzy-github.x86_64 - src/system/kernel/arch/x86 src/system/kernel/arch/x86/64 src/system/kernel/arch/x86/32 headers/private/kernel/arch/x86 headers/private/kernel/arch/x86/32
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 04 Jul 2012 23:30:59 +0200
Alex Smith wrote:
> On 4 July 2012 20:44, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2012-07-04 at 15:49:11 [+0200], xyzzy-github.x86_64
> > <community@xxxxxxxxxxxx> wrote:
> > > * Added a temporary method for setting the current thread on x86_64
> > > (a global variable, not SMP safe). This will be changed to be done
> > > via the GS segment but I've not implemented that yet.
> >
> > A relatively simple (and even quite portable) method would be to align the
> > kernel stack areas to a power of two at least >= the stack size and put a
> > pointer to the thread structure (or even the thread structure itself) at
> > the
> > top of the stack. This way the thread pointer can be derived quickly from
> > the
> > stack pointer.
>
> Although x86_64 mostly kills segmentation and allows only zero segment
> bases, it allows the GS segment base to be modified through an MSR. There
> is a second MSR, KernelGSbase, and the SWAPGS instruction exchanges those 2
> base addresses. What that's supposed to be used for is when implementing
> system calls through SYSCALL/SYSRET: SYSCALL doesn't set the stack pointer,
> so you point KernelGSbase to somewhere where your stack pointer is stored,
> and upon entry you do a SWAPGS and you can then get your stack pointer
> through the GS segment.
>
> Seeing as I'd be doing that for SYSCALL, I was going to reuse the same
> mechanism to store the current thread pointer: in arch_thread, have a
> pointer to the Thread it's contained in (as well as the stack pointer for
> SYSCALL) and point GS to the start of arch_thread, so getting the thread
> pointer would just be mov %gs:0, %<dest>.
Sounds like a plan. :-)
CU, Ingo
Other related posts:
