For each valid window, we try first to store it on the stack in the domain's space as located by successively older stack frame pointer found in the register windows. If there are no faults, the wim is adjusted to reflect that windows have been saved and the CWP is put back as it was and the program resumes.
If some page from the stack should be unmapped however, it sets "data_obstacle" and falls into memory trap logic.
My first impression, however, is that the locore forgets that it has succeeded in saving some of the registers so that it will try to save them all again when the page is available. This looks like a problem for the kernel is coded with the implicit assumption that it is OK to steal one page when a fault occurs on another. There is a headway problem. Perhaps this is only a theoretical problem. If we were to avoid beginning over to store into that domain's stack it would be necessary to have another few bits in the domain to remember how many windows were in need of transfer from the domain to its stack. ARGH!
This is almost certainly poorly tested code. It would be an ideal application of the kernel irritation key that could cause a page from the stack to be unmapped. Actually it would be possible to unmap the page by a store into a slot of a memory node!