Hi,
while coding on virtual page tables came some ideas...
* I throwed away my first implementation ;)
The approach was to translate virtual pages and insert them into
real used monitor page table as soon as they were placed into virtual
page tables. This produces a lower number of page faults while running
guest, but the penalty is that all pages were treated - if they were
used or not, we need more translation time and more memory. Becomes
worse with SBE and a larger number of used page tables. So I followed
the approach described in Kevins virtualization paper: handle translation
and so on not until guest demands them (by causing a page fault).
Setting a page directory means to unmap the dir and all used page tables
from guests address space and writing into virtual CR3. Writes and read
into/from a page dir/table cause page faults, catched by our page fault
handler. By looking at the linear page fault address and the virtual CPL
is the right "pager" (which resolves the fault) detected - all this isn't
new, I just wanted to summarize. Some details I missed, I want to add.
- Write access to a page dir/table: map page dir/table into guests address
space, retry the faulting instruction in single step mode, unmap page
dir/table, done
- Read access: like write, but we have to update A and D bits. We don't
know whether the guest reads or writes, so assume read every time
- Single step is done by setting the T-bit in eflags. T-bit is cleared
automatically. An alternative would be the use of debug registers, but
think that's slower.
- U/S-bit for unmapping from guest is bettern than P-bit, because with
U/S pages are accessible for monitor, with P not.
- Software TLBs can speed up monitor (we have to flush guests address space
with PDBR-changes)
- Of course, all emulation is done in guest context ;) (my first implementation
did some things in host context...)
* Monitor may demand some additional pages for emulation. For example, when a new
page table is needed. This suggests three things:
- An extended communication protokoll between host and guest
- Implement mechanisms for suspend emulation in monitor, do some things on host
side and resume emulation in monitor (nearly done, only a few changes needed)
- A "page pool" or "page cache" with a minimum and maximum number of free pages;
Monitor takes pages from this pool for use or gives back unused pages; if
the pool sank under the minimum, the host has to refill it, if it went up
above the maximim, the host can take the spare pages for itself (or other
virtual machines... ;)
I'll go ahead with page tables, write some docs about host<->guest communication
protocoll, extend this protocoll, implement suspending and resuming emulation in
monitor (I think about callback functions) and implement the page pool. Hope this
conflicts with no changes from you. (Kevin?)
jens
