WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Regarding page table management changes from Xen v1 to Xen v

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Regarding page table management changes from Xen v1 to Xen v2 (and v3)
From: Himanshu Raj <rhim@xxxxxxxxxxxxx>
Date: Wed, 26 Apr 2006 11:35:56 -0400
Delivery-date: Wed, 26 Apr 2006 08:36:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
Hi Folks,

While going through the 2004 OLS presentation on Xen, I noticed that the way PT
management happens changed from v1.2 to v2.0. More particularly in v1.2, guest
would make a hypercall for all the writes to the PT, whilst in v2.0 (and in 
v3.0)
, guest tries
to write the PT directly, even knowing that it is mapped RO and would cause a 
fault. Xen then detaches that particular page and maps it RW in guest. Another
access will cause another page fault and which time it will be
validated and re-attached to higher level PT structure.

I am trying to understand the rationale behind this change. In previous case, 
there would be no page faults due to page table updates and only one hypercall.
In the second case, there would be atleast 2 page faults due to PT management
activity, but no hypercalls. Besides, mapping and remapping with different 
permissions
imply removing this entry from TLB (which is hopefully being done with invlpg).
Benefit of latter approach only seems to be the removal of xen specific linux 
code. Why was the approach changed? Could someone please shed some light on 
this?

Thanks and best regards,
Himanshu

-- 
-------------------------------------------------------------------------
Himanshu Raj
PhD Student, GaTech (www.cc.gatech.edu/~rhim)
I prefer to receive attachments in an open, non-proprietary format.
-------------------------------------------------------------------------

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