Ramon van Handel wrote:
>
> >I don't quite see how that is supposed to work ... What do
> >you mean by 'synchronizing' with the host page table?
> >
> >The Linux swapper simply removes a page from a page table
> >whenever it likes to do so (and the page isn't locked), and
> >re-uses the page. On a multi-processor machine, this can
> >happen at any time even while a VM is running.
> >
> >If the page is at that time also entered into a page table
> >maintained by FreeMWare, you'll clobber memory. Therefore,
> >you cannot allow the swapper to swap out pages in use by a
> >VM, and thus they must be locked.
>
> You have a point. Hadn't thought of that. Okay, never mind ;)
We could implement our own swapping mechanism without much
problem. I think this is what Ulrich is talking about, but
what I was think was...
The processor will mark Accessed and Dirty bits for us in page
table entries. So our algorithm could be to periodically look
at what's been used, and mark some unused pages as not-present and
mark them as swappable in the host. This way if the host swaps
them out, there won't be a conflict with the monitor/guest, since
a trap will occur on any access to them.
When we receive a trap in the guest for a page that should be there,
then we have to switch back to the host, lock the page back down in
the host, and mark the page as present/accessible in the monitor/guest.
Definitely, we need to use proper host services to remark the page
mapping change, so this is done correctly in light of MP machines.
Anyways, this is just a classic swapping algorithm reiterated
for Nth time. We just make sure that any page is swappable by
at most one of either the host or monitor/guest.
The parameters to think about are what kinds of things can we look
for to make smarter decisions about the pages to make swappable.
Obviously, we have to exclude any of the monitor specific code/data pages,
since they are required to be there during exceptions so that the
monitor can function. We could simply keep some meta information
regarding guest pages, such as time-stamps on when they were put
into action, and maybe some feedback info from the swapping mechanism,
so frequently used pages get swapped out, and infrequently used pages
can be selected for host swapping. Maybe track the CPL of the process
using the page. Whatever else we can think of. Whatever we chose,
it won't be perfect for all cases. Perhaps we can make some RC file
config options, so you can play with the settings.
Any of you OS design weenies should chime in here. :^) I'm sure
paging strategies have been beat to death - no sense reinventing them.
Note that we never really do any swapping. We always pass that off
to the host OS. But the concept is the same. We just use a similar
strategy without implementing the actual swap.
-Kevin
