This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jui-Hao Chiang <windtracekimo@xxxxxxxxx>
Subject: Re: [Xen-devel] Consult some concepts about shadow paging mechanism
From: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
Date: Fri, 24 Apr 2009 15:32:09 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 24 Apr 2009 06:32:35 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=8Wfm8fVfOwwbfgXfs1I7Bh0hogrgHOnLNO8r0vkDfXE=; b=onu7kDA9x9m579/i4H0tqmK0XqO5WPNr/CvfCZ8qujIol+DvBvH5YACFZf87mYGnw6 GN7Zayor/TIq7M5sZEKx/eNnye50WZdIHl9G8AZbE6FQZDqNOOIcaaybzGnCh5M71rMB QglsRx5Lm/ZudUPHm0hL4m+Bw1BV21S4TLJFo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TwIp8Blq9o5NeQgswD1wo76MFT/PyMq8ppJvou/OeQ/IiKdHvadZuWwJO2deV2Soad bjyObXb841bZLRJ1SSZisk2c5k3+adbktWnVY8AdA1TkbIjx/9pqko/sPXWF5jsoXf7T ZGIWyRbr4TS7StVbyWmv+Qisw3wB3q/lLqYUs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <52cf60ee0904232123n6e38711fjbd8fe084c464b059@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <52cf60ee0904220614m343aa6c2v13c244fc878825f7@xxxxxxxxxxxxxx> <f8877f640904230846t256a35bfq191a19a4c9e43a4b@xxxxxxxxxxxxxx> <52cf60ee0904232123n6e38711fjbd8fe084c464b059@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


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

<Prev in Thread] Current Thread [Next in Thread>