[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <keir@xxxxxxx>, "Konrad Rzeszutek Wilk" <konrad@xxxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Thu, 19 Jan 2012 12:57:11 -0800
  • Cc: ian.jackson@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, ian.campbell@xxxxxxxxxx
  • Delivery-date: Thu, 19 Jan 2012 20:57:38 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=sESaZaQmPjkML3FLzwFBC201qKe3ZeG0uFhWNJyDY66u EDvz8Var66c9zm60KtWRDa8BHr0fBmI964NSvuM7q6sJT+r0eSgh0uXp7BoHyFDM uukGoegVe5n8uJlbc1LxnBnI1L0Fg6xoMI59yhTRUD9ENDSrf2iWmo9rld71yA8=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> 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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.