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

Le Vendredi 18 Août 2006 18:39, Hollis Blanchard a écrit :
> On Fri, 2006-08-18 at 11:04 +0200, Tristan Gingold wrote:
> > Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit :
> > > > 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!
>
> I'm not sure how it simplifies hcall.c. You always need to create
> xencomm descriptors, unless you're manually guaranteeing that the
> dom0_op structures do not cross page boundaries (in which case they are
> not "linear in memory"). Is that what you're doing?
For hypercalls issued through privcmd, xencomm descriptors are always created.
For hypercalls directly issued by kernel inline xencomm is prefered.

> > 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.
>
> "Heavy" meaning what? It adds almost no CPU overhead (just checking for
> crossing page boundaries), and the stack space used is 64 bytes.
It is cumbersome: you have to declare the stack space, to do the call and to 
check the result.  Using inline xencomm is just a call.

> The only reason it's not the preferred API is that a) it's a little
> cumbersome to use (in that the caller must manually allocate stack
> space), and b) it handles only up to two pages worth of data.
>
> > > 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 ?
>
> Yes, in particular longs and pointers.
But are longs and pointers used directly in Xen hypercalls ?  I though only 
sized types (uintNN_t & others) are used.

Tristan.

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

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