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