Ramon van Handel <[EMAIL PROTECTED]> wrote:
> I must say I find your picture quite complicated ;),
> but this actual action seems to me to be pretty
> trivial: the prerequisite is that you catch all
> modifications to the active pagetables; once you
> do that, you simply employ a one-to-one mapping between
> virtualised physical pages and the host's relevant
> part of the pagetable (you have to synchronise with
> the host page table, in stead of with directly assigned
> physical pages, because otherwise you cannot allow
> linux to swap out the guest memory, which is something
> we'd like to implement as well. This also means that
> a page-table modification requires a switch back to
> the host).
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.
What you can do to reduce memory requirements is to release
pages to the host OS from time to time (if they are infrequently
accessed by the guest); this amounts to implementing some
kind of swapping algorithm ourselves. While this is suboptimal
(especially as we probably can't get good information as to just
when the host OS *needs* memory), I don't see another way ...
(We might use swappable user space memory instead of kernel memory,
and simply lock/unlock pages there; this way, the whole mechanics
of actually writing the page to the swap file and reading it again
would be done by the OS as usual. But I don't see how we can leave
the pages unlocked and leave the *decision* when to swap to the host.)
Bye,
Ulrich
