>- Maybe we can't convert virtual->physical addresses for a non-current
>   address space (which would make it impossible to access a
>   non-current space's memory even if it were faulted in).

You can always *convert* it, the question is at what cost.  (Any
virtual address is uniquely identified by the <v.a.space, v.a.value>
pair, where the vaspace can be identified by its proc or vmspace or
whatever you like.)

One of the kernel optimizations I never got around to, which should
help speed up context switching, is the "lazy context switch" in
which user-space address accesses, including those done in uiomove(),
start out with:

    if (current user space != target user space)
	vm_system.switch_user_context(target user space);
    ... do the usual job ...

Then as long as kernel stacks are all shared in a single global
"kernel address space" (usually true), the save/restore process
context code becomes pretty trivial.

Among other things, this allows the "thundering herd" that sometimes
occurs from a wakeup(&resource) with 1000 sleep(&resource)'s to
proceed quickly and relatively efficiently back into the sleep()
for 999 of the 1000 processes.  Obviously you still want to reduce
the number of processes spuriously awakened, but by deferring the
actual context switch, it becomes much less critical.

If the code to "switch user context" handled an arbitrary user space,
the above uiomove() would work even for processes other than the one
you intend to return to next / are running in the kernel "on behalf of".

Chris