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

RE: [Xen-ia64-devel] Xen is now runnnig at Bull

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Xen is now runnnig at Bull
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 9 Sep 2005 10:21:28 +0800
Delivery-date: Fri, 09 Sep 2005 02:20:55 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcW0TxW1lI+0HOsqQ8iQ849KpXKpQwADL7agAAyEflAAFI5KwA==
Thread-topic: [Xen-ia64-devel] Xen is now runnnig at Bull
Dan:
        See my comments :-)

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Actually, it is conceivable that a single processor
> machine would want to support more than 64 VMs so
> it is very likely that a 48 processor machine would.
> The limit of 64 is on the number of domains that
> might be active, not necessarily simultaneously active.
> 
> I don't think rid virtualization helps here as there
> are only 2**24 rids available and every domain will
> use as many as it is given.  And there's no way to garbage
> collect rids from a domain. So -- I think -- the only ways
> to support more than 64 domains are:
> 1) Give each domain fewer than 2**18 rids, or
> 2) Flush the TLB whenever "necessary" when switching domains
The Intanium architecture guarantee that the guest will have at least
 18 bits of rid. Given less than 18 bits of rid will violate the sepc
and 
guest behavior especially for non modified guest that Bull is trying.
I am not sure how you can flushing TLB without big impact to
performance,
and how do you  determine condition of "necessary" here?

> 
> The frequency of "necessary" could be reduced by using
> a processor affinity hierarchy of some kind.  I suppose
> this is a form of rid virtualization, but is more like
> an extension (e.g. like PAE).
> 
> Dan
> 
RID virtualization targets to solve 2 problems:
1: VHPT locality issue. 
       Matt's mangling algorithm may can problem for single VM case if
all itanium 
processor use same has algorithm, but still has problem in multiple VM
situation.
 (The high bits of different VM doesn't participate the hash algorithm)
2: guest get full 24 bits of rid.

The way to garbage rid is not very complicate. :-(

When the guest rid is not used anymore, the physical rid should be
garbaged.
A simple way to determine when the guest rid is not used can be done by
looking
 at the VHPT table and machine TLB side. 
(Yes, a reference needs to be introduced for each guest rid to track the
entries
 in VHPT, and a special indicator in guest tlb to indicating if there is
entry in physical
TLB)


Is it time for me to share what we thought of for rid virtualization in
much details?

Eddie


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