>Yes, I know that there is some problem with this on some types of CPUs.
>It is due to the pmap_activate() semantics which I haven't got clear
>for me how they are. As soon as I know this I will fix it.
>(FYI it doesn't work on 780, but on my MVII).

Heh, It'd probably help if the person who (re-)introduced
pmap_activate() had ever _given_ reasonable MI semantics for it ;).

>From conversations about the exact same issue on the mips port, 
you need to do one of two things, I cant' remember which:

   a) change the effective userland VM context such that,
     on the next return to userspace,  the argument to pmap_activate()
     is the VM context that becomes active;

   b) make the given pmap active _now_.

You could try looking at the Mach VM source for a vax and see what
they do.  Of course, on a vax, this is kind of tricky, because (iirc)
you can't change the `VM context' independent of the rest of the
hardware PCB (registers, etc).

One way to do (b) is to save all the CPU registers, fudge up a
hardware PCB from the given pmap and saved registers, and do a LDPCTXT
on that.  (pointing the PC at a ret instruction.)  That may be more
heavyweight than is required, but it should work.

I guess you'll have to do another LDPCTXT when returing to userspace
in any case, to change ksp to the new processes' kernel stack?  Gag...