From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: memop struct packing, 32/64 bits Date: Thu, 19 Jan 2012 13:21:05 -0800 Message-ID: References: <3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org> <1327007491.21391.15.camel@dagon.hellion.org.uk> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1327007491.21391.15.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Ian Jackson List-Id: xen-devel@lists.xenproject.org > On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote: >> > On 19/01/2012 20:30, "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. >> >> 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. Ok, I'll back off on 'packed'. It makes me uneasy though not being able to control the layout exactly. Thanks, Andres > > 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@lists.xensource.com >> >> http://lists.xensource.com/xen-devel >> > >> > >> > >> >> > > >