linux-kernel - Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45634704.8020407@zytor.com>
Date:	Tue, 21 Nov 2006 10:35:48 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Avi Kivity <avi@...ranet.com>, Arnd Bergmann <arnd@...db.de>,
	kvm-devel@...ts.sourceforge.net, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly

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.

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