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

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


  • To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Thu, 19 Jan 2012 13:21:05 -0800
  • Cc: Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir \(Xen.org\)" <keir@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 19 Jan 2012 21:21:31 +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=Mf+RkITuFcySL1aXqTBn0lzXkLx1ZihgIITL4O99PAl1 FVPWo4CYavrwiTvU/dyKKH6S5+V8mZrjbcvKyoBeBHHXq6rbZELwJNf8Jicmg6sK Vlw1W6Eyz0weziuHA2sMP9+2GRhoMtyHmz8+hmmwtQO7iDh6xxdVkL8gZ7yRJ30=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
>> > 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
>
> 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@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®.