[lkml]   [2006]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>> Avi Kivity wrote:
>>>> Or gcc
>>>> might move the assignment of phys_addr to after the inline assembly.
>>> "asm volatile" prevents that (and I'm not 100% sure it's necessary).
>> No, it won't necessarily. "asm volatile" simply forces gcc to emit the
>> assembler, even if it thinks its output doesn't get used. It makes no
>> ordering guarantees with respect to other code (or even other "asm
>> volatiles"). The "memory" clobbers should fix the ordering of the asms
>> though.
> I think you're wrong about that; in particular, I'm pretty sure "asm
> volatiles" are ordered among themselves. What the "volatile" means is
> "this has side effects you (the compiler) don't understand", and gcc
> can't assume that it can reorder such side effects.

The gcc manual has this to say:

Similarly, you can't expect a sequence of volatile `asm' instructions
to remain perfectly consecutive. If you want consecutive output, use a
single `asm'. Also, GCC will perform some optimizations across a
volatile `asm' instruction; GCC does not "forget everything" when it
encounters a volatile `asm' instruction the way some other compilers do.

I wonder how we are supposed to code the following sequence:

asm volatile ("blah") /* sets funky processor mode */


asm volatile ("unblah");

Let's say "blah" disables floating point exceptions, and some_c_code()
must run without exceptions. Is is possible to code this in gcc without
putting functions in another translation unit? Is a memory clobber
sufficient? I'd certainly hate to use it.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-21 20:45    [W:0.063 / U:8.620 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site