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

H. Peter Anvin
2010-07-14T00:04:05Z

I believe that's how it is actually implemented though, and I believe we'd have failures all over if that was not true.

"Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

>On 07/13/2010 03:14 PM, H. Peter Anvin wrote:
>> Actually, I believe volatile operations (including asm volatile) are
>> strictly ordered *with respect to other volatile operations*.
>
>The documentation makes no reference to that property; in fact it
>suggests it is outright not true:
>
> Note that even a volatile `asm' instruction can be moved relative to
> other
> code, including across jump instructions. For example, on many targets
> there is a system register which can be set to control the rounding
> mode of floating point operations. You might try setting it with a
> volatile `asm', like this PowerPC example:
>
> asm volatile("mtfsf 255,%0" : : "f" (fpenv));
> sum = x + y;
>
> This will not work reliably, as the compiler may move the addition
> back before the volatile `asm'. To make it work you need to add an
> artificial dependency to the `asm' referencing a variable in the
> code you don't want moved, for example:
>
> asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
> sum = x + y;
>
> Similarly, you can't expect a sequence of volatile `asm'
> instructions to remain perfectly consecutive.
> [...]
> An `asm' instruction without any output operands will be treated
> identically to a volatile `asm' instruction.
>
>> As such I
>> would think we'd want to keep the "memory" clobber here, to make it
>> strictly ordered with regards to *all* memory operations.
>>
>
>That would keep its overall effect consistent.
>
> J

--
Sent from my mobile phone. Please pardon any lack of formatting.