Le Lundi 21 Août 2006 18:24, Hollis Blanchard a écrit :
> 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.
Kernel-created structures are linear in guest physical space, so it doesn't
matter if they cross page boundaries.
> > > > > 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 .
Xen-ppc-devel mailing list