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: Gianluca Guida <glguida@xxxxxxxxx>
Subject: Re: [Xen-devel] Consult some concepts about shadow paging mechanism
From: Jui-Hao Chiang <windtracekimo@xxxxxxxxx>
Date: Fri, 24 Apr 2009 00:23:23 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 23 Apr 2009 21:23:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fynsqSsYDPXmR+e+UNXxQ2HAChSEockqCPdST5UT9rk=; b=Lpuk93NZHWLvQyzKDP4UbvwJjgBNU2fBrKEwgmE75w6XxYi0GNP1rwSsfZus0zrmzM VKfx/RTE5XHcyIvR5K+5vA1ga/r1Npb6B9ByyOcuT7zcmoFB055GjijmzhTUEf9PUmAc tvvcRc7Gz2sBx9C9d5SUHzWk+WqwkOKI6MVAI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HFxDkXOUJO2HaMQHPhVuyhYK2nWWFm/2XJCz6K6sQOk1Wb0lSJQumYlIfzm92q7Edg NUldqjlFJcJsDj/V7d5ShV9Q8J4M1DvkBSHmZliwTbDjPfMmzN61Ldzg7p0QsaZ7q3ES w+GB6RAG6FWe7IOrwZZ+7lzQUf0PAIBY7X8JQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f8877f640904230846t256a35bfq191a19a4c9e43a4b@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thanks, Gianluca:

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?

(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.

Thanks for your patience,

On Thu, Apr 23, 2009 at 11:46 AM, Gianluca Guida <glguida@xxxxxxxxx> wrote:
> Hi,
> On Wed, Apr 22, 2009 at 3:14 PM, Jui-Hao Chiang <windtracekimo@xxxxxxxxx> 
> wrote:
>> Assume we have the following terms
>> GPT: guest page table
>> SPT: shadow page table
>> (Question a) When guest OS is running, is it always using SPT for
>> address translation?
> Yes, the guest always run directly on shadow pagetables.
>> If it is the case, how does guest OS refer and
>> modify its own GPT content?
> The guest will map its own pagetables (GPT) in the guest page tables
> itself. It will access them trasparently, and the shadow code will
> kick in doing the various magic to keep guest and shadows in sync.
>> It seems that there is a page table entry
>> in SPT for the GPT page.
> Yes, exactly.
>> (Question b) The hypervisor is performing synchronization between GPT
>> and SPT. When guest OS increase access to some page (call it
>> Normal_Page) by marking 'read only' GPT entries as 'read write',
>> what's the read-write mode of the GPT page in the beginning?
>> (1) If it's read-only in SPT, the this modification will trigger a
>> page fault for GPT page, so that hypervisor can synchronize those two
>> tables at this moment.
> Yes, that's exactly what happens in general. GPT pages are always
> mapped read only in shadows. Well, there's an exception at the moment:
> level 1 pagetables (page tables, as opposed to page directories, etc.)
> can be mapped writable, but this is a much longer discussion.
> 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

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