Re: [Xen-devel] Consult some concepts about shadow paging mechanism

[Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>]

On Fri, Apr 24, 2009 at 6:23 AM, Jui-Hao Chiang <windtracekimo@xxxxxxxxx> wrote:
> I have some additional doubts as the following:
> (1) For normal data page, in order to propagate the Dirty or Access
> bit from SPTE to GPTE, the hypervisor needs to set Read-Only in the
> SPTE. When the write page fault of this data page comes, hypervisor
> can propagate the Dirty or Access bit to GPTE and set it to R/W. My
> question is when does the hypervisor make it Read-Only again? Is there
> any place inside the source code you can point out?

What happens is this: the guest has to clear the dirty/accessed bit
and then flush the tlb (or invlpg the entry).
If the pagetable is mapped read only (as in levels > 1) the write to
the pagetable will trigger the emulator that will update the entry.
Otherwhise (if the page is out of sync, which means a writable guest
pagetable, and this happens when it's an L1) the flushtlb will do the
job of updating the shadow entry.

Look at how sh_propagate function works and when it get called. It's
what you're looking for.

> (2) How many shadow pages are maintained for each guest domain? If the
> hypervisor keep only one shadow page table for the active process in
> each guest domain, then during the guest context-switch, it might
> erase the entire shadow page table, and re-construct it for the new
> process, which seems a lot of overhead. I have checked the
> sh_update_cr3(), but not sure of the detailed mechanism.

There's a pool of shadow memory that get reused in a pseudo-LRU
manner. Across cr3 switch toplevel pagetables are kept in memory, and
unshadowed when evicted by the allocator or when other things happens,
mostly based on heuristic and reference counting.

Thanks,
Gianluca

-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel