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

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On 19/01/2012 21:56, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:
>
>> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
>> wrote:
>>
>>>>
>>>> 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.
>>
>> Would like public headers to not be gcc specific. The toolstack is a
>> more
>> specific special case, it contains lots of gcc-isms anyway. Hence its
>> sysctl/domctl hypercalls are allowed more leeway.
>>
>> Frankly, rather than hauling the mem_event toolstack operations out of
>> domctl, you might be better just fixing the coarse-grained locking at
>> least
>> for the particular commands you care about. The big domctl lock is not
>> needed for a quite a few of those domctl operations.
>
> As an alternative, you could declare a tools-only section for
> public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
> to use uint64_aligned_t in those sections.

This sounds like the way to go. Luckily not for general consumption and
not SOL :)

Thanks!
Andres

>
> If your struct is for general consumption by any guest then you're SOL and
> have to do it the hard way.
>
>  -- Keir
>
>>  -- Keir
>>
>>> 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