| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64
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?
> 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.
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.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home