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

RE: [Xen-devel] understanding __linear_l2_table and friends

To: "Gerd Knorr" <kraxel@xxxxxxxxxxx>
Subject: RE: [Xen-devel] understanding __linear_l2_table and friends
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 21 Apr 2005 22:13:33 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, ak@xxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Scott Parish <srparish@xxxxxxxxxx>
Delivery-date: Thu, 21 Apr 2005 21:13:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
Thread-index: AcVGq1oozSM0GUJ0Rim4xFjGYeie9wABx5mA
Thread-topic: [Xen-devel] understanding __linear_l2_table and friends
> > The alternative is to hack PAE Linux to force the L2 
> containing kernel 
> > mappings to be per-pagetable rather than shared. The 
> downside of the 
> > is that we use an extra 4KB per pagetable, and have the hassle of 
> > faulting in kernel L2 mappings on demand (like non-PAE 
> Linux has to). 
> > This plays nicely with the TLB flush filter, and is fine 
> for SMP guests.
> 
> I think that one is better. 

Good. The only hassle is the need for Linux's demand filling of L2 slots
pointing to kernel L1's, but seeing as non-PAE Linux has similar code
already, this shouldn't be too hard.

>  The topmost L2 table with the 
> kernel mappings is a special case anyway because it also has 
> the hypervisor hole and thus differs from the other three L2 
> tables when it comes to allocation and verification (and 
> maybe other places as well).
> I'm considering adding a new page type for the topmost L2 in 
> PAE mode to handle this.  Comments?  Better ideas?

You can just maintain the va back ptr index for L2's as well as L1's (we
may want to do this anyway to implement writeable L2 pagetables at some
point). If the va back ptr == 3, you know its an L2 with hypervisor
slots.

Part of validating an L3 will be to check that the top slot is filled in
and pointing to a validated L2. When alloc_l2_table is called with a
back pointer index of 3 it will install hypervisor entries in the L2.

I think this is much neater.

Best,
Ian

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