On Fri, Dec 18, 2009 at 08:19:02AM -0700, Jerry Jelinek wrote:
> Jerry Jelinek wrote:
> >Because its not right above, all of the other register values are
> >also pushed on the stack, so we need to go through the SSP to get
> >to the right spot.  I can add a comment explaining this but the
> >32bit and 64bit stacks are not identical.
> Ed,
> Actually, what I said above is not quite right.  I think that
> its not the other registers but the alignment that is making
> the stacks different.  I took another look at the AMD64 Architecture
> Programmers Manual, Volume 2: System Programming manual.  This is
> discussed in section 8.9 Long-Mode Interrupt Control Transfers.  You
> can see how the stack is different vs. the discussion in section 8.7.

all the comments in our source code would seem to indicate that the
stacks are the same.  also, looking at the stack diagram in the v2
manual they seem to be the same to me (aisde from the obvious 32 vs 64
bit word size differences):

        Figure 8-9 Stack After Interrupt to Higher Privilege
        p280 (p320)

        Figure 8-14 Long-Mode Stack After Interrupt-Higher Privilege
        p292 (p332)

also, right above figure 8-14 there is a discussion of the differences
between the long mode switch vs the classic legacy switch, with the only
difference being in how the SS is handled.

i guess this boils down to is, is there a difference between the value
of V_SSP and address of V_END, and if so why?  i set some breakpoints in
kmdb and compared these values and they are indeed different.  looking
at brand callback i can now see why, we do the following:
#define BRAND_CALLBACK(callback_id)                                     \
        movq    %rsp, %gs:CPU_RTMP_RSP  /* save the stack pointer       */ ;\
        movq    %r15, %gs:CPU_RTMP_R15  /* save %r15                    */ ;\
        movq    %gs:CPU_THREAD, %r15    /* load the thread pointer      */ ;\
        movq    T_STACK(%r15), %rsp     /* switch to the kernel stack   */ ;\

so we're actually changing our stack pointer after entry into the
kernel, so it's no longer necessarily matching the interrupt stack that
the processor switched in automatically and saved the parameters on.
notably we don't do this for 32-bit kernels.  this means that
de-referencing V_SSP is the right things todo.  sorry for taking so long
to understand this code...

so one last comment nit and then i promise i'm done.  could you update
the the descriptions of the stack setup by BRAND_CALLBACK on 64-bit
kernels to be more accurate for interrupt syscalls by changing:
        "user stack pointer"
        "user (or interrupt) stack pointer"

thanks, and sorry again for the delays while i tried to understand the
code better.

zones-discuss mailing list

Reply via email to