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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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