[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: Alex Smith <alex@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 4 Jul 2012 21:50:23 +0100
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 1 changeset to branch 'refs/remotes/xyzzy-github/x86_64'
> > old head: 4e8fbfb2d158de7b1cadd1c060acee51a7d67309
> > new head: 4304bb9894335fe5e5bd667a1f27dc7605c2e5b9
> >
> >
> ----------------------------------------------------------------------------
> >
> > 4304bb9: Added arch_cpu.cpp to the x86_64 build.
> >
> > * Some things are currently ifndef'd out completely for x86_64 because
> > they aren't implemented, there's a few other ifdef's to handle x86_64
> > differences but most of the code works unchanged.
> > * Renamed some i386_* functions to x86_*.
> > * 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>.
>
> [...]
> > diff --git a/headers/os/kernel/OS.h b/headers/os/kernel/OS.h
> > index 1f921f9..c3fe2b0 100644
> > --- a/headers/os/kernel/OS.h
> > +++ b/headers/os/kernel/OS.h
> > @@ -645,7 +645,7 @@ typedef enum cpu_types {
> >
> > #define B_CPU_x86_VENDOR_MASK 0xff00
> >
> > -#ifdef __INTEL__
> > +#if defined(__INTEL__) || defined(__x86_64)
>
> Not sure, if this is just a typo or if both macros are defined, but you
> usually use "__x86_64__".
>
Turns out that both are actually defined which is why I didn't notice that,
but I'll change it to __x86_64__ :)
Thanks,
Alex
Other related posts:
