xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir (Xen.org)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: memop struct packing, 32/64 bits
Date: Thu, 19 Jan 2012 14:05:07 -0800	[thread overview]
Message-ID: <01f5cfca681d747e5a27a345df6a8e60.squirrel@webmail.lagarcavilla.org> (raw)
In-Reply-To: <CB3E42E4.29270%keir.xen@gmail.com>

> On 19/01/2012 21:56, "Keir Fraser" <keir.xen@gmail.com> wrote:
>
>> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> 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@lists.xensource.com
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

  parent reply	other threads:[~2012-01-19 22:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-19 20:30 memop struct packing, 32/64 bits Andres Lagar-Cavilla
2012-01-19 20:49 ` Keir Fraser
2012-01-19 20:57   ` Andres Lagar-Cavilla
2012-01-19 21:11     ` Ian Campbell
2012-01-19 21:21       ` Andres Lagar-Cavilla
2012-01-19 21:23       ` Andres Lagar-Cavilla
2012-01-19 21:56         ` Keir Fraser
2012-01-19 22:00           ` Keir Fraser
2012-01-19 22:04             ` Keir Fraser
2012-01-19 22:05             ` Andres Lagar-Cavilla [this message]
2012-01-22 20:37   ` Konrad Rzeszutek Wilk
2012-01-22 20:43     ` Keir Fraser
2012-01-23  9:24     ` Jan Beulich
2012-01-23 15:02       ` Konrad Rzeszutek Wilk
2012-01-19 20:49 ` Konrad Rzeszutek Wilk
2012-01-19 21:07   ` Keir Fraser
2012-01-19 21:12     ` Ian Campbell
2012-01-19 21:56       ` Keir Fraser
2012-01-20 10:12         ` Jan Beulich
2012-01-20 10:32           ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01f5cfca681d747e5a27a345df6a8e60.squirrel@webmail.lagarcavilla.org \
    --to=andres@lagarcavilla.org \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir.xen@gmail.com \
    --cc=keir@xen.org \
    --cc=konrad@darnok.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).