xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* x86: fix rdrand asm()
@ 2013-09-25 15:46 Jan Beulich
  2013-09-25 15:52 ` Andrew Cooper
  2013-09-25 16:06 ` Keir Fraser
  0 siblings, 2 replies; 4+ messages in thread
From: Jan Beulich @ 2013-09-25 15:46 UTC (permalink / raw)
  To: xen-devel; +Cc: Keir Fraser

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

Just learned the hard way that at least for non-volatile asm()s gcc
indeed does what the documentation says: It may move it across jumps
(i.e. ahead of the cpu_has() check). While the documentation claims
that this can also happen for volatile asm()s, if that was the case
we'd have many more problems in our code (and e,g, Linux would too).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/random.h
+++ b/xen/include/asm-x86/random.h
@@ -8,7 +8,7 @@ static inline unsigned int arch_get_rand
     unsigned int val = 0;
 
     if ( cpu_has(&current_cpu_data, X86_FEATURE_RDRAND) )
-        asm ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
+        __asm__ __volatile__ ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
 
     return val;
 }




[-- Attachment #2: x86-rdrand-asm-volatile.patch --]
[-- Type: text/plain, Size: 797 bytes --]

x86: fix rdrand asm()

Just learned the hard way that at least for non-volatile asm()s gcc
indeed does what the documentation says: It may move it across jumps
(i.e. ahead of the cpu_has() check). While the documentation claims
that this can also happen for volatile asm()s, if that was the case
we'd have many more problems in our code (and e,g, Linux would too).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/random.h
+++ b/xen/include/asm-x86/random.h
@@ -8,7 +8,7 @@ static inline unsigned int arch_get_rand
     unsigned int val = 0;
 
     if ( cpu_has(&current_cpu_data, X86_FEATURE_RDRAND) )
-        asm ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
+        __asm__ __volatile__ ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
 
     return val;
 }

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: x86: fix rdrand asm()
  2013-09-25 15:46 x86: fix rdrand asm() Jan Beulich
@ 2013-09-25 15:52 ` Andrew Cooper
  2013-09-25 15:57   ` Jan Beulich
  2013-09-25 16:06 ` Keir Fraser
  1 sibling, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2013-09-25 15:52 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Keir Fraser


[-- Attachment #1.1: Type: text/plain, Size: 1179 bytes --]

On 25/09/13 16:46, Jan Beulich wrote:
> Just learned the hard way that at least for non-volatile asm()s gcc
> indeed does what the documentation says: It may move it across jumps
> (i.e. ahead of the cpu_has() check). While the documentation claims
> that this can also happen for volatile asm()s, if that was the case
> we'd have many more problems in our code (and e,g, Linux would too).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/include/asm-x86/random.h
> +++ b/xen/include/asm-x86/random.h
> @@ -8,7 +8,7 @@ static inline unsigned int arch_get_rand
>      unsigned int val = 0;
>  
>      if ( cpu_has(&current_cpu_data, X86_FEATURE_RDRAND) )
> -        asm ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
> +        __asm__ __volatile__ ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );

Any reason for using the double underscore versions?  They have
identical meanings, and the prevailing style does appear to be without.

Either way,

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>  
>      return val;
>  }
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 2114 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: x86: fix rdrand asm()
  2013-09-25 15:52 ` Andrew Cooper
@ 2013-09-25 15:57   ` Jan Beulich
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2013-09-25 15:57 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel, Keir Fraser

>>> On 25.09.13 at 17:52, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 25/09/13 16:46, Jan Beulich wrote:
>> Just learned the hard way that at least for non-volatile asm()s gcc
>> indeed does what the documentation says: It may move it across jumps
>> (i.e. ahead of the cpu_has() check). While the documentation claims
>> that this can also happen for volatile asm()s, if that was the case
>> we'd have many more problems in our code (and e,g, Linux would too).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/include/asm-x86/random.h
>> +++ b/xen/include/asm-x86/random.h
>> @@ -8,7 +8,7 @@ static inline unsigned int arch_get_rand
>>      unsigned int val = 0;
>>  
>>      if ( cpu_has(&current_cpu_data, X86_FEATURE_RDRAND) )
>> -        asm ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
>> +        __asm__ __volatile__ ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
> 
> Any reason for using the double underscore versions?  They have
> identical meanings, and the prevailing style does appear to be without.

In header I prefer to use the name space safe variant with
the underscores, while in .c files I'd use the ones without. From
a strict POV that ought to be necessary for public headers only
(where we don't have any asm()s anyway), but I'd like to do it
this way as long as we're not really consistent with this
throughout the tree.

Jan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: x86: fix rdrand asm()
  2013-09-25 15:46 x86: fix rdrand asm() Jan Beulich
  2013-09-25 15:52 ` Andrew Cooper
@ 2013-09-25 16:06 ` Keir Fraser
  1 sibling, 0 replies; 4+ messages in thread
From: Keir Fraser @ 2013-09-25 16:06 UTC (permalink / raw)
  To: Jan Beulich, xen-devel

On 25/09/2013 16:46, "Jan Beulich" <JBeulich@suse.com> wrote:

> Just learned the hard way that at least for non-volatile asm()s gcc
> indeed does what the documentation says: It may move it across jumps
> (i.e. ahead of the cpu_has() check). While the documentation claims
> that this can also happen for volatile asm()s, if that was the case
> we'd have many more problems in our code (and e,g, Linux would too).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/asm-x86/random.h
> +++ b/xen/include/asm-x86/random.h
> @@ -8,7 +8,7 @@ static inline unsigned int arch_get_rand
>      unsigned int val = 0;
>  
>      if ( cpu_has(&current_cpu_data, X86_FEATURE_RDRAND) )
> -        asm ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );
> +        __asm__ __volatile__ ( ".byte 0x0f,0xc7,0xf0" : "+a" (val) );

Although not consistently applied, we use 'asm volatile' rather than
'__asm__ __volatile__' generally. So we should here. Apart from that
Acked-by: Keir Fraser <keir@xen.org>

>      return val;
>  }
> 
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-09-25 16:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-25 15:46 x86: fix rdrand asm() Jan Beulich
2013-09-25 15:52 ` Andrew Cooper
2013-09-25 15:57   ` Jan Beulich
2013-09-25 16:06 ` Keir Fraser

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).