| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-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
|
|
|
| |
|
Home