[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Consult some concepts about shadow paging mechanism
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |