[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:23:50 -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:24:16 +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=BL2mBKEYmKcJKK69hw/rRonR+/ARDiPtLNRqhn6m/gv6 CjqHr9/s3tnjoIMJykJKPTrHWx9hdU/BW1632qP1WZENN8v0+7uBg1juplvPUsw6 XW1P0O3ma5YS9l8XJ7I1GXJxc5Gqc72Nks/MeIYuCls8yEILciMUZ7/+yupuqHM=
  • 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.

domctl.h is in a way spared, because __attribute__((aligned(8))) is
allowed in 32 bits. And the header is spared the ansi test.

Is there a rationale to allowing this ABI file do 'aligned', but
preventing that other header file from using it?

I'm thinking uint64_aligned_t would solve my problem in memory.h.

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®.