Re: [Xen-devel] memop struct packing, 32/64 bits

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
> > wrote:
> >
> >> Hi,
> >> I had the following painful experience. I declared
> >>
> >> struct xen_mem_event_op {
> >>     uint8_t       op;           /* XENMEM_*_op_* */
> >>     domid_t       domain;
> >>     uint64_t buffer;
> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> >> };
> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
> >>
> >> to be passed as the argument of a memory op called form the toolstack.
> >> The
> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> >> simply:
> >>
> >>     xen_mem_event_op_t meo;
> >> ... set fields ...
> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> >>
> >> No joy because 32 bits was packing the struct differently than 64 bits.
> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
> >> when
> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
> >> was
> >> thrown between 'domain' and 'buffer'.
> >>
> >> The first question is, what is the preferred way around this. Declare
> >> pads
> >> inside the struct?
> >
> > Yes.
> 
> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
> memory.h

I don't think gcc extensions such as this are allowed in
xen/include/public. You should explicitly pack the struct instead.

Ian.

> 
> Thanks!
> Andres
> 
> >
> >> Exploring the include/public/memory.h declarations and toolstack code, I
> >> see that no current declare includes __attribute__((aligned)) or
> >> __attribute__((packed)), or explicit pads.
> >>
> >> So how come things don't break more often for 32 bit toolstacks? pure
> >> luck? Am I missing something?
> >
> > Where older structs were not 32/64-bit invariant, compat shims were
> > implemented. See common/compat/memory.c, for example. Well worth avoiding
> > that!
> >
> >  -- Keir
> >
> >> Thanks!
> >> Andres
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >
> >
> >
> 
> 



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