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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
>Sent: 2006年1月17日 11:17
>
>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.

You capture the point there. ;-) Currently there're two solutions co-existing 
in current xen-ia64: per-LP(logical processor) VHPT/simplified vTLB and per-VP 
VHPT(virtual processor)/hash vTLB. The former is used by dom0/domU while the 
latter for domVTI. vTLB is the pool to track guest TLB related insertion/purge 
operation, and thus behave like shadow to machine TLB. Simplified vTLB means 
minimal architecture requirements with 8 DTR/ITR and 1 DTC/ITC and thus with 
less hit rate. Hash vTLB is a hash distributed table with collision support 
with more memory required but higher hit rate. Currently it's more urgent to 
merge two solutions to be general, instead of the strategy. To be per-VP or 
per-LP is discussed many times before, which is actually not that obvious 
without a general solution and benchmark data provided. We'll have a discussion 
on this topic in tomorrow's summit.

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

To let guest explicitly update Xen's VHPT has several obvious limitations:
        - VHPT on IA64 has two format: short and long. To support different OS, 
Xen has to construct a VHPT table with long format to support both from guest. 
Currently linux is using short format VHPT, so it means a lot modification to 
xenlinux operating xen's long format VHPT directly.
        - It also conflict with current region id virtualization policy. On 
xen/ia64, region id describes one address space which is virtualized with fewer 
bits to xenlinux than ones machine actually supported. If xenlinux directly 
executes hash algorithm on virtualized region id, it's actually meaningless.

Thanks,
Kevin

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