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-ppc-devel mailing list Xenemail@example.com http://lists.xensource.com/xen-ppc-devel