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

[Keir Fraser <keir.xen@xxxxxxxxx>]

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.

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