From: Zachary Amsden <zach@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>,
lguest@ozlabs.org, kvm-devel@lists.sourceforge.net,
mingo@elte.hu, ak@suse.de, linux-kernel@vger.kernel.org,
anthony@codemonkey.ws, tglx@linutronix.de,
Glauber de Oliveira Costa <gcosta@redhat.com>,
virtualization@lists.linux-foundation.org,
akpm@linux-foundation.org
Subject: Re: [Lguest] [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt
Date: Thu, 01 Nov 2007 09:55:13 -0700 [thread overview]
Message-ID: <1193936113.29447.56.camel@bodhitayantram.eng.vmware.com> (raw)
In-Reply-To: <472A0FBF.6040907@goop.org>
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-ordering across
another volatile load, store, or asm was permitted. And of course, as
long as input and output constraints are written properly, the
re-ordering should not be vulnerable to pathological movement causing
the code to malfunction.
It seems that CPU state side effects which can't be expressed in C need
special care - FPU is certainly one example.
Also, memory clobber on a volatile asm should stop invalid movement
across TLB flushes and other problems areas. Even memory fences should
have memory clobber in order to stop movement of loads and stores across
the fence by the compiler.
Zach
next prev parent reply other threads:[~2007-11-02 1:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 19:14 [PATCH 0/7] (Re-)introducing pvops for x86_64 - Real pvops work part Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 1/16] Wipe out traditional opt from x86_64 Makefile Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 2/16] paravirt hooks at entry functions Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 4/16] provide native irq initialization function Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 5/16] report ring kernel is running without paravirt Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 6/16] export math_state_restore Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 7/16] native versions for set pagetables Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 8/16] add native functions for descriptors handling Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 9/16] This patch add provisions for time related functions so they Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 10/16] export cpu_gdt_descr Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 11/16] turn priviled operation into a macro in head_64.S Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 12/16] tweak io_64.h for paravirt Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 13/16] native versions for page table entries values Glauber de Oliveira Costa
2007-10-31 19:14 ` [PATCH 14/16] prepare x86_64 architecture initialization for paravirt Glauber de Oliveira Costa
2007-10-31 19:15 ` [PATCH 15/16] consolidation of paravirt for 32 and 64 bits Glauber de Oliveira Costa
2007-10-31 19:15 ` [PATCH 16/16] make vsmp a paravirt client Glauber de Oliveira Costa
2007-11-01 4:38 ` Jeremy Fitzhardinge
2007-11-01 4:50 ` [PATCH 11/16] turn priviled operation into a macro in head_64.S Jeremy Fitzhardinge
2007-11-01 13:50 ` Glauber de Oliveira Costa
2007-11-01 4:48 ` [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt Jeremy Fitzhardinge
2007-11-01 13:48 ` Glauber de Oliveira Costa
2007-11-01 15:30 ` Jeremy Fitzhardinge
2007-11-01 16:07 ` Keir Fraser
2007-11-01 16:13 ` Glauber de Oliveira Costa
2007-11-01 17:41 ` Jeremy Fitzhardinge
2007-11-01 16:55 ` Zachary Amsden [this message]
2007-11-02 1:21 ` [Lguest] " Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1193936113.29447.56.camel@bodhitayantram.eng.vmware.com \
--to=zach@vmware.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anthony@codemonkey.ws \
--cc=gcosta@redhat.com \
--cc=jeremy@goop.org \
--cc=kvm-devel@lists.sourceforge.net \
--cc=lguest@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome