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

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Thu, Jan 19, 2012 at 12:30:21PM -0800, Andres Lagar-Cavilla 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. And also use __attribute(__packed__); 
> 
> 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.

Sometimes they have #pragma(4), which will make the alignment be
32-bit (4-bytes) for 64-bit builds as well.
> 
> So how come things don't break more often for 32 bit toolstacks? pure
> luck? Am I missing something?

If you do not use 'memcpy' you can escape some of these misues.

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