We want to use the finish_callback_and_resume() function because
it's well-tested and sets up everything just right, but it expects
that we're coming from another process. Unfortunately, in the
middle of all of this, we need to map a page back into the
destination process' memory space, so we end up starting from
the swapper's memory space, changing into the destination process'
memory space, then mapping the page, then changing back into
the swapper's memory space, then using the finish_callback_and_resume()
call.
I think the impact might not be *that* bad, mainly it's a TLB
miss and the PTW isn't super bad, and this comes after a disastrously
expensive decrypt-from-RAM operation -- so probably not worth it
to angonize over optimizing this bit at this point, and stick
with well-tested primitives.
There's two ways we can enter the swapper:
1. via an interrupt due to a page fault
2. via a syscall that generated a memory event (e.g. unmap)
This patch handles case (2) better and clarifies variable names
around that to make the code read better.
It also has logic to handle divergent looping through a large
unmap request.
The unmap syscall is a little bit tricky, because it can de-allocate
several pages at once, which can trigger an advisory de-allocate
message to the swapper in the middle of the loop. The entire structure
has to be re-written to handle this case, so we patch this right at
the top level syscall point and handle it entirely with custom
logic in the swapper.
@xobs made the `state` element of a process publicly read-only visible
through a function call. I don't think this is a security issue but
please lmk if that's a problem.
for now, we just count how mayn pages we missed an advisory on,
those all effectively are "wired". If we're fast enough on registering,
it turns out we actually miss nothing.
