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] page fault handling in Xen

To: jeet <jeet_sat12@xxxxxxxxxxx>
Subject: Re: [Xen-devel] page fault handling in Xen
From: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Date: Fri, 2 Mar 2007 09:36:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Mar 2007 01:39:04 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <874451.84009.qm@xxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <874451.84009.qm@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
At 14:39 +0530 on 02 Mar (1172846389), jeet wrote:
> As per my understanding when guest can update it own page table without 
> causing VM exit in xen

No -- once a page is recognised as a page table by Xen, the guest is no
longer allowed to write directly to it.  We trap and emulate any
instructions that write to known page tables, so that we can keep the
shadow page tables up to date.

> when some process requires some memory (pages) this will cause page fault and 
> control goes to guest OS
> the guest then allocate page from its own psuedo address space and make 
> entries in guest page table which contain
> mapping of virtual to psuedo physical memory and
> But when actual write occurs to that page, page fault occurs which will cause 
> vm exit in xen.
> Xen then will update the page mfn in shadow page table and return control 
> back to guest by vn entry.
> Is this understanding it correct? so there would be only one vn exit/entry?

There are at least two VMEXITs needed.  Typically the first is for
the original page fault, which is reflected back to the guest.  The
second is caused by the guest's fault-handler writing to guest
pagetables; Xen intercepts that write and updates the shadow pagetables
to match.



Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

Xen-devel mailing list