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] Essay on an important Xen decision (long)

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Essay on an important Xen decision (long)
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 17 Jan 2006 03:16:49 +0000
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 Jan 2006 03:24:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD590341B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <516F50407E01324991DD6D07B0531AD590341B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> > I know I've followed some of these discussions before, just a
> > bit rusty now ;-)
>
> Exactly... except for one nice shortcut that Matt Chapman
> added.  Since the VHPT is architected and the guest is
> expecting that it may be walked, when Xen intercepts the
> initial TLB miss, it can first look in the guest VHPT
> to resolve the miss (and add it to Xen's VHPT and fill
> the TLB) rather than reflect the TLB miss to the guest.
> Only if the translation isn't found in the guest VHPT
> (or if looking for it -- a user_access -- causes another
> TLB miss), then the TLB miss is reflected to the guest.
>
> Thus, guests have the benefit not only of the hardware TLB
> and Xen's VHPT but also their own VHPT.

I wondered if that'd be useful to do.  I guess Linux would naturally try to 
fill the VHPT eagerly as a performance optimisation, so this should work 
quite nicely - you'd only get the extra cost of reflecting the fault at times 
when even native Linux would have missed the VHPT.  Sweet!

And the real VHPT is per (logical) CPU?  I guess walking the guest VHPT 
additionally gives you (effectively) a VHPT per virtual processor, but the 
cost coming out of domain memory.  The fast-path VHPT in Xen doesn't need to 
have such a high hit-rate as a result, I assume.

Had you evaluated the costs of having the guest explictly update Xen's VHPT? 
(or at least hint that an update was necessary for some reason).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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