Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock

[Jeremy Fitzhardinge]

On 07/14/2010 12:40 PM, H.J. Lu wrote:
> On Wed, Jul 14, 2010 at 12:36 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>   
>> On 07/14/2010 12:32 PM, H.J. Lu wrote:
>>     
>>> On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>>       
>>>> On 07/14/2010 11:18 AM, H.J. Lu wrote:
>>>>         
>>>>> There are some discussions on:
>>>>>
>>>>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html
>>>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html
>>>>>
>>>>> Are they related?
>>>>>
>>>>>           
>>>> Not directly as far as I can tell.
>>>>
>>>> The issue is if gcc can ever reorder, duplicate or elide a volatile
>>>> operation (either asm volatile or a volatile-annotated memory
>>>> reference.)  In my (and Linus') opinion, this would be an incredibly
>>>> serious bug.
>>>>         
>>> Is there a gcc bug for this?
>>>
>>>       
>> Are you asking for a bug report against the documentation?  We're not
>> sure what the semantics intended by the gcc team to be, which I guess is
>> a documentation bug.
>>
>>     
> Documentation bug is also a bug :-).
>   

The question is "what are the real ordering semantics of asm volatile"? 
What ordering is enforced between other asm volatiles?  What ordering is
enforced between asm volatiles and regular memory accesses? asm volatile
and other code?

The documentation discusses this to some extent, but mostly says "there
are no ordering guarantees".  Older versions of gcc - 2.95, for example
- are more explicit, saying that "asm volatiles" won't be moved out of
their basic block (I think that's how I parse it, anyway).

Linux relies on "asm volatile" being ordered at least with respect to
other asm volatiles.  Is this reasonable now?  Will gcc break this at
some point in the future?  If we can't rely on "asm volatile" ordering
semantics, what other mechanism can we use (for example, to order clts
with respect to FPU-using code)?

Thanks,
    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/