On 09/21/07 18:18, Haris wrote:
Hey -In OpenSolaris on SPARC when we are running a process the register windows' register OTHERWIN marks
> the register windows used by the kernel. The opposite happens when we are in
kernel, i.e OTHERWIN
> marks the register windows used by the process.
Yes, this switch happens at the begining of user_trap where we were running in
user mode
and trapped to nucleus context and decide that we need to go to C and traplevel
0 in the
kernel to handle the trap. ie the switch only happens on full kernel entry,
and not
just for switch to supervisor mode. From user_trap prologue:
!
! set window registers so that current windows are "other" windows
!
rdpr %canrestore, %l0
rdpr %wstate, %l1
wrpr %g0, 0, %canrestore
sllx %l1, WSTATE_SHIFT, %l1
wrpr %l1, WSTATE_K64, %wstate
wrpr %g0, %l0, %otherwin
Since we are going to C it is very likely that some of these "other"
user windows will have to be spilled as we go down the call stack.
They are not spilled to the user stack but to "wbufs" - see wbuf.s
and mentions elsewhere. Good luck in reading that code - about as
difficult as it gets for low-level sparc bits!
My question is whether there is any guarantee that when running in a process the kernel does not use any register windows and has the OTHERWIN set to 0.
Yes, see user_rtt which us the "user return from trap" code which gets us back
to
the user code that was running when we trapped:
! switch "other" windows back to "normal" windows.
rdpr %otherwin, %g1
wrpr %g0, 0, %otherwin
add %l3, WSTATE_CLEAN_OFFSET, %l3 ! convert to "clean" wstate
wrpr %g0, %l3, %wstate
wrpr %g0, %g1, %canrestore
This restores any remaining user windows back as "normal" windows (they
were "other" windows after the kernel entry), and writes zero to
%otherwin so that when we return to running user code there
are no "other" windows.
This question is an extension of
> the question whether the kernel needs to keep the kernel stack when it returns back to a process. > I see two cases happening. The first case is when you block in the kernel. In such a case
you need to keep the kernel stack. However the kernel forces a context switch which is flushing
> the register windows, so the OTHERWIN is set to 0. The second case is when you go into the kernel, > do something, and return back. I don't see any reason of keeping the kernel stack at such a case,
so the register windows used while in the kernel should also get invalidated and therefore OTHERWIN is 0. Any comments on that?
Strictly speaking register windows and stacks are independent - spill/fill handlers do not have to work with the stack as a place to store/retrieve register windows (eg the wbuf.s code spills elsewhere). Your reasoning that otherwin can (and should) be zero on return to userland is correct. Hope that helps. It's a bottomless subject. Gavin
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
