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

Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Fri, 18 Aug 2006 11:04:50 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Aug 2006 02:18:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1155839719.27466.48.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200608161724.36470.Tristan.Gingold@xxxxxxxx> <1155839719.27466.48.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit :
> (CCed to xen-devel for completeness. ;)
So I stay on xen-devel only!

> On Wed, 2006-08-16 at 17:24 +0200, Tristan Gingold wrote:
[...]
> > 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 affected.
> >
> > 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 postpone.
>
> Right, by switching to the xencomm approach for copy_*_guest(), you lose
> the ability to copy_*_guest() with arbitrary addresses, because
> copy_*_guest() *requires* that the guest kernel has passed in a xencomm
> structure.
>
> x86 has a copy_*_user() implementation, which is used only in x86 code
> and is independent of the copy_*_guest() API. You could create a similar
> parallel API if you need to.
That's my current solution.

> > 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.
>
> I'll be very interested to see your patch. I guess the "flag" is a
> reserved bit in the (physical) address passed from kernel to hypervisor?
Yes.

> Does that really gain much performance?
I don't think performance will be decreased.  But it simplifies hcall.c a lot!
Using xencomm_create (and __get_free_page) is tricky: it doesn't work all the 
time and at least it doesn't work very early duing kernel boot.
Using xencomm_create_mini is possible but rather heavy.

> I guess you will need to do the same thing we need to with privcmd ioctl
> handling, i.e. copy and modify the pointers in the dom0_op data
> structures passed to the kernel. :(
Yes.  hcall.c *has* to be shared between ppc and ia64.

> We need to do one more thing though: we *also* need to change fix up the
> size of longs and pointers in our code (since 32-bit userland is passing
> structures to a 64-bit kernel). So perhaps these two fixup passes could
> be split: we could share the xencomm conversion in common code, and PPC
> arch code could contain the size munging.
Are structure sizes different on 32 and 64 bits ?

> This is why passing complex data structures as hcall parameters will
> always be a bad thing.

Tristan.

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

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