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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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