From: Glauber de Oliveira Costa <gcosta@redhat.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
lguest@ozlabs.org, kvm-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, ak@suse.de, chrisw@sous-sol.org,
tglx@linutronix.de, anthony@codemonkey.ws,
akpm@linux-foundation.org,
virtualization@lists.linux-foundation.org, mingo@elte.hu
Subject: Re: [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt
Date: Thu, 01 Nov 2007 14:13:55 -0200 [thread overview]
Message-ID: <4729FB43.1010904@redhat.com> (raw)
In-Reply-To: <C34FAA4C.17CA9%Keir.Fraser@cl.cam.ac.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Keir Fraser escreveu:
> On 1/11/07 15:30, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
>
>> Glauber de Oliveira Costa wrote:
>>> I in fact have seen bugs with mixed reads and writes to the same cr,
>>> (cr4), but adding the volatile
>>> flag to the read function seemed to fix it.
>> Well, volatile will make a read be repeated rather than caching the
>> previous value, but it has no effect on ordering.
>
> volatile prevents the asm from being 'moved significantly', according to the
> gcc manual. I take that to mean that reordering is not allowed.
>
According to a gcc developer to whom I asked this question, volatile
prevents the code
to be removed, but does not prevent it to be moved (pun indented). In
practice, it should force
a re-read, but not influence the ordering decisions from the compiler.
Besides , 'significantly'
sounds like a significantly unprecise word, whose specific meaning may
be implementation dependant.
So I agree that adding a memory location reference is probably the best
alternative.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org
iD8DBQFHKftDjYI8LaFUWXMRAiLTAKDqf/M8umNYw6u7r9ONozTEUVy8SwCgygma
jWNKQmxmLpyPxr00KbQy9Vg=
=JM4K
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2007-11-01 16:14 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 [this message]
2007-11-01 17:41 ` Jeremy Fitzhardinge
2007-11-01 16:55 ` [Lguest] " Zachary Amsden
2007-11-02 1:21 ` 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=4729FB43.1010904@redhat.com \
--to=gcosta@redhat.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anthony@codemonkey.ws \
--cc=chrisw@sous-sol.org \
--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