|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] memop struct packing, 32/64 bits
On 19/01/2012 20:49, "Konrad Rzeszutek Wilk" <konrad@xxxxxxxxxx> wrote:
> 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__);
Not used in any public header files.
>> 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.
Not in any public header files. It's used in the auto-generated 32-on-64
compat headers, for the hypervisor's private use.
>> 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.
Mainly you just have to be careful.
-- 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |