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/
Home Products Support Community News


[Xen-ia64-devel] Xencomm for xen/ia64

To: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: [Xen-ia64-devel] Xencomm for xen/ia64
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Wed, 16 Aug 2006 17:24:36 +0200
Cc: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 16 Aug 2006 08:20:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
User-agent: KMail/1.5

[xen-ppc-devel is on CC just for info]

I am porting xen-ppc's xencomm to xen/ia64.
Currently on xen/ia64 copy_from/to_guest uses guest virtual address.  This 
works well as long as the virtual addresses are in the TLB.  When not in TLB 
(or vTLB) the hypercall can't success without domain help.  The possible 
solution is either to touch the memory areas before doing the hypercall 
and/or restarting the hypercall.

Touching the memory area is an hack and we can't be sure it works.
Restarting the hypercall is not always possible (some hypercalls are atomic: 
DOM0_SHADOW_CONTROL_OP_CLEAN) or can result in a live-lock.

The most simple solution is to use guest physical addresses instead of virtual 

For hypercalls directly issued by the kernel, the translation is very easy.  
For hypercalls (indirectly) issued by dom0 though the ioctl, kernel has to do 
the translation.  Because it may not be linear in guest physical memory the 
parameter is a pointer to a list of page (xencomm).

The pros of such approach is simplicity and reliability.

The main cons is maybe speed.  Hopefully the most frequent hypercalls (dom0vp 
and eoi) either don't use in memory parameters (dom0vp) or may be modified so 
that they pass parameters through registers (eoi).  IMHO speed won't be 

Access to guest memory is also performed during vcpu_translate (to read vhpt) 
or EFI/PAL/SAL calls.  We can either do not change that code (ie both 
mechanisms are not exclusive) or change the code.  This point will be 

Comments are welcome (I won't work tomorrow, so you have more time).

If we agree on using xencomm we will have to work with xen/ppc people in order 
not to duplicate the code.  Hopefully it is rather small.  I have enhanced 
the xencomm code so that the kernel may not use xencomm area but pass the 
guest physical address with a flag to know the space is linear in memory.

At this time I can boot dom0 with xencomm.  I will publish the patch later.


Xen-ia64-devel mailing list

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