Re: [Xen-devel] Essay on an important Xen decision (long)

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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