Hi
Jim Glent wrote:
Thanks for your reply.
It would seem that the pointer in %g7 is a waste from other piece of code -
gold to me by the way. I was able to use cpu.cpu_thread and cpu.cpu_dispthread
correctly however.
I have one more question.. How and when does the primary and/or secondary MMU
context with which each thread is associated change? Different threads on a
processor seem to always have different contexts. However, threads on different
processors must have different contexts? If a thread migrates, does it keep its
original context?
There are a few places (and maybe more added since last I knew
this code).
First place to look is in the resume() code - actually _resume_from_idle
since resume() always falls through to that. If you see who calls
resume you'll see it is the higher-level dispatch code of swtch()
and swtch_to() called from all the other "let's run this thread
now" code. The sun4 resume code is reponsible for saving the
context of one thread and restoring the context of the next-to-run
thread. See the SET_KCONTEXTREG in _resume_from_idle, followed
by possible calls to sfmmu_setctx_sec and sfmmu_alloc_ctx
depending on what we are switching from and to.
When running in non-supervisor mode - just a user thread running in
userland - your primary context is as setup for you in the
context allocation code at resume time. If this thread then
enters supervisor mode at all - ie it traps - then the context
registers are not automatically changed (while you're at
traplevel > 0 you're in "nucleus context" which is hardwired
as 0 and so trap handling can ran without needing to
setup context regs). The TL > 0 handlers can still access
stuff from the trapped userland context using the
"as if user primary" and "as if user secondary" ASIs to
access primary and secondary user context. That's done in
emulating instructions, for example. But if a trap handler
needs to run for longer and move from nucleus context (TL > 0)
to TL=0 but still supervisor mode then it calls sys_trap or
user_trap. That is a hideous wedge of amazingly complex code,
but part of that code is to arrange that primary context
becomes kernel and secondary context the previous userland
primary context; in this way the trap handler can still access
the userland address space. So that's what happens on say
a system call - an initial component of TL > - handling and then
call user_trap to enter the kernel fully. When the trap handling
is done and we wish to return to userland the context is restored -
see user_rtt code.
Gavin
I am running under a simulator and at times the simulator breaks and I must
determine what thread is executing on each cpu. It has to do with obtaining the
memory access pattern of a set of applications.
jimglent
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
