This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: lazy context switching

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:

        save r0-r13 to cpu_user_regs
        call c_handler
        restore r0-r13

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