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

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Mon, 2006-08-21 at 08:46 +0200, Tristan Gingold wrote:
> 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 :
> >
> > 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.

How do you guarantee that kernel-created data structures are not
crossing page boundaries? The patch you sent does not do this. Without
that, xencomm_inline() simply cannot work except by luck.

> > > > 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.

I have put a lot of work into converting types to be explicitly sized,
but there are still missing pieces. I think Jimi got tired of it, and
started doing the Linux "compat32" conversion. For example, see
drivers/xen/privcmd/compat_privcmd.c .

-- 
Hollis Blanchard
IBM Linux Technology Center


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