[Xen-devel] Re: lazy context switching

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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