Subject: Re: VAX and vfork
To: Anders Magnusson <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/25/1998 15:12:51
>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...