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: Xen/ia64 - global or per VP VHPT

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Yang, Fred" <fred.yang@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Sun, 1 May 2005 12:35:01 -0700
Cc: ipf-xen <ipf-xen@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 May 2005 19:34:40 +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: AcVKfesR741jQGkzQvWmdNAbNvskDgAAPPdQAAnH97AAJJJm8AAGJlmgACr730AABzFgcAAYTImwABTis7AAALccgAAAPutgABLQl4AAN60BYAARFB9AABDYKGA=
Thread-topic: Xen/ia64 - global or per VP VHPT
> > I don't think this applies to "global VHPT vs per-domain VHPT"
> > as this should be completely invisible to guestOS.  And I
> > think it should be possible (fairly easy) to support both:
> > per-domain for VT domains and global for non-VT.
>
> How can you guarantee the MAP for hypercall will not be 
> purged without extra data structure I mean vTLB?  

I haven't seen your hypercall implementation yet, but I was
assuming that (on non-VT) the parameters would be passed in
memory in the "shared page" which is always mapped by a TR.

> Actually vMMU is not only VHPT issues. Another important 
> thing is vTLB. The current implementation doesn't include any 
> vTLB code. If we decide to develop hypercalls base on my vMMU 
> implementation, the extra effort is quit small (just several 
> hours to enable), but I am afraid it is quit difficult to 
> support on current global VHPT implementation.

Actually the current implementation does include a vTLB
implementation, but it is one entry vITLB and one entry
vDTLB, used so far only to ensure forward progress on
privop emulation.

This is insufficient if your hypercall proposal passes parameters
by address where the address can be anywhere in guest memory,
but I didn't think that was your proposal.
 
>       This is not a big cake. If the domain get more 
> memories(exceed some threshold), it is ok to increase VHPT 
> size dynamically.

If the per-domain VHPT must be contiguous in physical memory,
this IS a big cake.

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

<Prev in Thread] Current Thread [Next in Thread>