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: ---8<--- #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 */ ;\ ---8<--- 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" to: "user (or interrupt) stack pointer" thanks, and sorry again for the delays while i tried to understand the code better. ed _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org