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

[Xen-ia64-devel] RE: Implementing both (was: Xen/ia64 - global or per VP

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: [Xen-ia64-devel] RE: Implementing both (was: Xen/ia64 - global or per VP VHPT)
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 4 May 2005 22:26:00 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 04 May 2005 14:25:36 +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: AcVPb3JXMihcD89IQYupUNJEM3YWVAAEihcQAAFcjdAABKuvsAAVXHAgAAAcwiAAMEVo4A==
Thread-topic: Implementing both (was: Xen/ia64 - global or per VP VHPT)
Hi, dan:
> Hi Eddie --
> 
> Could you explain again what the foreignmap is?
> Is it mappings for other domains (e.g. for domainA
> to access memory in domainB)?  Or is it for
> the hypervisor to access domainA space?  Or
> something else?
It is mapping for domain 0 (device model application) to access other
domain's physical memory. Like a non modified domain N issue a IDE DMA
read/write command, the service domain can directly read or write data
to the point provided by domain N to avoid data copy with foreignmap. 
In this way, the map will be huge like 64GB to cover domain N, and one
map for each domain (except service domain). My current implementation
is to introduce another attribute to vTLB that means vTLB has TR, TC and
FM (FM covers foreignmap and shared page). When collision chain memory
is exhausted, all vTC will be cycled, but vTR and FM will remain there.
Thus I can guarantee the hyper call shared page will never to purged
that you are using TR temply now. It is same for foreignmap.
Another important thing is that the entry in VHPT may be different with
that in vTLB due to machine discontiguous situation. Suppose a guest has
a 256MB huge tlb map that uses one vTC, but in VHPT it may be unable to
find a machine contiguous space for that, so HV needs to convert this
single map into bunch of VHPT entries like 256M/16K=16K entries. I guess
you will headache without full tracking of guest vTLB. If you prefer to
always use 16KB or 4KB page size for VHPT entries, the problem is
disappeared but I am afraid it will consume so much VHPT entries and
thus impact other entries performance.
> 
> Since the current implementation doesn't have
> this, I just want to ensure I understand it.
> (And it would probably be useful for others
> on the mailing list too!)
> 
> Thanks,
> Dan 
> 

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