[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Essay on an important Xen decision (long)
> > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |