On Aug 26, 2005, at 12:14 PM, Keir Fraser wrote:
On 26 Aug 2005, at 17:38, Hollis Blanchard wrote:
Hmmmmm. I think the basic problem is that in the exception handler we
don't usually know we will need this state. The exception is a debug
exception, where we know we will need it for the GDB stub.
However, we also have a hypervisor-dedicated timer, HDEC (hypervisor
decrementer). Rather than using it as a plain tick which may or may
not cause a scheduler exception, we can use it to *always* mean a
context switch. In that case, we would always save the full state on
HDEC entry, because we know it will always cause a context switch.
Judging by set_ac_timer() callers, it seems that only the scheduler
really uses the Xen timer tick. If non-scheduler components start
using Xen-internal ticks, this approach wouldn't hold up (or rather,
it would start becoming less efficient).
Why not move the non-volatile save/restore into your context switch
routine, rather than deferring it until you exit the hypervisor?
This is a key point. r14-r31 are nonvolatile in our C ABI, which means
that callees must preserve their contents for callers. At a high level,
our exception handlers look like this:
exception:
save r0-r13 to cpu_user_regs
call c_handler
restore r0-r13
return
We know that c_handler() will use r14-r31, but we also know that when
it returns, their contents will have been restored. So saving and
restoring them in assembly would be a waste of time.
context_switch() will be called from somewhere beneath c_handler(). At
that point, the original nonvolatiles will have been saved across many
stack frames (starting with c_handler()'s), so we really are unable to
access them at this point. However, we trust that by the time we get
back to the exception handler, the original nonvolatiles will have been
restored off all those stack frames.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home