>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).
Yes, completely right. I tryed to make it as simple as
possible (after I had some strange and complex ideas...)
>I don't get your point here. (a) what's the difference between
>"unmapping" and "setting P=0" ??
With "unmapping" I mean to remove from page table, "setting P=0"
is what it says...
>(b) what does sharing
>memory between guest and host have to do with it ? They run
>off a different set of pagetables.
Ups, you are right. Sorry for confusion...
>> Caution with paging: if one page is swapped out, the guest may
>> try to enter the address of this page on hard disk in page
>> table, so we do no page translation!
>Uh, you should only activate pages with P=1. I don't see
>what the problem is ?
No problem, only caution. As you said and as I pointed out,
we recognize on the P-bit whether guest trys to enter a page frame
or a place on disk into page table. In first case we have to translate,
in second not. I just wanted to remember this fact.
>Once again, I don't see the problem. You've got the *virtual*
>page table, which is *not* the same as the real page table
>(they reside at different physical addresses altogether !)
>This means you also have a *virtual* P-bit, and a *real* P-bit.
>There is no possible way to confuse these.
Yes, yes, yes, you're right ;)
jens
